Blockchain commitment — TG3 negotiation
Subject: How the on-chain development commitment in the SHA / IA drafts maps to three concrete architectures, what Verifluence has already promised its users, and what we need TG3 to choose before we commit engineering.
Status: Pre-call discussion document — please review before our next session.
This is the introduction to a 4-document set. Read this first; the three companion documents go deep on each axis of the decision.
Verifluence's user redlines
These are the load-bearing commitments Verifluence has already made to its operators and streamers. They are not architectural preferences — they are the platform's promises to its users. Any blockchain architecture must preserve them. Each redline below is a constraint that rules out otherwise-cheaper engineering options.
- Streamer does not sign transactions. The streamer provides only a destination address and waits for USDC to land in their wallet. Verifluence (or its relayer) submits and pays gas for every claim transaction on the streamer's behalf. This rules out any architecture that asks the streamer to sign a bridge or claim transaction.
- Streamer is paid immediately on operator approval — no batching. Each successful delivery triggers its own payout transaction the moment the operator approves it. There is no daily/hourly batch window. This rules out the obvious cost-reduction trick of bundling N claims into a single cross-chain message, which would amortise LayerZero fees but introduce hours of payout latency.
- One campaign contains 20 independent stream deliveries. Each delivery is a separately verified slot, paid on confirmed delivery. Of the 20 slots, 19 result in successful payouts and 1 results in a refund (non-delivery). This is the campaign shape every cost number in these documents is computed against.
- Operators continue to fund campaigns in USDC or USDT. Both stablecoins are first-class funding assets on the platform; the per-campaign cost analysis treats them identically (both are ERC-20s with the same gas profile and bridge support). Whether the operator touches one chain or two depends on which architecture is chosen.
Planning baseline for annualised numbers: 2,000 stream deliveries in the first year — i.e., 100 campaigns at the standard 20-delivery shape from Assumption #3. The 15-year SHA term applies. All cost numbers in this document set assume this volume held flat at 2,000 deliveries / 100 campaigns per year for the life of the agreement — a deliberately conservative floor. If platform volume grows above this baseline, annualised variable OpEx scales approximately linearly; fixed engineering, monitoring, and audit-refresh costs are largely independent of volume.
These constraints are the framework. The rest of this document — and the three companion documents — describes how each candidate architecture compares against them.
Technical assumptions
These constrain how on-chain cost is modelled for the architectures below. If any of these change, the per-campaign and TCO numbers in companion documents (2) and (3) need to be revisited.
- Operator-friction threshold: transaction fees of $0.20 USD or less are treated as zero in operator-cost analysis. A single Base USDC transfer or
fund()call costs the operator on the order of $0.005–$0.05 in gas; below the friction threshold these are reported as "no impact." This avoids cluttering the analysis with rounding-error line items while staying conservative about real frictions like bridge fees or XTZ acquisition. - Cross-chain fund bridging uses LayerZero, at $1–2 USD per transaction (mid: $1.50). This is the cost for every USDC/USDT transfer between Base and EtherLink — operator bridge-in (Option A), streamer off-bridge (Option A), and any other movement of value across the two chains. LayerZero is the only solution currently under review for this role; it matches what the EtherLink official docs prescribe.
- Cross-chain messaging (no value transfer) uses Hyperlane, at $0.30 USD per message. This is the cost for every state-update message between Base and EtherLink in Option C — deal-register, claim-release, refund-verify, etc. Hyperlane's modular ISM lets us tune security per route; it is meaningfully cheaper than LayerZero's bridge-feature pricing for pure messaging and supports both chains. (LayerZero with a custom DVN config could be substituted at comparable cost; the protocol choice does not change the architecture, only the supplier of the per-message bill.)
Market assumptions
External cost inputs the build estimates rely on:
- Smart-contract developer rate: €100/hour (~$107/hour) all-in. Reflects the EU senior-engineer market rate inclusive of taxes and benefits. Translates to ~$4,280/week and ~$171K/year for one full-time FTE-equivalent. Used in both build cost (dev-weeks × rate) and ongoing engineering overhead (% of FTE × annual loaded cost).
- Smart-contract audit rate: $4,000 USD per day, with a 1-day minimum. Reflects the rate quoted by the existing Verifluence audit partner for HTLC work. Used directly in build cost (audit-days × $4K) and audit-refresh budgets (re-review days × $4K, every 2 years).
What TG3 is asking for
The current SHA / IA drafts call for all on-chain development to happen on EtherLink, while customer-facing chains remain the operator's choice. A literal reading of that commitment admits at least three different architectures, with substantially different cost profiles, UX implications, and risk surfaces. Before Verifluence commits engineering effort, we need to align with TG3 on which interpretation matches their investment thesis.
The three options at a glance
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. EtherLink campaigns are real, complete, on-chain — but operators electing EtherLink must bridge USDC/USDT in and acquire XTZ. Streamers receiving payouts on EtherLink must off-bridge to use the funds elsewhere.
Option B — Metadata on EtherLink, funds stay on the funding chain
Funds always live on Base (or whichever chain the operator funded on). The EtherLink contract is a metadata registry — it records deal creation, claims, and refunds as on-chain events, but never holds or moves assets. Operator and streamer UX is identical to today. Every Verifluence campaign produces visible activity on EtherLink at near-zero cost.
Option C — Base as facade, EtherLink as logic
Operators only ever see Base. The Base contract holds native USDC/USDT and defers all business-logic decisions to a contract on EtherLink, coordinated via a cross-chain messaging protocol (Hyperlane at $0.30/msg as the working assumption; see Technical Assumption #3). Every state transition in the platform is an EtherLink transaction with cross-chain message echoes back to Base. Most expensive to build and operate.
Decision matrix at a glance
The single most important number for the negotiation is the Build + 15-yr TCO row, which captures what Verifluence is being asked to spend in total to satisfy "develop on EtherLink" under each interpretation. Detailed derivations are in the companion documents.
| Today (Base) | Option A | Option B | Option C | |
|---|---|---|---|---|
| Build cost (one-time) | — | ~$35K | ~$17K | ~$130K |
| 15-yr TCO (engineering + fees + ops) | <$1K | $443K (typical) / $463K (high) | $113K | $1.09M |
| Total commitment over SHA term | <$1K | $478K – $498K | ~$130K | ~$1.22M |
| Multiple of TG3's €200K investment | — | 2.2× | 0.6× | 5.7× |
| Operator UX vs today | — | Mixed (depends on chain election) | Unchanged | Unchanged |
| Streamer UX vs today | — | Degraded if EL-elected | Unchanged | Unchanged |
| New external dependency | — | LayerZero bridge | None | Hyperlane messaging |
Honest summary: B is the only option where the cost of the commitment is materially smaller than TG3's investment. A and C cost Verifluence between 2.2× and 5.7× more than TG3's €200K cheque over the agreement's lifetime — at the conservative 2,000-deliveries/year baseline, with smart-contract dev at €100/hr and Hyperlane messaging at $0.30/msg. If platform volume scales above plan, those multiples grow approximately linearly with the variable-cost component; engineering and audit-refresh overhead is largely fixed.
Document map
This memo continues in three companion documents. Each takes one axis of the decision and goes deep.
| # | Document | What it covers |
|---|---|---|
| 1 | Options — technical details + diagrams | Each architecture in detail: Solidity volumes, build steps, calendar, sequence diagrams, technical risks. The engineering view. |
| 2 | Commitments and consequences (UX, costs, risks) | Per-party impact tables: UX changes, per-campaign costs, build + total cost of ownership, operational risk surface. The operations view. |
| 3 | Share performance projection | NPV impact on company valuation; effect on each shareholder class; sensitivity to discount rate and adoption assumptions. The financial view. |
Read in order if reviewing the full case. Skip to (3) if you only want the dollar impact on shareholders.
The question we need TG3 to answer
Before we commit engineering, we need TG3 to choose which interpretation of "develop on EtherLink" matches the investment thesis:
Option A — co-equal chain. EtherLink campaigns are real and complete; operator UX on EL is meaningfully harder than Base today; streamer UX on EL requires off-bridging.
Option B — record layer. Every Verifluence campaign is visible on EtherLink; funds stay on the chain of funding; no UX change for any party.
Option C — logic layer. Operators only see Base; every escrow decision is made on EtherLink via cross-chain messaging; most expensive and highest ecosystem signal.
Each option satisfies a literal reading of the SHA clause. They're substantially different commitments on our side. We can implement any of them. Before we do, we'd like to align with TG3 on which one the investment thesis actually requires, and whether the commercial terms reflect the cost and risk profile of that choice.
What we need from TG3 before the call
A direct answer to: "Which of A, B, or C represents the commitment you're asking us to make?"
- If the answer is C, we'd like to discuss commercial-term adjustments that reflect a ~$1.2M operational obligation over the SHA term at the conservative 2K-deliveries/year baseline (scaling with growth), plus a security-review allowance for cross-chain risk.
- If the answer is B, we can likely accept the development clause largely as drafted, with light wording around the "EtherLink as record layer" framing.
- If the answer is A, we'd like to discuss carve-out language for operators who continue funding on Base, and whether TG3 will commit to an adoption-target floor that bounds the cost-of-ownership uncertainty.
Notes worth surfacing on the call
- Option B is the lowest-cost, lowest-risk way to put Verifluence "on EtherLink" in a substantive way. No external dependencies, no UX change, no significant ongoing cost. If TG3's interest is "Verifluence visibly building on Tezos infrastructure," B accomplishes that without compromising the roadmap. Companion doc (2) shows that B is the only option where the cost of the commitment is materially smaller than the investment.
- Option C is the most expensive but produces the strongest ecosystem signal. If TG3 has been pitching Verifluence to the Tezos Foundation as a flagship EtherLink integration, C is the architecture that pattern-matches that pitch. We need to understand if that's the framing being used externally.
- Option A is a middle path that depends on operator demand. If no operator elects EtherLink, the EtherLink deployment sees minimal activity. If many do, we absorb significant LayerZero bridge fees. Companion doc (3) shows that A's range of outcomes lands around 1.1× TG3's investment at the conservative baseline; scales linearly with growth.
- All three options assume current Base operations continue unchanged. None of them require migrating existing campaigns off Base. We'd expect that principle in the final SHA wording regardless of which option is chosen.
- Cross-chain messaging (Option C) has been the highest-incident category in DeFi by dollar value lost. Wormhole ($325M), Nomad ($190M), Ronin ($625M), Multichain ($126M) — all cross-chain protocol breaches. Choosing C means inheriting that risk surface for the platform's lifetime; this should be reflected in TG3's view of the founders' execution risk under the agreement.
Prepared as discussion material for the upcoming TG3 negotiation. Numbers in this set reflect best-effort engineering estimates against current Base operations data; see companion document (2) for derivation notes, and (3) for valuation-sensitivity analysis. Final SHA wording should be confirmed with Estonian counsel before signing.