Project guide

Raidz is designed to help a project buy original creator work with comparable reputation, explicit terms, evidence, and bounded settlement.

1. Establish project identity

Create a project profile and verify control of a relevant website, X account, Telegram community, or contract. Project ownership verification is distinct from a user’s wallet link. The database supports project website, social handles, chain, contract address, verification timestamp, and reputation, but the full verification workflow is not yet implemented.

2. Define the outcome

Choose a goal before selecting creators:

awareness through original content;
research or education;
creative and meme production;
community operations or events;
product testing and structured feedback;
qualified registrations, activations, or onchain actions.

Avoid buying raw engagement. A useful deliverable is observable, attributable to the creator, bounded in time, and assessable without changing the rules after publication.

3. Draft the campaign

A complete draft should specify:

objective, audience, service, channel, and jurisdiction;
exact deliverable and revision limits;
compensation disclosure language;
score and fit requirements;
creator limit and fixed reward;
gross budget and reward currency;
start, deadline, and retention period;
verification sources, pass conditions, and review cases;
refund, pause, dispute, and data terms.

4. Pass policy preflight

The current engine blocks prohibited financial/market-integrity claims, paid metric inflation, and a versioned X paid-crypto jurisdiction rule. A successful automated preflight does not prove legal compliance. Rules can change, so the policy version and evaluation time belong in the campaign record.

5. Fund and deploy

The prototype contract computes an 8% marketplace fee and transfers the remaining 92% to a campaign-specific escrow. It rejects over-allocation and requires positive budget/reward, a future deadline, a non-zero creator limit, and valid dependency addresses.

No contracts or $RAIDZ token are deployed today. Do not transfer funds to an address merely because it appears in a draft, screenshot, or chat message. Production funding requires published verified addresses, review closure, simulation, signer controls, and a reconciled receipt.

6. Track work

Projects should see claimed positions, deadlines, submitted hashes/URLs, rule results, fraud signals, verifier state, reserved obligations, released amounts, retained amounts, and refunds. These records are represented in the schema but are not yet delivered as a persistent production dashboard.

7. Review results

Verification is evidence-bound. An operator or buyer cannot silently override a signed economic outcome. Ambiguous evidence goes to manual review; a new attributable decision is required. Projects should not receive raw creator private data when a normalized result is sufficient.

8. Repeat based on qualified evidence

Compare cost per accepted deliverable, verified campaign value, qualified outcomes, creator reliability, dispute rate, repeat rate, and retention—not impressions alone. Attribution indicates an observed path under a stated model; it does not automatically prove causation.

Current availability

Campaign planning UI, policy preflight, economics helpers, lifecycle logic, schemas, and contract prototypes exist. Persistent campaign creation, production funding, verifier operation, settlement, and analytics remain pre-launch.