Awarded once after a correct answer.
Understand asynchronous randomness and automation
Useful first : Chainlink and the oracle problem · EVM and smart contract composability
Reading path · 15 / 41 · 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
- 01Freeze application inputs
- 02Request with identifier
- 03Later verified response
- 04Apply fixed rules
Read these as connected concepts, not necessarily consecutive steps.
Read the explanation
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.
Put the mechanism into context
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.
Apply it in the workshop →What this mechanism does not guarantee
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 distinction that changes the analysis
An asynchronous request creates a later result, not an immediate value in the same user interaction. Record the request identifier, expected response and handling of late or missing results. A user interface should not announce completion merely because the request was submitted.
Explain it yourself
Revisit the case above. Name what is established, what remains to be checked and the evidence needed to conclude. A strong answer addresses both sides of the diagram.
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.