ATTENTION, WITH PROOF.Raidz documentation
Raidz is a Pons-native Web3 creator marketplace designed for Robinhood Chain. It connects creator identity and reputation to paid project work, proof verification, token settlement, and a compounding performance record.
The product loop is:
CONNECT → SCORE → RAID → VERIFY → EARN → RANK
Raidz serves two sides of the market:
- Creators connect X, Telegram, and wallet ownership; receive an explainable 0–1000 Raidz Score; find missions or list services; submit original work; and build reputation through verified performance.
- Projects verify their identity; define compliant work; select creators; fund an escrow; track delivery; approve evidence through a verifier quorum; and measure qualified outcomes.
Start here
| If you are… | Read… |
|---|---|
| New to Raidz | What is Raidz? |
| A creator | Creator guide |
| A project or agency | Project guide |
| An integrator | Architecture overview and API reference |
| A contract reviewer | Smart-contract reference and security model |
| An operator | Deployment and runtime and observability |
| Evaluating what is live | System status |
| Mapping every subsystem | System catalog |
Public surfaces
- Website: raidz.fun
- Application: app.raidz.fun
- X: @Raidz_web3
- Telegram: @Raidz_fun
Important current boundary
The public web application, identity adapters, regular Telegram bot, database foundation, score model, policy model, domain logic, and contract prototypes exist. The displayed missions and creator profiles are demo fixtures. There is no deployed $RAIDZ token, live campaign escrow, funded reward pool, official trading address, or proven marketplace revenue. Contract prototypes have tests but have not cleared the independent review required for value-bearing production.
Every page uses the following status language:
- Live — deployed and independently checked in the recorded environment.
- Implemented — present in source and covered by proportionate local tests, but not necessarily exposed as a production workflow.
- Specified — behavior and interfaces are defined; integration may still be incomplete.
- Planned — a roadmap capability, not available today.
- Gated — implementation or execution is intentionally blocked until named conditions pass.
This distinction is part of the product’s trust model. See System status for the component-by-component matrix.