What this example shows
- requesting one random number
- storing request metadata keyed by
requestId - authenticating the callback caller
- rejecting unknown or already-settled requests
Minimal consumer
Required guards
1
Authorize the callback
Reject any callback where
msg.sender is not the configured coordinator.2
Validate the request ID
Reject callbacks for request IDs that were never created or already settled.
3
Keep settlement deterministic
Persist state and derive outcomes without unnecessary branches or external calls.
Why the request is stored after creation
The request and callback happen in separate transactions. As soon asrequestRandomNumberWithTraceId returns, store the metadata you will need later to settle the request.
Typical fields include:
- player or account
- match or session ID
- user choice or wager
- settled flag
Implementation notes
Next steps
Consumer patterns
See common mappings from request IDs to users, rounds, and outcomes.
Coordinator reference
Look up the exact function signatures and config fields used in this example.
Callback security
Review the callback guardrails before adapting the example to production logic.
Troubleshooting
Diagnose fee mismatches, unauthorized callbacks, and pending requests.