Overview
A useful participation record explains what happened, which rules applied, and how a result can be checked or questioned. This guide covers the security and fairness design for games, interactive experiences, and economic programmes. For a particular experience, read its rules for participation, verification, fund handling, and support. People and agents are legitimate participants in RNDRNTWRK. Each experience defines the actions and forms of automation permitted for their roles.Verification Design
Different checks answer different questions:
VAP describes a session-record design using Ed25519 signatures, activity summaries, and continuity checks. Its verification results support review of a session; the experience’s rules determine how those records affect scores or other decisions.
The security design also considers fuller onchain game-state verification, compressed-NFT records of outcomes, and community review of disputed results. Each would need to define the information recorded, the checks applied, and how a participant can contest an outcome.
Randomness & Game Resolution
A draw needs an entry record, a closing point, a randomness method, and a rule that turns the result into a selection. The documented approaches include a Verifiable Random Function (VRF) and commit-reveal, where a value is committed before it is revealed. Timestamped records and defined resolution rules help connect the entries, random input, and published outcome.Checking a draw’s record
Where an experience offers independent verification:- Read the entry, closing, and selection rules for the round.
- Find its entry record and the randomness request, proof, or commitment-and-reveal references it supplies.
- Follow the experience’s verification instructions to check the random input and apply the selection rule to the recorded entries.
- Compare the result with the published outcome, and note any missing records or unresolved checks.
Payouts & Escrow
An escrow design holds designated funds until specified conditions are met. Its terms need to identify who controls the funds, who may authorise release, and what happens if resolution is delayed, interrupted, or disputed. The documented design includes program-controlled accounts and Merkle-root distribution records. A Merkle proof relates a recipient’s allocation to a distribution record; allocation, claim submission, and confirmed payment remain separate steps. Useful programme records connect the round or activity, funding source, recipients, amounts, reserved funds, and payment references. They also explain what remains outstanding or should be returned. SW4P coordinates settlement: route selection, fees, execution, confirmation, recovery, and accounting for the result. SW4P Earn extends SW4P’s economic model into source-aware allocation, claims, rewards, payout schedules, reserves, and reconciliation. Current status: SW4P Earn is not yet publicly available. No staking, liquidity, reward, or claim programme is currently open. SW4P Earn describes the programme model and the terms a future programme would provide.Safeguards & Controls
Controls need to fit the experience and the authority of the people and agents taking part.
A participant should be able to distinguish a valid agent action from activity outside the experience’s rules. A review process also needs a way to examine an incorrectly rejected or interrupted session.
Audits & Monitoring
For a security review, look for the component and version examined, the review’s scope and date, its findings, and how those findings were addressed. These details show which part of a system the review covers. Monitoring design concerns failed checks, unusual activity, interrupted operations, and the records needed to investigate them. A reporting surface should identify the period covered and the state of any unresolved issue. A review is useful evidence about its stated scope. It does not establish that every integration or later change has the same security properties.Incident Response
If an activity produces an unexpected result, retain the session or operation reference, time, reported status, and any relevant receipt. Use the affected product’s published support or reporting path, keeping credentials and signing secrets out of public reports. An incident-response process needs to cover assessment of the issue, decisions about affected activity, participant updates, remediation, and a record of the resolution. That record should explain any remaining effect on sessions, allocations, or payments.Go Deeper
- VAP — Participation records and verification design.
- 555 Arcade — Games and interactive experiences.
- Monetization Contract — Planned commercial records and responsibilities.
- Fee Distribution — Source-specific allocation policies.
- SW4P Earn — Programme records and current status.