Key points
- Document the approved rules and probability configuration before accepting transactions or entries.
- Bind each business event to one random operation and retain a receipt that can be reviewed independently.
- Confirm jurisdiction, licence, lab certification, disclosure, retention, and player-protection requirements with qualified specialists.
Start with the rule set, not the random value
A fair random value cannot correct an incorrect probability table, an ineligible entry list, or application logic that maps the value to the wrong prize. Version the rules, prize inventory, odds, and eligibility criteria. Record who approved the version and when it became active.
Where a business event must have one outcome, assign an operation identifier before calling the randomness API. Retries should resolve the existing operation or follow an explicit recovery procedure rather than silently drawing again.
Evidence to retain for an outcome review
The review package should connect the business event, rule version, request, random result or result hash, mapping decision, timestamp, and receipt identifier. Access to raw values should be limited when they contain sensitive material, but a verifier still needs enough canonical data to recompute integrity fields.
- Receipt retrieval and hash verification for the selected event.
- Hash-chain position and Merkle membership proof when enabled.
- Application logs showing how the random result mapped to the outcome.
- Export checksum, reviewer identity, and review timestamp.
Licensing and certification remain separate decisions
A licensing-stage operator can use Rantropy to design evidence and technical controls before launch, but the service does not grant a gambling, lottery, or gaming licence. Some jurisdictions require an approved test laboratory, local hosting, source-code review, change control, player disclosures, or regulator access.
The customer remains responsible for confirming that the product, game, promotion, and operating model are lawful in every target jurisdiction. Rantropy can provide technical material and deployment options for review, including isolated infrastructure where the contract and risk assessment justify it.
Run the failure scenarios before launch
Test API timeout, duplicate request, depleted quota, disabled receipt policy, delayed receipt processing, evidence export failure, key revocation, and service scaling. Define whether the business operation stops, waits, or follows a documented fallback. A fallback that changes the source of randomness without disclosure can invalidate the review trail.