ATTENTION, WITH PROOF.Security and trust model
Raidz combines social identity, external evidence, automated decisions, and token settlement. The primary security goal is to preserve user intent and economic obligations across boundaries that cannot fully trust one another.
Protected assets
- user identity links, consent, private profile data, and provider tokens;
- campaign terms, creator obligations, evidence, and review decisions;
- escrow balances, verifier keys, emergency roles, fee recipients, and treasury signers;
- official domains, social accounts, bot identity, deployment state, and contract addresses;
- score integrity, policy versions, attribution records, and public claims.
Security controls already present
- Zod validation on public API inputs.
- Parameterized SQL and bounded PostgreSQL pool/statement settings.
- HttpOnly, SameSite session cookie; Secure in production.
- Five-minute, single-use wallet and OAuth challenges.
- Domain/chain/address/time-bound wallet ownership message.
- X OAuth authorization code with PKCE and state.
- Telegram Login HMAC verification with timing-safe comparison and freshness.
- HMAC-pseudonymized social subjects and AES-256-GCM token encryption.
- Structured log redaction for credentials, cookies, and signatures.
- SafeERC20, reentrancy guards, pause control, EIP-712, replay protection, and sorted verifier signatures in contract prototypes.
- Two-step ownership for verifier, fee-recipient, and reputation-attestor administration.
- Read-only secret mounts and isolated Docker networking.
Key trust assumptions
- The web origin, API, database, provider configuration, and runtime secret store are operated correctly.
- X and Telegram accurately sign/return the provider facts the adapter checks.
- The wallet signer controls the linked address at challenge time.
- At least two production verifiers are honest and operationally independent.
- The selected token behaves as expected by SafeERC20 and campaign accounting.
- Robinhood Chain and the verified Pons contracts provide the observed state.
- Privileged owners/emergency authorities are secured and act within documented procedures.
These assumptions are not hidden decentralization claims. The MVP has meaningful offchain trust.
Threats and responses
| Threat | Primary controls | Remaining work |
|---|---|---|
| Wallet phishing or wrong chain | Explicit ownership-only message, domain, chain 4663, nonce, expiry | Transaction simulation and wallet-request UI review for funding |
| OAuth/Telegram replay | PKCE/state, expiring stored challenge, five-minute Telegram freshness | Session rotation, recovery, abuse monitoring |
| Provider token disclosure | AES-GCM encryption, runtime key, log redaction | Rotation, access audit, deletion jobs |
| Sybil or fake audience | Multi-source evidence, score confidence, campaign history | Production graph/fraud engine and appeal process |
| Verifier collusion/key theft | 2-of-3 quorum, registry, EIP-712, expiry, replay prevention | Independent infrastructure/HSM or signer controls, rotation drills |
| Escrow loss/accounting drift | Immutable economics, reserved budget, SafeERC20, reentrancy guard | Audit, invariants, malicious-token tests, reconciliation service |
| Admin compromise | Ownable2Step and separate emergency authority | Multisig/timelock, monitoring, documented role matrix |
| Wrong public token address | Pre-launch fail-closed copy, publication gate | Signed canonical address packet and multi-channel verification |
| External mutation timeout | Stop and query state before retry | Automated receipt reconciliation with safe idempotency |
| Privacy leakage | Minimization, pseudonymization, consent, redaction | Complete retention/deletion implementation and data map |
Value-bearing release gate
Do not enable contract funding until source/schema reconciliation, high-risk tests, independent review, deployment verification, role custody, pause/recovery drills, live balance/obligation monitoring, legal/policy review, and public address verification pass. A locally passing test suite is necessary but not sufficient.
Reporting
Until a dedicated disclosure channel is published, report suspected issues privately through a verified Raidz/Chaos Crew contact and avoid posting secrets or exploit steps publicly. Operators should preserve evidence, contain the smallest scope, reconcile state, and communicate verified facts.