Understand asynchronous randomness and automation
By the end, explain the diagram in your own words, solve the case and justify the correction.
Prerequisites : Chainlink and the oracle problem · EVM and smart contract composability
Level 2 · Intermediate →Reading path · 15 / 35 · Intermediate
Smart contracts may need verifiable randomness or an external trigger when a condition is met.
The essentials
Smart contracts may need verifiable randomness or an external trigger when a condition is met. Chainlink VRF provides randomness with a verifiable proof; automation services can trigger predefined contract actions. Both are components of an application rather than guarantees about the whole product.
How it works
A fair random value does not ensure a fair game if the application can discard unfavourable outcomes or change payout rules. Request handling, result consumption and administrative powers need separate examination. Likewise, automating an incorrect condition simply executes the incorrect rule more reliably.
What to watch
Tokenised assets may use published reserve information or net asset values. Assess the underlying attestation, covered assets and update cadence. An on-chain report does not itself establish ownership, absence of liabilities or enforceable redemption rights over assets held outside the blockchain.
Understand the details
Verifiable randomness lets an application verify that a returned random result follows the service’s cryptographic process. The request and fulfillment occur separately, so the application must preserve which request belongs to which game or selection. Automation submits transactions when configured conditions are met; contracts do not spontaneously wake themselves up.
Boundaries and common mistakes
Randomness does not repair unfair rules. Allowing an operator to discard an unfavorable result or change entrants after requesting randomness can undermine the game. Automated execution also depends on funding, gas conditions and valid application state. The execution function should recheck conditions rather than blindly trust an earlier off-chain observation.
The mechanism at a glance
- Freeze application inputs
- Request with identifier
- Later verified response
- Apply fixed rules
Apply the lesson to a case
A raffle closes entries, requests randomness and waits for fulfillment. A second request is later issued for another raffle. Draw identifiers linking each response to its original entrant list, even if responses arrive in the reverse order.
Freeze the eligible entries and selection rules for that request. Match fulfillment by identifier rather than arrival order, and define unavailable-service behavior in advance. A verifiable random number does not prove that the application used it according to its announced rules.
Prepare a correction note
Describe the passage and the proposed correction. This creates a local note for you to share; it sends nothing. Do not include personal or confidential information.