PlatformRandomness
0x22A5Ed6bA91661cd06D68FBa5aae5015EDbF7DA1Use this address for the fastest Testnet experiment. Tx1 creates one request; Tx2 authenticates the three future headers and permanently stores its result.
View Platform on explorerPlatform onboarding
Integrate Monad RNG
Start with the product boundary, choose who the contract records as requester, freeze the platform configuration, then build finalization and permanent settlement as one operated lifecycle.
Live Testnet V1
Start from the attested contracts.
Both contracts are live on Monad Testnet chain 10143, ownerless, frozen, source-verified with an exact match, and tested through real Tx1 and Tx2 flows. The public canary is free; the Factory creates a separately configured instance for each platform.
RandomnessFactory
0x75E6458DaA0c6152419e4617dcf4D459149C1530Call deployPlatform with the recipient, name, price, and pending limit that your platform wants to freeze forever. The Factory retains no ownership.
The complete path
Design past the request transaction.
A request is unfinished until its authenticated result is stored and the application has settled the original business action exactly once.
- 01 · Tx1
Lock the request
Atomically bind payment, eligibility, or inventory to one request. Persist its ID, requester, request block, and three fixed targets.
- 02 · Wait
Wait for the targets
Use block height—not a wall-clock timer. The targets are R+8, R+24, and R+40; requester finalization opens at R+42.
- 03 · Tx2
Authenticate and finalize
Fetch the three exact RLP headers from a checked Monad RPC. Submit them through the stored requester path and preserve the transaction.
- 04 · Settle
Settle from stored result
Wait for finalized confirmation, verify the event against on-chain storage, then settle once from the permanent result.
Start with your role
Four guides, one operating model.
These public Markdown files are generated byte-for-byte from the repository's canonical onboarding documents.
Product leads + technical owners
Decide whether the primitive fits
Set the value ceiling, expiry policy, operating roles, gas budget, and Go/No-Go criteria before implementation.
production-readiness.mdApplication + smart-contract engineers
Build Tx1, Tx2, and settlement
Choose direct EOA or wrapper mode, bind the business action, persist request identity, and settle exactly once.
integration-guide.mdRelease + deployment engineers
Deploy and verify every boundary
Verify chain, approved address, runtime code, frozen settings, source, manifest, and a full canary flow separately.
deployment-and-verification.mdOperators + support teams
Keep requests moving safely
Run finalization, rescue, RPC failover, nonce reconciliation, expiry, monitoring, and incident procedures.
operations-runbook.mdRequester architecture
Choose direct EOA or wrapper deliberately.
Whoever calls PlatformRandomness in Tx1 becomes the stored requester and controls the requester-only Tx2 window.
The Tx1 wallet stays the requester.
- An EOA calls the platform contract directly.
- That same EOA must finalize directly from R+42 through R+103.
- Use only when the business action can safely remain outside the request transaction.
The wrapper—not the player—becomes requester.
- One wrapper call can lock payment, eligibility, inventory, and Tx1 atomically.
- A reviewed
finalizeEntryfunction must forward requester-window Tx2 through the wrapper. - Prefer this mode for paid entries, prizes, mints, assignments, and other value-bearing actions.
From R+104, permissionless rescue may finalize the underlying request directly. The application still has to reconcile and settle the wrapper entry exactly once.
Authoritative lifecycle
Block height is the source of truth.
R is the block containing Tx1. Internal warnings may start earlier, but they never change these contract boundaries.
| Block | What becomes true |
|---|---|
| R | Tx1 locks the business action, stores the requester, and creates one pending request. |
| R+8 · R+24 · R+40 | The three fixed target blocks contribute authenticated proposer entropy. |
| R+42 | Requester-window Tx2 opens. Only the stored requester may finalize through R+103. |
| R+104 | Permissionless rescue opens. Anyone may submit the same proof, but execution is still not automatic. |
| R+8199 | Last contract-valid proof block. Tx2 must be included successfully by this block. |
| R+8200 | Expiry starts. Tx2 is no longer valid; anyone may expire the request, and no result is created. |
Production boundary
Know what your platform must supply.
The primitive authenticates and stores entropy. Product safety, transaction operations, and customer outcomes remain integration responsibilities.
- Not a cryptographic VRFProposer skip bias remains. Set an approved value ceiling and use external VRF or threshold randomness above it.
- Every caller funds its own gasZero protocol fee does not make deployment, Tx1, Tx2, rescue, or expiry gasless.
- No automatic finalization or rescueA funded external operator must submit every Tx2. Permissionless rescue only changes who is allowed to call. That caller can be a browser, script, serverless job, or keeper; an always-on server is not a protocol requirement.
- V1 is ownerless and frozenRevenue recipient, name, price, and pending policy are fixed at deployment. There is no owner, admin, pause, setter, proxy, or upgrade; a mistake or code change requires a new V2 address.
- Free mode needs an anti-spam policy
maxPending == 0means unlimited. A positive free cap can be filled until requests finalize or expire, so add eligibility, economic, or rate controls in the integrating platform. - Revenue has one permanent destinationAnyone may trigger a revenue withdrawal, but the entire balance always goes to the deployment-fixed recipient. The caller cannot redirect it.
- RPC and replacement limits are operational risksProduction needs checked raw-header RPC capacity, timeouts, and failover. Monad public RPC hides pending mempool transactions, so some replacements require manual sender-and-nonce reconciliation.
- The browser is a reference demo, not a production SDKIts localStorage and Web Locks are not a durable journal, shared queue, indexer, keeper, or cross-device idempotency system.
- Only the Testnet baseline is validatedOnly Monad Testnet chain 10143 has been validated for this release. Mainnet needs fresh RPC and EIP-2935 verification, an updated threat model, and an independent security review.
- Expiry is terminalFrom R+8200 the request cannot produce randomness. Expiry creates no result, protocol refund, keeper reward, or later retry right.
Ready to evaluate the flow?
Run the reference path, then build from the guides.
The demo makes Tx1, the target wait, Tx2, stored reads, rescue, and expiry visible. The public artifact supplies the exact ABI and bytecode. Production teams must also verify a raw-header RPC with debug_getRawHeader.