ATTENTION, WITH PROOF.System status
This page describes the repository and recorded production state as of 2026-09-04 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, owner-only persisted Raid control room, Jobs market, specialist reputation, profile and project views | Funded missions or production settlement workflow |
| Product analytics | Live first-party foundation | Explicit opt-in, typed creator/project events, server pseudonyms, canonical dedupe, bounded retention, self-service deletion | Qualified real-participant cohort, aggregate operator dashboard, validated conversion or retention |
| Identity API | Live foundation | Sessions, editable creator profile, wallet challenge/verify, X OAuth PKCE, Telegram Login verification, disconnect, proof-based return to an existing identity through wallet/X/Telegram | Completed production user-consent evidence at scale; self-service deletion and reviewed merge workflow for two active profiles |
| 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 | Live two-sided offchain workflow | Persisted live Radar, authenticated applications, Score/connection gates, owner-only Raid selection and applicant review, evidence links, proof accept/reject, private applicant visibility, and creator work timeline | Funded rewards, capacity reservations, disclosure terms, disputes, independent verification, or chain settlement |
| 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 later aggregate analytics | Governed aggregate read models; opted-in operational events currently remain in PostgreSQL |
| 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 preview missions and creator profiles demonstrate intended behavior only; live Radar items are database-backed and explicitly distinguish declared pools from funded rewards.
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/.