4 — Etherlink TVL settlement: technical evaluation
A focused follow-up to Option C, written after TG3's June 10 clarification of what "meaningful" use of Etherlink means. It folds in three inputs the earlier memo did not have:
- TG3's own definition of "meaningful" (their June 10 reply).
- Official Etherlink documentation on how USDC/USDT actually bridge to and from Etherlink today.
- A DeFi-engineering review of the resulting settlement design — atomicity, custody, liquidity, and failure modes.
The earlier documents assumed Option C as a messaging layer (state echoes between chains, funds stay on Base). TG3's clarification rules that reading out. This document evaluates the version they actually asked for: real TVL moving Base ⇄ Etherlink in both directions.
4.1 What TG3 now means by "meaningful"
From the June 10 reply, verbatim intent:
"We want Verifluence to build on Etherlink in a meaningful way, not merely use Etherlink as a passive metadata layer. However, this should be implemented in a way where operators and streamers never need to care about Etherlink, Base, gas tokens, bridges or wallets."
"We would see Etherlink as the main implementation and settlement layer, while Verifluence abstracts away the chain complexity from the end users."
Three hard constraints follow:
| Constraint | Consequence for architecture |
|---|---|
| Etherlink is the settlement layer, not a registry | Rules out Option B (metadata only). Value and logic must live on Etherlink. |
| TVL moves through Etherlink in a tangible way | Funds bridge Base→Etherlink and back — not just state echoes. This is a value-bridge problem, not a messaging problem. |
| Users never touch chain / gas / bridge / wallet | Rules out vanilla Option C too (operator signs fund()/refund() on Base). Requires a relayer / gas-abstraction / partial-custody layer on top. |
So the target is Option C's split-contract shape, upgraded from messaging to real value-bridging, plus a full abstraction layer. That is strictly more than any option costed in documents (1)–(3).
4.2 Official Etherlink bridging — what actually exists today
Everything below is from the official Etherlink documentation (docs.etherlink.com), not third-party tooling. This matters because it fixes the bridge primitive we'd be building on.
The bridge is LayerZero, lock-and-mint, wrapped
"The bridge uses the decentralized smart contracts of LayerZero… When you bridge tokens to Etherlink, the bridge contracts lock the tokens in a liquidity pool on the source network and mint tokens on Etherlink. When you bridge tokens out of Etherlink, the contracts burn the tokens on Etherlink and unlock them in the liquidity pool on the target network."
Implications:
- USDC/USDT on Etherlink are bridged/wrapped representations, not canonical issuer tokens. The real USDC/USDT stays locked in the LayerZero pool on the source chain (Base). "TVL on Etherlink" is therefore a 1:1 wrapped claim, collateralised on Base — not the native token.
- There is no CCTP / canonical issuer path for either asset on Etherlink. (USDT0 — Tether's LayerZero OFT — exists as a separate omnichain standard, but the Etherlink official bridge is the wrapped LayerZero route above.)
Supported routes and live mainnet addresses
| Item | Value (Etherlink mainnet) |
|---|---|
| Bridge contract (all networks) | 0x1f8E735f424B7A49A885571A2fA104E8C13C26c7 |
| USDC (bridged) | 0x796Ea11Fa2dD751eD01b53C372fFDB4AAa8f00F9 |
| USDT (bridged) | 0x2C03058C8AFC06713be23e58D2febC8337dbfE6A |
| WXTZ (LayerZero OFT) | 0xc9B53AB2679f573e480d01e0f49e2B5CFB7a3EAb |
| Supported counter-chains | Ethereum, Arbitrum One, Base, Optimism, BNB Chain, Avalanche |
Base ⇄ Etherlink for USDC/USDT is officially supported — so the route VF needs exists out of the box.
The constraint that dominates the design: withdrawal liquidity caps
"Bridging tokens out of Etherlink is dependent on the liquidity pool on the target chain… if the bridge contract on [target] has 100 USDT, you can transfer no more than 100 USDT from Etherlink."
This is the "Transfer Cap Reached" state the original Option A analysis flagged — and it now applies to every payout in a TVL-moves-both-ways design. If the Base-side LayerZero pool is short, a streamer payout cannot unlock. You cannot engineer this away on the official bridge; you can only (a) keep the pool funded, or (b) run your own OFTAdapter and custody the float yourself (more code, more audit, VF becomes the custodian).
4.3 The settlement design under "real TVL movement"
Two viable shapes. Both use the official LayerZero bridge for value and LayerZero/Hyperlane messaging for state.
Variant A — move-on-allocate (split state)
- Deposit-state on Base, allocation-state on Etherlink. Unallocated funds stay on Base; only allocated value bridges to Etherlink.
- Cheaper: unallocated funds and their refunds never cross-chain.
- Cost: distributed state. "available = deposited − allocated" spans two chains → reconciliation logic, and a lost message diverges balances.
Variant B — all-on-Etherlink (Base = stateless gateway) — recommended
- Base contract is a pure OFT entry/exit gateway. All accounting + HTLC (deposit ledger, allocation, preimage verification) lives on Etherlink.
- Operator deposits on Base → bridged immediately to Etherlink → all logic on Etherlink → withdraw triggers OFT back to Base to pay the receiver.
- Single source of truth — no cross-chain state reconciliation. Cleaner to audit.
- Best fit for TG3's thesis ("value, logic and activity move through Etherlink"). Trade-off: every deposit and every unallocated-refund is a bridge hop.
DeFi-engineering note — recommend Variant B. Distributed mutable balances across two asynchronous chains (Variant A) is the classic source of cross-chain accounting bugs. Putting one authoritative ledger on Etherlink and making Base a dumb gateway removes an entire bug class for a modest hop-cost increase.
Three non-negotiable engineering requirements
- Atomic allocate via OFT compose. The token transfer and the allocation parameters must travel in one LayerZero message (
sendAndCall/lzCompose), so the mint on Etherlink and the allocation-state write happen in a single delivery. Sending them as two messages admits a state where tokens are minted with no allocation recorded (or vice-versa) → stranded funds. Same applies to withdraw (verify + burn atomic). - One hop per payout, not two. If
withdraw()is initiated on Base, it costs two cross-chain hops (Base→Etherlink to verify, Etherlink→Base to release). Since TG3 requires a relayer anyway (streamers don't sign), the relayer initiates the claim on Etherlink → a single Etherlink→Base value hop. - Explicit refund paths.
refundUnallocated(cheap and single-chain in Variant A; a hop in Variant B) andrefundof an expired-timelock allocation (Etherlink→Base back to the operator) must both be designed, plus arecoverStuckMessagepath for delayed LayerZero deliveries.
4.4 Cost of moving TVL tangibly
Computed on the document-set baseline (campaign = 10 slots: 9 payouts + 1 refund; 200 campaigns / 2,000 deliveries per year; no payout batching, per Assumption #2). With real value movement, every value move is a LayerZero bridge crossing, not a $0.30 message.
Measured update. The $1.50 / $0.40 OFT figures below are pre-measurement planning ceilings. On-chain, the Etherlink official bridge takes 0% on the token and charges only the LayerZero message fee — measured ~$0.01 in / ~$0.03 out per crossing (10. Appendix). At that rate a campaign's ~11 value crossings cost ~$0.30 + gas (~$0.65 total), and the annual figure is ~$130/yr at 200 campaigns — not the ~$3,400 the planning ceiling shows. The table is kept as a conservative upper bound; the structural conclusions still hold (and "bridging is cheap" is now far stronger — see the revised takeaways).
Per campaign
| Movement | Count | OFT @ $1.50 (planning) | OFT @ $0.40 (realistic Base↔EL) |
|---|---|---|---|
| Bridge budget in (bulk) | 1 | $1.50 | $0.40 |
| Payout out (per delivery, unbatched) | 9 | $13.50 | $3.60 |
| Refund out (1 non-delivery) | 1 | $1.50 | $0.40 |
| Cross-chain subtotal | 11 | $16.50 | $4.40 |
| Base + Etherlink gas (~20 tx) | — | ~$0.35 | ~$0.35 |
| Per campaign | ≈ $17 | ≈ $5 |
Annualised and 15-year (200 campaigns/yr; 15-yr SHA term)
| Scenario | / campaign | / year | / 15 yr |
|---|---|---|---|
| Measured (~$0.025/crossing, on-chain) | ~$0.65 | ~$130 | ~$2K |
| Planning ceiling ($1.50, bulk-in, 1-hop) | ~$17 | ~$3,400 | ~$51K |
| Realistic ($0.40) | ~$5 | ~$1,000 | ~$15K |
| Worst (per-slot bridge-in + 2-hop withdraw) | ~$34 | ~$6,800 | ~$102K |
"Gas burning" specifically
- Etherlink (XTZ): ~2 tx/slot → ~4,000 tx/yr @ ~$0.005 ≈ $20/yr burned XTZ.
- Base (ETH): ≈ $30–50/yr.
- Absolute gas is noise. The real operational burden is that the relayer must always hold ETH on Base and XTZ on Etherlink and pay for everything (the abstraction requirement) — XTZ has to be sourced and auto-topped-up.
The cost takeaway
- Bridging is not the expensive part — measured, it's a rounding error. Even at the $1.50 ceiling variable cross-chain cost is ~$3.4K/yr (< 0.04 FTE); on-chain it's ~$130/yr.
- At measured cost, batching barely matters. The 9 un-batched payout-bridges are still ~80% of variable cost, but variable cost is now ~$130/yr total, so batching them into 1 saves ~$0.24/campaign (~$50/yr) — not the ~$2,400/yr it would have saved at the $1.50 ceiling. The no-batch rule is no longer a cost lever worth re-opening with TG3; if it's re-opened, the reason is latency / UX, not cost. (This reverses the earlier draft, which — pre-measurement — called batching "the single most valuable thing to re-open.")
- Build + audit dominate TCO. OFT-compose integration on top of Option C ≈ $150–180K build; cross-chain + custom OFTAdapter audit ≈ $60–120K, two rounds. Over 15 years these dwarf all gas and bridge fees combined.
4.5 DeFi-engineering risk register (specific to this design)
| Risk | Source | Mitigation / cost |
|---|---|---|
| Withdrawal liquidity cap — payout can't unlock if the Base-side pool is short | Official Etherlink bridge behaviour | Keep pool funded, or run own OFTAdapter (VF custodies float → more audit) |
| Wrapped, non-canonical USDC/USDT on Etherlink — only redeemable through the pool; not fungible with native | Lock-and-mint model | Accept wrapped representation, or adopt USDT0 OFT for USDT (USDC has no canonical EL path) |
| Non-atomic allocate/withdraw — tokens minted without state | Two-message naïve design | OFT compose (lzCompose) — mandatory, not optional |
| Two hops per payout — 2× fee, latency, stuck-message risk | Withdraw initiated on Base | Relayer initiates on Etherlink → 1 hop |
| Stuck / replayed messages, source-chain reorg vs delivery | Cross-chain messaging | Nonce + dedupe, finality thresholds, recoverStuckMessage, on-call runbook spanning both chains |
| Custody shift — VF becomes a fund custodian if running own adapter | Avoiding liquidity caps | Legal/regulatory review; multisig admin; this is a business decision, not just code |
| Abstraction layer — relayer keys, gas wallets, meta-tx / fiat on-ramp | TG3 "no user signing" | Separate workstream; not in any prior estimate |
4.6 Decision points for the CTO call
- Official bridge vs own OFTAdapter? Using the official Etherlink LayerZero bridge means VF does not custody funds (they sit in LayerZero's pool) but inherits the liquidity-cap on payouts. Running our own adapter removes the cap but makes VF the custodian (audit + regulatory weight). This is the pivotal choice.
- Canonical token strategy. USDT can use the USDT0 OFT (Tether-backed, omnichain). USDC has no canonical Etherlink path — only the wrapped bridge. Does TG3 accept wrapped USDC on Etherlink, or is USDT-only acceptable?
- Payout batching. Will TG3 relax the immediate-per-delivery rule for a short aggregation window? This is the dominant cost lever.
- Who runs/funds the relayer, and is a fiat / multi-token on-ramp in scope for the "operators fund in fiat" ask?
- Their portfolio CTO's actual design — which of these problems have they already solved, and with which primitive (official bridge, USDT0, own OFT, intent/solver network)?
4.7 Bottom line
- TG3's "meaningful" = Etherlink as the settlement layer with real TVL flowing both ways, fully abstracted from users. That is more than messaging-only Option C and more than anything previously costed.
- The route exists today (official Base ⇄ Etherlink LayerZero bridge for USDC/USDT), so this is buildable on documented infrastructure.
- Gas and bridge fees are cheap (~$1–3K/yr; worst case ~$6.6K). The money is in build (~$150–180K) and audit (~$60–120K), plus a new abstraction/custody workstream with no prior estimate.
- The two design pivots that decide cost and risk are (a) official bridge vs own custodial adapter, and (b) whether payouts can be batched. Both are TG3 decisions, best closed on the CTO call before any Solidity is written.