9. Risks & risk sharing
Option C (TVL on Etherlink, the architecture TG3 mandated) concentrates a specific set of risks on Verifluence. This page enumerates them — legal/custody, protocol exploit, bridge solvency, operator reputation, and cost-model fragility — then asks the negotiation question: the SHA, as drafted, imposes uncapped liability on the founders for any breach — is it fair that all of these risks land on them, without limit?
The cost side of this — the €400K investment against the ~€1.0M commitment, and the minimal cost of engineering the risks out — is in 8. BC cost vs investment. This page covers the risks themselves and how the SHA allocates them.
Risk register
1. Legal / custody
Holding escrow TVL on Etherlink as wrapped LZUSDC, with a VF relayer driving every release and a bridge-out path back to Base, pushes Verifluence toward the line between non-custodial escrow and custodian / money-transmitter. The escrow logic and timelocks stay non-custodial, but the relayer is a trusted signer and the funds spend their life as bridge IOUs — and any payout buffer would be custodial outright.
- Impact: VASP / MiCA / EU e-money reclassification → licensing, capital, and compliance obligations that don't exist for the Base-only product today.
- Mitigation: keep the relayer strictly authorize-only (funds never touch a VF wallet — see 7. BC-satisfying solution); per-jurisdiction legal opinion (Malta / Estonia); avoid buffers/treasury functions.
- Residual: regulatory interpretation can shift over the 15-year term regardless of design.
2. Protocol exploit (LayerZero, à la April 2026)
Cross-chain messaging is the highest-incident category in DeFi by dollar value lost — Ronin $625M, Wormhole $325M, LayerZero/Kelp $292M (Apr 2026), Nomad $190M, Multichain $126M. Option C puts a LayerZero bridge on the critical path of every escrow. An exploit of the bridge or its verifier set can drain the USDC locked on Base that backs the escrow's LZUSDC.
- Impact: escrowed client funds lost and unrecoverable by VF — a catastrophic, headline-grade event.
- Mitigation: minimise TVL dwell-time on Etherlink, migrate to CCIP when a stablecoin lane ships, monitor the bridge's verification config (push the owner toward a hardened set / V2), exploit insurance.
- Residual: VF cannot engineer away a third-party bridge exploit. This risk is created by the mandated architecture, not by VF's code. (See 4. DeFi experts' opinions.)
3. Solvency of the Etherlink bridge
LZUSDC is "money" only while OriginalTokenBridge on Base stays fully backed and redeemable. Beyond a hack, the backing can fail through operational halts, governance freezes, liquidity shortfalls, or mismanagement — any of which de-pegs LZUSDC or blocks redemption.
- Impact: the escrow holds tokens it cannot convert to real USDC → payouts and refunds stall or settle at a discount.
- Mitigation: monitor bridge reserves + redemption health; cap concurrent exposure; pre-built fast-exit.
- Residual: VF's clients' funds depend on a third party's solvency for as long as TVL lives on Etherlink.
4. Reputation — operators won't move funds to another chain
Operators fund in USDC/USDT on Base today. Option C requires those funds to be bridged to Etherlink and held as a wrapped token on a chain they did not choose. Even behind a facade UX, disclosure / ToS must reveal that funds leave Base. Post-exploit headlines make "we move your money across a bridge" a hard sell. And on Etherlink the operator never sees a transaction sent by his own wallet — every action (allocate, release, refund) is VF's relayer, not him (7. slot allocation) — deepening the "is this still my money?" unease.
- Impact: operator refusal, churn, or demands for guarantees — an adoption risk to the whole platform, not just the Etherlink path. The live Base book of business is the asset most exposed.
- Mitigation: keep Base as the visible entry/exit, clear comms, optionality, strong incident track record.
- Residual: a single bridge incident anywhere in the ecosystem can damage trust VF didn't break.
5. Cost-model fragility — the 0%-fee / liquidity assumption
The entire cheap-bridging case (~€0.5/crossing, ~€198K of chain fees over 15 yr — see 6. Interactive model) rests on the Etherlink official bridge staying 0%-fee and liquid. Two ways it breaks:
The fee rises — and VF controls none of the levers. The LayerZero
nativeFeeVF pays is destination gas + the relayer's fee + the oracle's fee (this lane runs V1 — Oracle+Relayer, verified on-chain; a future V2 migration would shift it to DVN + executor fees + a treasury take). Every component is set by a third party — chain gas markets, and the relayer / oracle whose set is chosen by the bridge's owner (Etherlink / LayerZero Labs), not VF, because VF uses the official bridge, it does not operate it. There is no contract, SLA, or price-lock:estimateFeesreturns the current price on every call, so a rise is simply paid (or the tx reverts). The measured ~$0.01–0.03 (10. Appendix) is today's snapshot, not a guaranteed rate. Two modes:- Benign drift — gas / relayer-oracle repricing nudges the fixed fee from cents to dimes. Bounded, small, doesn't scale with value.
- Dangerous — a value-based fee (an LZ treasury bps, a CCIP-style 0.05–0.1%, or a token fee the bridge owner enables) flips the cost from fixed-cents to a percentage of every deposit / release / withdrawal / refund → scales with TVL → 10–100× the modelled chain cost.
Liquidity loss. Etherlink's own docs describe a liquidity-bounded "Transfer Cap Reached" state; if the Base-side pool is exhausted or LPs exit, bridge-out stalls — payouts get stuck, or VF must fall back to slower / pricier routes.
Impact: retro-actively breaks the 15-year TCO basis and/or halts settlement.
Mitigation: the interactive model lets you stress the bridge cost upward; keep a multi-rail fallback (CCIP); negotiate a cost re-opener in the SHA.
Residual: VF cannot control a third-party rail's pricing or liquidity for 15 years — it doesn't even operate the bridge, so it has no fee lever at all. The only real defenses are a multi-rail fallback (CCIP, itself third-party-priced) and a contractual cost re-opener.
6. Bridge verification — legacy LZ V1 (Oracle + Relayer), public but VF-uncontrolled
Verified on-chain (2026-06-14, config in 10. Appendix): the Base↔Etherlink bridge runs LayerZero V1 (UltraLightNodeV2) — security is an Oracle + Relayer, not the V2 multi-DVN model. The pathway uses LayerZero's default Oracle + Relayer with 10-block confirmations (Base→Etherlink oracle 0x1e02…785F, relayer 0xcb56…aaAa). The config is fully public (anyone can read it on-chain) — but it is the bridge owner's OApp config: VF can read and monitor it, not change it.
This sits below the bar the industry moved to after the $292M exploit:
No DVNs, no n-of-m quorum. Oracle + Relayer is a 2-party model whose default operators are LayerZero's — effectively a single trust domain, the centralised-verification class the V2 DVN model was built to replace.
LayerZero's post-Kelp "no 1-of-1 DVN" remediation does not apply — there is no DVN here at all.
V1 is a deprecating protocol version; a forced migration to V2 (re-integration + re-audit) is a future cost/risk VF inherits.
The bridge's code audit (OtterSec WAB V2, Sep 2024) is pre-breach with no public re-audit.
Impact: the escrow's TVL is verified by a legacy 2-party model on a deprecating protocol, behind a pre-breach audit — the dominant loss path, entirely third-party.
Mitigation: require the owner to evidence the Oracle/Relayer set (or migrate the lane to a hardened V2 multi-DVN) + a post-2026 re-audit; monitor the on-chain config for owner changes; multi-rail fallback.
Residual: VF can read the config but cannot set it, pick the verifiers, or compel a re-audit of a bridge it doesn't operate — yet carries 100% of the liability.
7. Forced rework — protocol deprecation & rail migration
The rail is not a fixed substrate; it changes under VF on third parties' schedules, and each change forces a re-integration of a system that holds live client TVL:
LZ V1 is the legacy version. The lane runs V1 (Oracle+Relayer); LayerZero's security investment, DVN model and tooling are all V2. A V1→V2 migration of the bridge — the owner's decision and timeline — changes contracts, message encoding, the wrapped token, and the verification model, forcing VF to re-integrate + re-test + re-audit. V1→V2 was a real, breaking, industry-wide migration in 2024 — this is "when," not "if."
CCIP swap. The recommended safer rail has no USDC/USDT lane to Etherlink yet; if one ships and VF moves, that's a full rail replacement — new contracts, token mechanics, audit.
Any bridge redeploy/upgrade by Etherlink/LZ (new addresses, new wrapped token) forces VF to follow.
Impact: rework + re-audit scheduled by others — and migrating a live-TVL escrow is itself a high-risk event: re-bridging / re-wrapping / re-pointing funds is exactly the class of operation that strands or loses money. VF's escrowed LZUSDC is tied to the V1 bridge; a migration may require moving it.
Mitigation: a rail-abstraction layer (swap-friendly integration), migration runbooks + dry-runs, budgeted re-audits (in 5. TCO), and a cost/scope re-opener for forced migrations.
Residual: VF cannot set the timing — it inherits the owner's deprecation/upgrade schedule, pays the rework, and carries uncapped liability through the migration itself.
Audit perimeter — VF's audit stops at VF's contracts
Tracing where a security audit actually exists in this structure — and who commissioned it:
| Layer holding / moving the funds | Audited by | Commissioned by | In VF's control? |
|---|---|---|---|
| VF escrow + relayer (EscrowLogic on Etherlink, gateway) | VF's auditor — build + re-audits (8. cost) | VF | ✅ yes |
Wrapped-asset-bridge (OriginalTokenBridge / WrappedTokenBridge) — holds the TVL | OtterSec — "WAB V2", Sep 2024 | LayerZero / Etherlink | ❌ no |
| LayerZero core (Endpoint, UltraLightNodeV2, Oracle / Relayer — this lane is V1) | OpenZeppelin, Trail of Bits, PeckShield, ChainSecurity, OtterSec | LayerZero | ❌ no |
| Verification config — LZ V1 Oracle + Relayer (verified on-chain) | — no audit covers config; LZ default operators | bridge owner | ❌ no |
The gap: VF's audit budget covers only the top row. Once funds bridge, they sit behind a WAB contract and an LZ core VF never audited and cannot commission a re-audit of (the OtterSec WAB report is LayerZero's, dated Sep 2024 — and the live Etherlink deployment may have drifted from the audited version), plus a verification config that no audit covers at all. Misconfiguration of that layer is exactly where the $292M April-2026 exploit happened — an audited LayerZero stack defeated by a verification-config flaw (a 1-of-1 DVN), not a contract bug. So VF can re-audit its own escrow every year (the ~€16K/yr line on 8. BC cost vs investment) and still not touch the layer most likely to lose the funds. Assurance over the escrow's TVL sits mostly outside VF's audit perimeter — while 100% of the liability sits inside it.
It's worse on inspection: this bridge has no DVNs at all. Reading the live config on-chain (2026-06-14, 10. Appendix) shows the Base↔Etherlink lane runs LayerZero V1 (UltraLightNodeV2) — secured by an Oracle + Relayer (LZ's defaults, 10-block confirmations), not the V2 multi-DVN model. So the post-Kelp "ban 1-of-1 DVN / require 2-of-3" hardening doesn't even apply — there is no DVN to harden; it's the older 2-party model whose operators are LayerZero's, effectively a single trust domain, on a deprecating protocol version. The WAB code audit (Sep 2024) is pre-breach with no public re-audit. The config is public and readable (good for due diligence), but owner-controlled — VF can monitor it, not set it. The honest ask to TG3: evidence the verification set (or migrate the lane to a hardened V2 multi-DVN) and a post-2026 re-audit — or share the liability for layers VF can neither audit nor control.
Risk concentration — who bears it
| Risk | Created / imposed by | Can VF engineer it away? | Bears it under the SHA today |
|---|---|---|---|
| Legal / custody | The mandated cross-chain custody | Partly (design) | Founders |
| Protocol exploit | LayerZero / mandated rail | No | Founders |
| Bridge solvency | Etherlink bridge (3rd party) | No | Founders |
| Operator reputation | The "move funds off Base" mandate | Partly (comms) | Founders |
| Fee / liquidity shift | LayerZero / Etherlink (3rd party) | No | Founders |
| Bridge assurance gap | Bridge owner's pre-breach audit + V1 Oracle/Relayer config | No | Founders |
| Forced rework / migration | LZ V1 deprecation, Etherlink upgrades, CCIP swap (3rd party) | Partly (abstraction) | Founders |
Four of the seven are third-party risks no amount of VF engineering can remove, and all seven flow from an architecture TG3 directed — yet the SHA, as drafted, treats non-delivery as material breach and leaves the founders carrying every downside under uncapped liability for the term. Every cell in that last column reads Founders — without limit.
Risk sharing — is "founders carry all risk" fair?
Execution risk: yes — founders own it. Building the escrow well, running the relayer reliably, passing the audit — that is squarely the founders' responsibility, and the SHA should hold them to it.
Imposed and uncontrollable risk: no — that should be shared or carved out. It is not reasonable for founders to solely bear risks that (a) TG3's mandated architecture created and (b) no party can engineer away — a bridge exploit, a third-party's insolvency, a protocol fee change, a regulatory reclassification. The party that chose the risk-bearing architecture should share its downside.
Concrete asks for the SHA:
- A liability cap — and no double recovery. Uncapped personal liability for any breach is the headline problem. Cap it — e.g. at the fees/investment received or a negotiated sum — and exclude third-party-protocol events entirely. Critically, any return-of-subscription remedy must net against (not stack on top of) the liability cap: founders should not both repay the €400K and face unlimited liability for the same event. Unbounded founder exposure against an investor whose capital is fully clawable back is not risk capital — it is a secured loan with unlimited recourse.
- Force-majeure carve-out for third-party protocol failures (bridge exploit, LayerZero/Etherlink outage or fee change, liquidity halt) — these are not a founder "material breach."
- Cost re-opener: the ~€1.0M TCO is conditioned on the 0%-fee bridge; if a fee appears or liquidity forces a pricier rail, the commitment and the terms are revisited.
- Shared liability / TG3 indemnity for losses from the mandated bridge, since TG3 directed the chain choice.
- Security-review + exploit-insurance allowance funded from the round, not the founders' pocket.
- Milestone-based delivery — no material-breach trigger for third-party-caused failures or events outside VF's control.
Bottom line: founders should own how well it's built; TG3, having mandated what's built and on which rail, should share the risks that choice creates and that neither side can remove. A 60/40 founder cap table absorbing uncapped liability for a TG3-directed, third-party-driven risk surface for 15 years — against an investor whose €400K is itself clawable back on breach — is the misalignment to fix at the table.
Prepared as discussion material for the TG3 negotiation. Not legal advice — final SHA wording and any liability/indemnity terms should be confirmed with counsel.