Escrow and verifier requirements

Specification version: 2026-09-03.1 Status: frozen for implementation review (CONTRACT-001)

This specification freezes the local requirements for CampaignEscrow, RewardDistributor, ServiceEscrow, and verifier integration. It does not approve deployment, funding, a token launch, or use with real value. The canonical product plan remains RAIDZ_MASTER_PROJECT_PLAN_2026-09.md.

Economic constants and rounding

A project funds a campaign with $RAIDZ. At MVP, exactly 8% of gross funding routes once to FeeRouter; the remaining 92% is the creator reward pool. A later tiered fee requires a separate reviewed specification.
Each verified creator reward is reserved from the creator pool, then divided into 70% immediate settlement and 30% retention settlement.
Integer division rounds the fee and immediate portion down. Every remainder stays in the creator pool or retained portion respectively, so value is never lost.
Reserved, paid, retained, refundable, and protocol-fee balances must reconcile to gross deposits at every state. No administrative sweep may consume a creator obligation.

The executable constants and pure split functions live in packages/domain/src/escrow-requirements.ts.

Roles and authority

Role	Authority	Explicitly forbidden
Project	Fund its campaign, deploy after approval, request eligible unused-budget refund	Verify its own deliverable, redirect a creator payment, refund reserved obligations
Creator	Claim once within eligibility/capacity, submit a non-empty deliverable commitment, receive settlement	Change reward terms after claim, submit for another wallet, reuse a claim
Campaign factory	Create an isolated escrow from reviewed immutable campaign terms	Custody campaign funds outside the created escrow
Verifier registry	Maintain the three authorized verifier identities and expose quorum configuration	Approve deliverables or move escrow value itself
Verifier quorum	Authorize a specific proof result through EIP-712 signatures	Change campaign terms, recipient, or payment encoded in the attestation
Emergency authority	Pause value-moving and claim/submission entry points; initiate documented recovery	Seize funds, fabricate approval, bypass quorum, or alter balances
Public caller/relayer	Submit a complete signed attestation to permissionless settlement entry points	Gain authority merely by paying gas

Production signer custody, rotation, and recovery remain gated work. A project, creator, operator, or relayer is not implicitly a verifier.

Campaign value flow

The factory records immutable campaign ID, project, token, gross deposit, creator-pool amount, deadline, creator limit, reward rule, verification policy, retention period, and refund policy.
Funding transfers the gross deposit atomically: the 8% fee goes to FeeRouter and the 92% creator pool reaches the isolated escrow. Fee-on-transfer, rebasing, callback-capable, or otherwise non-conforming tokens must be rejected unless separately reviewed.
A successful claim reserves its maximum reward before returning. Capacity, deadline, duplicate-wallet, and available-pool checks precede mutation.
A creator commits a non-zero deliverable hash. A valid approval attestation releases 70% to the same creator wallet and locks 30% until the agreed retention deadline.
After the deadline, a fresh retention attestation releases the retained 30% to the creator when the required deliverable remains valid; otherwise it returns only that retained amount to the project.
A rejected initial proof releases the entire reserved reward back to unused campaign balance. It pays neither creator nor protocol a second fee.
After expiry, the project may recover only unreserved and explicitly released value. Open creator obligations remain in escrow until settled or resolved under the frozen refund policy.

All transfers use checks-effects-interactions, reentrancy protection, exact state guards, and events containing campaign/claim identifiers and amounts.

Proof and quorum contract

The MVP verifier set contains three authorized signers and requires two distinct authorized signatures. Signers are sorted or deduplicated onchain; duplicate signatures never increase the count.

Each initial EIP-712 attestation binds at minimum:

domain name/version, chain ID, and verifying contract;
campaign ID and creator wallet;
deliverable hash and verification status;
exact gross creator reward used for the 70/30 split;
nonce, observation timestamp, and expiry.

Each retention attestation additionally binds the retained amount and whether the contractually required deliverable remains valid. A digest is single-use. Expired, wrong-domain, wrong-chain, wrong-contract, wrong-campaign, wrong-creator, wrong-hash, wrong-amount, duplicate-signer, unauthorized-signer, and replayed attestations fail closed without balance or state changes.

Pause, failure, refund, and recovery matrix

Condition	Required behavior	Value destination
Claim capacity exhausted, duplicate claim, deadline passed, or insufficient pool	Revert before reservation	Unchanged escrow balance
Empty or wrong-owner submission	Revert before state mutation	Reserved reward unchanged
Initial proof rejected by quorum	Mark rejected; release reservation	Unused campaign balance
Quorum/signature/expiry/replay failure	Revert atomically	No value movement
Retention check passes	Mark settled once	Retained 30% to creator
Required deliverable invalid at retention check	Mark settled once with failure reason	Retained 30% to project
Campaign expires with unused balance	Permit project refund only after expiry and with no overlap with obligations	Project
Pause active	Block new claims, submissions, verification releases, retention releases, and ordinary refunds	Funds remain isolated in escrow
Token transfer fails	Revert the whole transition	Prior state and balances
Verifier compromise or signer rotation	Pause; preserve funds; rotate through separately reviewed registry procedure; require fresh attestations	No automatic movement
Irrecoverable contract fault	Pause and use a separately reviewed, timelocked recovery/migration path preserving claimant balances	Equivalent isolated escrow or original recipients

Unpause requires the emergency authority, a recorded incident resolution, reconciled balances, and verifier health. Recovery cannot rewrite completed settlement, weaken 2-of-3 quorum, or transfer creator obligations to an operator or treasury.

Implementation and review gates

CONTRACT-002 and CONTRACT-003 must encode these requirements and add unit, fuzz, invariant, malicious-token, signature/replay, withdrawal, pause, and recovery tests. Before any testnet rehearsal or marketplace funding, the project must also complete verifier-key isolation, signer rotation/recovery documentation, exact artifact review, and independent audit gates from the canonical plan.