Options — technical details + diagrams

Companion document to the main memo. This document goes deep on the three candidate architectures: how each one is built, what the Solidity surface looks like, what calendar time and audit effort each requires, and what specific failure modes each one inherits.

The redline assumptions and the high-level option summaries live in the introduction. This document assumes you've read that.

---

Option A — Parallel deployments, equal service on both chains

Verifluence publishes the same audited HTLC contract on Base and on EtherLink. Operators choose a chain at campaign creation. Streamers receive USDC on whichever chain the operator funded.

Source: docs/tg3/blockchain_commitment/diagrams/option-a.puml

What you actually build

• Recompile the existing HTLC contract against EtherLink RPC. No Solidity changes required — the contract is EVM-equivalent code, Shanghai/Cancun-compatible.
• Add chain-aware addressing in the backend (api/src/oauth.ts and payout-relay logic): per-deal chain ID, per-chain contract address registry.
• Wire RainbowKit / wagmi to expose EtherLink as a selectable chain on the operator flow.
• Stand up a second indexer reading EtherLink events (your existing indexer points only at Base).
• Add a streamer-side off-bridge UX so streamers receiving payouts on EtherLink can move USDC back to Base via the LayerZero bridge.

Solidity surface

• Existing HTLC contract — unchanged. ~250 lines.
• Chain-aware deployment scripts — Foundry / Hardhat config additions, ~50 lines of deploy script.

Build effort

• Engineering: 4–6 dev-weeks for one senior engineer
• Audit (incremental): $5–10K, 2–4 days with your existing auditor
• Calendar: 4–6 weeks end-to-end

Technical risks specific to A

• Transfer Cap Reached on the streamer off-bridge. EtherLink's official docs explicitly describe a liquidity-bounded bridge state where transfers fail because the LayerZero pool on Base is exhausted. You can't engineer around this; you can only build a recovery path.
• Operator XTZ liquidity acquisition. Every operator who elects EtherLink must obtain XTZ to pay gas. There's no in-platform path to do this — they need a CEX or DEX trade. Adds an onboarding step Verifluence doesn't control.
• Adoption uncertainty. If few operators elect EtherLink, the deployment is stranded engineering effort. If many do, the per-campaign cost on the EL path is ~180× the Base baseline.

---

Option B — Metadata on EtherLink, funds stay on the funding chain

Funds always live on the chain where the operator funded. The EtherLink contract is a metadata registry — it records deal creation, claims, and refunds as on-chain events, but never holds or moves assets.

Source: docs/tg3/blockchain_commitment/diagrams/option-b.puml

What you actually build

• Deploy a thin DealRegistry contract on EtherLink. It stores no value — only dealId → (operator, totalFunded, slotCount, openedAt, status, claimsHash, refundsHash). Public read functions for inspection.
• Add a Verifluence backend writer that subscribes to the existing Base HTLC events (DealFunded, SlotClaimed, SlotRefunded) and posts attestation transactions to the EtherLink registry.
• Batch claim attestations into a single registry call per N events to keep gas down (claims write a Merkle root; individual claims provable against it off-chain).
• Maintain a small ETH/XTZ balance on the backend writer account to fund attestation transactions.

Solidity surface

• Existing HTLC contract on Base — unchanged.
• New DealRegistry on EtherLink — ~80 lines. Trivial pattern: write-only event registry with a small admin role for the backend writer address.

Build effort

• Engineering: 2–3 dev-weeks for one senior engineer
• Audit: $3–5K — the contract has no value-at-risk, so the audit is a sanity check rather than an adversarial review
• Calendar: 2–3 weeks end-to-end

Technical risks specific to B

• Backend writer reliability. If the attestation writer crashes for an extended period, the EtherLink record falls behind. Mitigation: the writer is idempotent and can replay from any Base block.
• Stale records during incidents. Attestation can lag behind the real chain by minutes. If TG3 (or anyone) is monitoring the registry as a real-time signal, they may see a brief gap. Mitigation: registry exposes a lastSyncedBaseBlock field that anyone can query.
• Registry contract takeover. If the writer's private key leaks, an attacker can write false attestations. They cannot drain funds (the registry holds no value), but they can pollute the record. Mitigation: standard hot-key hygiene; rotate periodically; consider a multisig writer role for high-stakes deployments.

This is the lowest-complexity, lowest-risk architecture. Almost everything that could go wrong is contained to the EtherLink registry and has no impact on operator/streamer funds.

---

Option C — Base as facade, EtherLink as logic

Operators only ever see Base. The Base contract (EscrowGateway) holds native USDC and acts as a thin interface that defers all business-logic decisions to a contract on EtherLink (EscrowLogic). The two chains coordinate via a cross-chain messaging protocol (LayerZero or equivalent).

Source: docs/tg3/blockchain_commitment/diagrams/option-c.puml

What you actually build

• EscrowGateway on Base — holds native USDC. Has a single trusted-remote that can call releaseTo(address, amount) and refundTo(address, amount). Otherwise inert. Operators interact with this contract for fund() and refund().
• EscrowLogic on EtherLink — owns the deal state, the preimage hashes, the expiry timestamps. Verifluence's relayer calls claim(dealId, slotIndex, preimage) here, which verifies and emits a release message to Base.
• LayerZero (or equivalent) OApp integration on both contracts — endpoint addresses, trusted-remote configuration, per-message fee quoting.
• Recovery contracts and admin paths — recoverStuckMessage(), emergency pause, long-timelock fallback path for operator-side recovery if EtherLink is unreachable for an extended period.
• Two indexers (Base + EtherLink), with cross-chain reconciliation logic in the backend to detect "fund on Base, no corresponding registration on EtherLink" or "claim on EtherLink, no corresponding release on Base."

Solidity surface

• EscrowGateway on Base — ~250 lines (token vault + message handler + emergency paths)
• EscrowLogic on EtherLink — ~300 lines (full state machine)
• Messaging adapter — ~100 lines per side
• Recovery + admin — ~80 lines
• Total: ~650 lines of Solidity + ~1,500 lines of tests covering reorder, replay, stuck-message, reorg, and fee-underpayment scenarios

Build effort

• Engineering: 8–12 dev-weeks for one senior engineer (or 5–6 weeks for two)
• Audit: $50K–$100K. Often two firms in series — cross-chain code has the highest-incident rate in DeFi, and reputable audit firms recommend independent second reviews for cross-chain components handling user funds.
• Calendar: 8–12 weeks end-to-end (audit cycle dominates)

Technical risks specific to C

• Cross-chain messaging-protocol failure. Wormhole ($325M), Nomad ($190M), Ronin Bridge ($625M), Multichain ($126M), Harmony Horizon ($100M) — all cross-chain protocol breaches. By choosing C, Verifluence inherits the messaging protocol's full security model for the platform's lifetime. Your $8K audit covers your code; it does not audit LayerZero / Hyperlane / CCIP.
• Stuck messages. Cross-chain delivery is not synchronous. Messages can be delayed during destination-chain congestion or relayer downtime. The platform needs a manual-retry path and a runbook for the on-call engineer.
• Message replay attacks. Each message must carry a unique nonce, and the receiver must deduplicate. Standard pattern, but a known footgun.
• Source-chain reorg vs message delivery. If the source chain reorgs after a message attestation is signed but before it executes on the destination, the message can deliver value for a transaction that no longer exists. Protocols mitigate this with finality thresholds, but EtherLink's hard-finality window is longer than Base's. Soft-finality settlement is what gets used in practice, and that's a small-but-nonzero risk.
• Operational complexity at incident time. Recovery from a stuck-message or cross-chain failure scenario is meaningfully harder than recovering from a single-chain incident. Runbooks must cover both chains, both indexers, and the messaging protocol's recovery affordances simultaneously.

---

Build effort summary

	Today (Base)	Option A	Option B	Option C
Solidity lines added	—	~50 (deploy scripts)	~80 (registry contract)	~650 (two contracts + adapter + recovery)
Test code added	—	~50 lines	~150 lines	~1,500 lines
Engineering dev-weeks	—	4–6	2–3	8–12
Senior eng time @ $5K/wk	—	$20–30K	$10–15K	$40–60K
Audit (initial)	—	$5–10K	$3–5K	$50–100K
Calendar to ship	—	4–6 weeks	2–3 weeks	8–12 weeks
Reversibility	N/A	Easy — disable EL path	Easy — stop writing	Hard — sunk audit + on-chain state

---

Next

The operational consequences of each architecture (UX changes, ongoing costs, risk surface, recovery scenarios) are covered in Commitments and consequences. The financial impact on shareholders is covered in Share performance projection.