ATTENTION, WITH PROOF.System status
This page describes the repository and recorded production state as of 2026-09-03 UTC. It is not a guarantee that an external dependency is unchanged; production operators must re-check live state before a value-bearing action.
Status matrix
| System | Status | What exists | What does not yet exist |
|---|---|---|---|
| Marketing website | Live | raidz.fun, TLS, production Next.js build, truthful pre-launch labeling | Evidence of market demand or revenue |
| Marketplace application | Live foundation | app.raidz.fun, role-oriented interface, Raid directory, persisted Raid Manager, Jobs market, specialist reputation, profile and project views | Funded missions or production settlement workflow |
| Identity API | Live foundation | Sessions, editable creator profile, wallet challenge/verify, X OAuth PKCE, Telegram Login verification, disconnect | Completed production user-consent evidence at scale; full account recovery and deletion workflow |
| Wallet UI | Implemented and configured | Reown AppKit on Robinhood Chain ID 4663; server-issued ownership proof | Custody, token approval, campaign funding, or transaction execution |
| Raidz Reputation V1 | Live foundation | Server-authoritative overall and specialist tracks derived from persisted X/Telegram/wallet evidence, score snapshots and verified delivery; application snapshots; tests | Validated predictive power from real marketplace history; scheduled provider refresh and larger evidence cohort |
| Mission marketplace | UI/API foundation | Demo Signal cards, empty live API response, budget/settlement domain helpers | A funded campaign or verified creator claim |
| Direct creator market | UI/schema foundation | Demo creator cards and service-listing schema | Authenticated booking, service escrow, dispute flow |
| Policy engine | Implemented baseline | Prohibited-claim checks, metric-inflation checks, versioned X jurisdiction rule | Complete legal coverage or automatic legal determination |
| Campaign lifecycle | Live offchain workflow | Persisted Raids and Jobs, applications, owner review, proof, Telegram impact, milestone vesting and entitlement ledgers | Chain settlement and a funded production campaign |
| Verification | Specified | Versioned proof model, reason codes, verifier requirements, contract prototype | Production verifier services, independent keys, manual-review console |
| Escrow contracts | Prototype | Factory, campaign escrow, 2-of-3 registry, fee router, reputation and identity registries; Foundry tests | Deployment, audit, full invariants, production addresses, live funds |
| PostgreSQL | Live foundation | Identity plus marketplace, proof, settlement, attribution, policy, and Pons schema | Proof that all planned tables are exercised in production |
| Redis | Live infrastructure | Private cache/queue dependency and readiness | Durable workflow semantics |
| ClickHouse | Optional profile | Container definition for analytics | Production analytics pipeline and governed datasets |
| Temporal | Planned | Architecture choice and workflow boundaries | Runtime service or workflow implementation |
| Telegram bot | Live | Regular bot, deep links, commands, rate-limit foundation, channel administration | A crypto Mini App, custody, trading, or autonomous paid actions |
| Pons V2 reads | Specified/pinned | Address and bytecode provenance registry; required ABI fragments | Current launch approval, $RAIDZ token deployment, launch transaction |
$RAIDZ token | Gated | Utility and economic design; readiness checklist | Contract address, total supply confirmation, trading venue, funded rewards |
| Attribution | Implemented domain model | Consented click/registration/activation/wallet/onchain envelopes, retention and dedupe rules | Production collection service or validated causal measurement |
| AI campaign agent | Planned | Product requirements | Automated planning or deployment |
Public claims that are safe today
- Raidz has a live pre-launch website and application foundation.
- The repository contains tested identity, score, policy, lifecycle, analytics, attribution, and Solidity prototype code.
- X, Telegram, wallet, database, bot, and operational runtime integrations are configured according to recorded deployment evidence.
- Demo missions and profiles demonstrate intended behavior only.
Claims that must not be made today
- That
$RAIDZis deployed, tradable, purchasable, or has an official contract address. - That a displayed mission is funded or a displayed creator is verified.
- That contract code is audited or production-safe.
- That Raidz has realized campaign revenue, profit, or validated score performance.
- That Pons launch access, configuration, audit status, or economics are current without a fresh read.
Sources of truth
For product intent, use the master plan. For implemented behavior, source and tests win. For deployment state, use a dated deployment receipt and verify the live endpoint. For external/onchain state, use a fresh authoritative read plus a receipt. Chat, screenshots, and UI fixture data are never sufficient evidence.
Key records are ROADMAP_STATUS.md, the repository-root DEPLOYMENT.yaml, and the dated files under reports/.