Escrow Overview
The Verifluence escrow is a smart contract on Base that holds a campaign's budget from the moment an operator funds it until it is either paid out to a creator or returned to the operator. It enforces two properties that matter most: funds can only ever reach the creator address committed at allocation time, and the amount per slot cannot be changed after the fact.
It is not a fully autonomous payment machine. A payout happens when the operator approves the delivery — the contract enforces where the money goes and how much, not whether the work was done. That division is deliberate and is described precisely below.
Current deployment
Production runs HTLC v7 on Base mainnet (chain 8453) at 0xed1C0d614D993032e23f88999126cA6Cb2F31481, bound to Circle native USDC (0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913). Earlier campaigns remain served by v5 (0xC66BbeA8e1b8A75A95DC2660c85B38Ee03Ba6290) and v6 (0x08c94ACa0EFf8Bc0865948Ee7E8583cDBA55215e).
A signature-authorised redesign, Escrow V8, is staged on testnet pending an independent audit — not live for any real campaign yet.
Fund Lifecycle
Stage 1: Fund
The operator transfers campaign budget from their own wallet into the contract. The funds are visible on-chain and can only move according to the contract's rules. Verifluence never takes possession of them.
Stage 2: Lock escrow
The operator commits a portion of the pool to one creator. The allocation fixes, immutably:
- the receiver address — the only address that escrow can ever pay,
- the number of slots and the amount per slot, committed as a Merkle root,
- a timelock, after which unspent funds can be returned to the pool.
Stage 3: Release or refund
- Release — once the operator approves a delivery, the slot's funds transfer to the bound receiver address. See Payout Release for who submits this transaction and what authorises it.
- Refund — after the timelock, unspent allocation funds can be returned to the operator's campaign pool. Unallocated pool balance can be withdrawn by the operator at any time.
Custody and Control
| Question | Answer |
|---|---|
| Who holds the funds after funding? | The contract. Verifluence never takes custody, and never holds operator or creator funds off-chain. |
| Can the payout be redirected? | No. The receiver address is bound when the escrow is locked and is immutable. Every transfer pays that address. |
| Can the amount or schedule be changed? | No. Per-slot amounts are fixed by the on-chain Merkle root at allocation time. |
| Can Verifluence move escrowed funds? | No. There is no administrative withdrawal path, and the owner's recovery function is arithmetically capped at the non-escrowed balance. |
| Does Verifluence hold any keys? | Yes — but not over your funds. It holds the contract owner key (pause and stray-token recovery, both scoped below) and a relayer key that can submit an already-authorised payout. Neither can change a recipient or an amount. |
| Is there a pause function? | Yes, owner-only — and its scope is narrow: it gates new funding and new allocations only. Release, refund and operator withdrawal all stay callable while paused, so a pause cannot trap escrowed money or block a creator's payout. |
| Can the contract be upgraded? | No. There is no proxy and no delegatecall. Each version is a fresh, immutable deployment; existing campaigns keep serving on the version they were created under. |
| Are there external dependencies? | No. No oracle, bridge or external verification module. Proof checking is a pure in-contract keccak256 + Merkle computation. |
| How are disputes handled? | Off-chain, on the platform. The contract has no dispute mechanism — it enforces the allocation's terms, not the delivery's quality. |
Owner Capabilities, Precisely
The contract has an owner (0x87364ef4…804C, held by Verifluence). Its powers are deliberately minimal, and neither touches escrowed funds:
| Function | Scope | Effect on escrowed funds |
|---|---|---|
pause() / unpause() | Blocks fund() and lockEscrow() | None. Releases, refunds and operator withdrawals continue to work while paused. |
recoverToken() | Sweeps tokens sent to the contract by mistake | None. Capped at contract balance minus reserved escrow, so escrowed funds are out of reach by arithmetic. |
transferOwnership() | Moves ownership | None. |
Asset Support
| Property | Detail |
|---|---|
| Token | One ERC-20, bound immutably at deployment. Production is bound to Circle native USDC; the contract rejects any other token. |
| Native currency | Not supported. There are no payable entry points, which removes the ETH reentrancy surface entirely. |
| Transfers | OpenZeppelin SafeERC20. Fee-on-transfer, rebasing and ERC-777 callback tokens are unsupported. |
| Solvency | An automated invariant proves the contract's token balance always equals everything funded minus everything released and refunded. |
Documentation once said USDT
Some older material referred to USDT. Production has only ever settled in USDC; the single-token binding makes any other asset impossible on the deployed instances.
On-Chain Transparency
Every action emits a permanent public record:
| Event | What it records |
|---|---|
CampaignCreated | A campaign pool was opened |
Funded | Operator moved budget into the pool |
EscrowLocked | Budget committed to a creator, with receiver, slots and timelock |
EscrowReleased | A slot was paid to the bound receiver |
EscrowRefunded | Unspent allocation funds returned to the pool |
FundsWithdrawn | Operator withdrew unallocated pool balance |
TokenRecovered | Owner swept a stray non-escrow token |
Paused / Unpaused | Funding and allocation were suspended or resumed |
Anyone — operator, creator, auditor or regulator — can verify these independently, without access to Verifluence's systems.
Detailed Flow Documentation
- Funding the Campaign Pool — how budgets enter escrow
- Budget Allocation — how funds are committed to a creator
- Payout Release — how a creator gets paid, and who signs
- Fund Recovery (Refund) — how operators reclaim unused budget
- Security Assurance — testing and review coverage