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

moderator → CommunityAwardsVault → co-signers → owner final approval → winner

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.

CommunityAwardsVault

Each vault holds one approved ERC-20 reward asset. Moderators may propose an award with an immutable recipient wallet, amount, concise public reason, optional evidence URI, and review deadline. The amount is reserved immediately so concurrent drafts cannot over-allocate the vault.

Co-signers approve onchain first. The owner is deliberately excluded from the co-signer set and must submit the final approval transaction; no moderator or co-signer can execute payment. The owner transaction atomically marks the award executed and transfers the prize. Role or threshold changes advance the signer epoch and invalidate every pending draft, forcing cancellation and recreation against the new signer configuration.

Award reasons and evidence are public and permanent. They must not contain private moderation reports or personal data. One deployment supports one non-fee-on-transfer ERC-20; use a separate reviewed vault per asset and wrapped-native token rather than raw ETH.

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.