Escrow V8 — Signature-Authorised Payouts

V8 is the next escrow design, built to close two gaps that V5–V7 leave open: it removes Verifluence's role as a discretionary step in releasing an operator's funds, and it removes the release secret (the preimage) that only Verifluence's database durably holds today. Release moves from "reveal a secret" to "the operator signs."

Not in production

V8 is not live for any real campaign. It is deployed on Base Sepolia (testnet) for staging and demo use only, and is unaudited. Production still runs v7 exclusively. See Status for exactly what is shipped and what is gated behind an audit.

Why V8 Exists

V5–V7 gate a payout on a preimage — a secret committed on-chain as a Merkle root when the escrow is locked. That design carries two costs:

Problem	In V5–V7
Transfer-service risk	On campaigns where Verifluence submits the release, operator consent is a database row, not something the chain can verify. Verifluence is a substantive step in moving the operator's money.
Custody risk	Verifluence's database is the only durable holder of release secrets. It can release funds using the preimage alone, and if that data were lost, funds would be unreleasable until the timelock.

V8's goal: Verifluence has no discretion over any movement of funds. It can neither force a payout nor block one. Authority to release is the operator's signature; authority to fall back is the clock.

What Changes From V7

	V5–V7	V8
Release condition	A secret (preimage) + Merkle proof	An operator signature (EIP-712, or ERC-1271 for a smart-account wallet)
Who can hold the release secret	Verifluence, durably, for the life of the campaign	No one — there is no secret
Unresponsive operator	Funds sit until the timelock, then refund to the operator	A delivered slot the operator neither signs nor disputes becomes creator-claimable after a review window
Disagreement over delivery	No on-chain mechanism	An on-chain, time-boxed dispute, resolved by an arbiter or by a deadline default
Wallet support	EOA only	Any wallet that can produce a valid signature — EOA (ECDSA) or smart account (ERC-1271): Safe, Fireblocks, passkey

The creator's position is unchanged in the one way that matters most: they still sign nothing. They confirm a receiver address once, at allocation, and wait for funds to land there — V8 does not turn them into a counterparty who has to transact on-chain.

Actors and Authorities

Authority	Who	Scope
Fund escrow / allocate	Operator	Moves their own funds in
Authorise a release	Operator	One signature per payout, or one signature for a batch
Start the review clock	Verifluence's relayer, or the operator, at any time	Anyone, permissionlessly, once one week has passed since the escrow lock or the previous release — so Verifluence can advance the clock but never withhold it
Open a dispute	Operator	On-chain, per slot, before the review window elapses
Resolve a disputed slot	Arbiter (Verifluence)	Only slots already in dispute — routes to the creator or back to the operator's pool, never anywhere else
Claim after timeout	Anyone	Permissionless; always pays the address bound at allocation
Refund an undelivered slot after the timelock	Anyone	Permissionless; returns to the operator's pool

Verifluence's on-chain powers reduce to exactly two, and neither can move funds on its own initiative: arbiter, scoped to slots already disputed, and buffer-depth, a risk parameter for a funding mode not yet enabled (see Deferred). Everywhere else — including submitting operator-signed releases — Verifluence is a courier: it can broadcast a transaction, but it cannot originate one, redirect where it pays, or withhold a refund.

Per-Slot Lifecycle

Each slot in an allocation moves through its own state independently.

Two properties hold regardless of path:

• No transition depends on an operator action after delivery. They can sign (→ released), dispute (→ disputed), or do nothing (→ claimable). Silence favours the creator, not Verifluence and not the operator.
• A dispute always resolves — by the arbiter, or, if the arbiter never acts, by a deadline that defaults to the creator. There is no state a disputed slot can be stuck in indefinitely.

Fee Capture

Verifluence's platform fee can optionally be taken on-chain, as a second transfer bundled atomically into the same release transaction — the creator's net amount and Verifluence's fee are two outputs of one call, so Verifluence is never a mid-transit holder of the creator's share. This is per-allocation and defaults to off (fee = 0): today's monthly EUR invoicing continues unless a specific allocation is funded with an explicit on-chain fee. It is one of the deferred phases below, not part of the initial rollout.

Deferred for Later Phases

Two capabilities are designed but intentionally not in the first rollout:

• Rolling-buffer funding. Today, V8 locks the full campaign amount at funding, same as V5–V7. A planned second mode lets an operator grant a standing allowance and have the contract pull only a rolling buffer of slots — capital-efficient, but it changes what the slot count guarantees (see the design doc for the honest version of that trade-off). Gated behind its own flag until V8's core has run in production.
• On-chain fee capture. Described above; ships behind its own flag once a finance decision is made on rollout pace.

Status

Shipped, on main, as of 2026-09-08: the full application integration — contract registration, a read-only indexer mirror, per-operator opt-in with an explicit "Create V8 campaign" action, allocation and delivery attestation, sign-to-release with batching and a courier relayer, and the dispute/arbiter console. None of it is reachable by a real campaign yet — every layer is behind a flag, described next.

Three independent flag layers, so no single flip turns V8 on for real money:

1. Availability (ESCROW_V8_ENABLED, per environment) — the master server switch. Off means no V8 stamping and no V8 crons, full stop.
2. Selection (a LaunchDarkly flag targeted by operator, plus a server-side escrow_v8_allowed allowlist) — both must be on before an operator can create a V8 campaign at all. An operator who never opts in sees nothing different: the existing "Create campaign" button is untouched, and a second "Create V8 campaign" button only appears once they're flagged.
3. Capability switches — the delivery attestor, the release relayer, and disputes each have their own on/off switch, independent of the other two layers.

Every switch defaults off, and turning any of them off stops a service, never a settlement: the contract's permissionless paths (claim-after-timeout, dispute-deadline default, refund-after-timelock) never depend on a Verifluence process staying up. A V8 allocation that exists cannot be stranded by a rollback.

Environment	Contract	State
Stage (Base Sepolia)	0xcC5afc2275e95F8198165f0978485AbfCAa2fbFF	Live for internal/demo use — ESCROW_V8_ENABLED=true, attestor on, compressed review timers (minutes, not the real one-week window) so a full lifecycle is testable quickly. The contract self-reports this so it can't be mistaken for production timing.
Production (Base mainnet)	(none deployed)	Nothing wired. No env vars set, no contract deployed.

What's still required before any real campaign can use it:

1. An independent security audit — hard gate, not yet done.
2. A mainnet deployment with production (uncompressed) timers and the arbiter role held by a multisig, not a single key.
3. Allowlisting a small number of pilot operators, and rehearsing the kill-switch paths on stage first.

For the full design rationale — the EIP-712 payload shape, why the Merkle tree was dropped, the funding-mode trade-offs, and the arbiter's decentralisation plan — see the escrow repository's docs/PAYOUT_AUTHORIZATION_V8.md and its companion documents.

Related Reading

• Escrow Overview — the currently-live v5/v6/v7 design, which this page assumes as background
• Payout Release — how release works today, for comparison