RaidzATTENTION, WITH PROOF.
Open app

Smart-contract reference

The Solidity contracts are pre-deployment prototypes compiled with Solidity 0.8.26 and OpenZeppelin 5.6.1. They are not audited and must not receive real value.

Contract graph

VerifierRegistry ───────────────┐
                               ▼
project → CampaignFactory → CampaignEscrow → creator/project
              │ 8%                 │ 70/30
              ▼                    │ 2-of-3 proof
          FeeRouter                └───────────────

wallet → RaidzRegistry
attestor → ReputationRegistry

CampaignFactory

The immutable factory binds one ERC-20 token, verifier registry, fee router, and emergency authority. createCampaign accepts gross budget, fixed reward, creator limit, deadline, and retention period.

It calculates an 8% fee, validates that fixed rewards fit inside the creator pool, deploys a dedicated escrow, then transfers the fee and creator pool from the project. The project must approve the factory for the gross amount first. The call is atomic: a failed transfer reverts deployment and accounting.

Event: CampaignCreated(campaignId, project, escrow, grossBudget, creatorPool, protocolFee).

CampaignEscrow

Each escrow is immutable for token, verifier registry, project, emergency authority, campaign ID, fixed reward, deadline, retention period, and creator limit.

Claim flow

  • claimPosition() — before deadline, once per address, while limit and funds allow.
  • submitDeliverable(claimId, deliverableHash) — creator-only from Claimed, hash must be non-zero.
  • verifyAndRelease(...) — consumes valid 2-of-3 attestation. Reject returns the reserved reward to unused budget; approve transfers 70% and starts retention.
  • settleRetention(...) — after retention, consumes quorum and sends 30% to creator if valid or project if invalid.
  • refundUnused() — project-only after deadline; transfers only unreserved remainingBudget.
  • pause() / unpause() — emergency-authority only.

External token-transfer paths are reentrancy guarded. SafeERC20 supports tokens that do not return a conventional boolean.

Attestation rules

The contract uses EIP-712 domain RaidzCampaignEscrow, version 1. Initial and retention digests bind campaign ID, creator, deliverable hash, outcome, payment, nonce, and expiry. The call requires at least two signatures, sorted by recovered address. Only authorized verifier signatures count; a digest is single-use.

The domain-level target schema also includes numeric status, reason code, and observed time. This contract must be reconciled to that schema before deployment.

VerifierRegistry

The registry starts with exactly three distinct verifier addresses and constant quorum 2. Its two-step owner can add or remove verifiers, but cannot remove one if doing so would leave only the quorum count. Quorum independence is operational, not guaranteed by this contract.

FeeRouter

The router holds five non-zero recipients and immutable allocation basis points [5000, 2000, 1500, 1000, 500]. Anyone may call distribute(token); funds always go to configured recipients. The final recipient receives rounding remainder. A two-step owner can replace recipients but cannot change percentages.

RaidzRegistry

Any wallet can link a non-zero hash of its offchain profile and later revoke it. This contract proves only that the wallet wrote a hash; it does not prove the underlying social identity, score, or content.

ReputationRegistry

Authorized attestors can write a creator score 0–1000, non-zero score hash, timestamp, and version. The two-step owner manages attestors. Detailed score components remain offchain.

Missing production controls

Before deployment, at minimum:

  • reconcile proof schema and chain ID assumptions;
  • add comprehensive unit, fuzz, invariant, fork, and malicious-token tests;
  • specify dispute/resubmission and rejected-claim behavior;
  • test fee-on-transfer/rebasing incompatibility or explicitly reject such tokens;
  • assess timestamp, signer compromise, verifier outage, and source outage behavior;
  • define multisig/timelock ownership, emergency pause, recovery, and key rotation;
  • complete independent review and publish source/bytecode/address verification;
  • exercise end-to-end funding, claim, release, retention, refund, and pause on a disposable environment.

See Escrow and verifier requirements for the release gate.