Proof, verification, and settlement

Raidz treats a deliverable, the evidence used to evaluate it, and the payment instruction as separate objects. This prevents a screenshot or a single API response from becoming an unreviewable payment oracle.

Evidence path

creator submission
  → canonical URL and/or content hash
  → channel-specific observation
  → campaign-rule evaluation
  → integrity and fraud checks
  → verifier decision
  → 2-of-3 signed quorum
  → escrow release or rejection
  → retention observation
  → final retained release or return

Potential sources are X, Telegram, the public web, project analytics, onchain logs, file evidence, content analysis, and a fraud engine. Each source is independently fallible. Source failure or ambiguity should produce REVIEW_FLAG, not an invented success or an automatic rejection.

Decisions and reason codes

The target domain proof schema has five signed statuses:

• VERIFIED
• REJECTED
• REVIEW_FLAG
• RETENTION_VALID
• RETENTION_INVALID

Non-success results require a known reason code. Reasons cover missing deliverables, creator mismatch, timing, hash mismatch, disclosure, content changes/deletion, prohibited claims, metric inflation, jurisdiction blocks, duplicates, fraud signals, unavailable sources, ambiguous evidence, and manual review.

REVIEW_FLAG is deliberately non-settling. Human review must produce a new attributable decision rather than changing a signed result in place.

Signed payload

The target EIP-712 payload binds the campaign, creator, content hash, outcome, reason, amount, nonce, observation time, expiry, chain, verifying contract, domain name, and version. Any economically relevant mismatch must invalidate the attestation.

The current CampaignEscrow.sol prototype uses a narrower schema with boolean initial approval and boolean retention validity. This is an acknowledged implementation gap: the richer domain schema and Solidity contract must be reconciled and tested before deployment. See EIP-712 proof schema.

Quorum

The prototype verifier registry starts with three distinct, non-zero authorized addresses and requires two valid signatures. Signatures supplied to escrow must be sorted by recovered address, preventing duplicate signers from satisfying quorum. An attestation digest can be consumed only once and must not be expired.

Production requires independent verifier failure domains. Three keys on one host or controlled by one operator are not meaningful quorum. Key custody, rotation, monitoring, source isolation, and manual review authority must be recorded before funding.

Initial settlement

When quorum approves a submitted claim:

1. escrow marks the claim as in retention;
2. 70% transfers to the creator;
3. 30% remains reserved;
4. the retention end timestamp is stored.

When quorum rejects a claim, its full reserved reward returns to the campaign’s unused budget. The prototype does not currently expose a dispute or resubmission path onchain.

Retention settlement

After the retention window, verifiers check that the accepted content remains valid under the campaign terms. If valid, the retained 30% goes to the creator. If invalid, it returns to the project. The retained claim then becomes settled.

The retention mechanism is intended to handle deletion or material invalidation, not give a buyer an indefinite right to reverse accepted work. The period and proof criteria must be clear before funding.

Refunds and pauses

The emergency authority can pause claims, submissions, and settlement on a campaign escrow. The project can refund only the remaining unreserved budget after the deadline. Reserved creator obligations cannot be withdrawn through refundUnused.

Pausing does not resolve obligations by itself. Incident operations must preserve evidence, explain affected state, and define a recovery or compensation path.