Many smart contracts need randomness.
Games need fair outcomes. NFT drops need unpredictable rarity. Protocols need unbiased selection.
But randomness on-chain is harder than it looks.
Block data can be manipulated. Pseudo-random functions are predictable. And deterministic execution makes true randomness impossible inside the EVM.
For many Web3 applications, randomness needs to be secure, unpredictable, and delivered in a way smart contracts can safely consume.
That's where the Kurier Random Hash Oracle comes in.
The Kurier oracle allows smart contracts to request random hashes through a simple subscription-based workflow, making it easier to build applications that depend on fair and unpredictable outcomes.
Why Smart Contracts Need Verifiable Randomness
Randomness is a foundational primitive for many Web3 systems.
Common use cases include:
- NFT trait reveals
- On-chain games
- Lotteries and raffles
- Random participant selection
- Governance mechanisms
The challenge is that blockchains are deterministic systems.
Every node must arrive at the same result when executing a transaction. That makes generating secure randomness directly inside a contract extremely difficult.
Instead, smart contracts request randomness from an oracle.
The Kurier Random Hash Oracle provides a structured way to do exactly that, allowing contracts to safely request and receive random hashes through an oracle fulfillment workflow.
Quickstart: Adding Randomness to a Smart Contract
The integration flow for the Kurier Random Hash Oracle looks like this:
- Create and fund a subscription with the oracle coordinator
- Deploy a consumer smart contract linked to the subscription
- Authorize the contract to use the subscription
- Call
requestRandomHash()from the contract - Receive the random hash through an oracle callback
Once configured, your contract can safely request randomness whenever it needs it.
Architecture: Random Hash Oracle Request Flow
The Kurier Random Hash Oracle follows a simple request → fulfillment pattern.
What happens step-by-step
- A smart contract requests randomness
- The coordinator registers the request
- Oracle infrastructure detects the request event
- A random hash is generated
- The oracle fulfills the request
- The smart contract receives the random value
This request → fulfillment pattern allows randomness to be delivered safely while keeping smart contracts deterministic.
Step 1: Create and Fund a Subscription
Randomness requests are paid for through a subscription.
Each request draws funds from the subscription balance using the network's native token.
First, create a subscription through the oracle coordinator contract. This returns a subscriptionId, which will be used throughout the rest of the setup.
Next, fund the subscription.
Once funded, the subscription can pay for randomness requests from authorized contracts.
Step 2: Implement the Consumer Smart Contract
Your smart contract acts as a consumer of randomness.
The contract must:
- Store the subscription ID
- Store the coordinator contract address
- Expose a function that forwards randomness requests
Calling the request function registers a randomness request with the Kurier Oracle coordinator. The coordinator schedules the request and eventually calls your contract back with the random hash.
Step 3: Deploy the Consumer Contract
Once the contract logic is implemented, deploy the consumer contract.
Typical constructor parameters include:
- The subscription ID
- The oracle coordinator address
These values allow the contract to communicate with the oracle service.
Step 4: Authorize the Consumer Contract
After deployment, the consumer contract must be authorized to use the subscription.
You can confirm authorization afterward. Requests will fail unless the contract is added to the subscription.
Step 5: Request a Random Hash
Once everything is configured, your contract can request randomness.
The oracle workflow then executes:
- The contract sends a randomness request
- The oracle generates a random hash
- The coordinator fulfills the request
- The contract receives the randomness via callback
The random hash can now be used inside your contract logic.
Request Costs
Random hash requests are paid from the subscription balance.
Each request typically includes:
- A fixed oracle fee
- Gas costs for the callback execution
The coordinator reserves funds based on the callback gas limit and settles the final cost once the request is fulfilled.
Developers can query the coordinator contract to estimate request costs before submitting transactions.
End-to-End Integration Checklist
Most teams integrate the oracle using the following flow:
- Select the oracle coordinator deployment for your network
- Create a subscription
- Fund the subscription
- Deploy a consumer contract with the coordinator address and subscription ID
- Authorize the consumer contract
- Call the randomness request function
- Receive the random hash via oracle callback
Once configured, your contract can safely request randomness whenever needed.
Practical Use Cases
The Kurier Random Hash Oracle enables several Web3 application patterns.
On-Chain Games
Games can request randomness for mechanics like loot drops, combat outcomes, or player rewards. Because the randomness comes through an oracle workflow, outcomes cannot be manipulated by players or validators.
NFT Trait Assignment
NFT projects often use randomness to determine token rarity or reveal order. Oracle-delivered randomness prevents predictable trait distribution.
Random Selection in Protocols
Protocols can randomly select:
- Validators
- Reward recipients
- Governance participants
This ensures fair and unbiased distribution.
Troubleshooting Common Issues
"Not authorized consumer"
The consumer contract has not been added to the subscription. Make sure to authorize the contract with the coordinator.
Wallet cannot estimate gas for the request
This often indicates a transaction revert. Check that:
- The subscription is funded
- The consumer contract is authorized
- The callback gas limit is within allowed bounds
Callback fails
This usually means the callback gas limit is too low. Increase the callbackGasLimit parameter when requesting randomness.
Reliable Randomness for Web3 Builders
Randomness is essential for many smart contract applications. But generating secure randomness inside a deterministic system is difficult.
The Kurier Random Hash Oracle provides a structured solution:
- Subscription-based randomness requests
- Oracle-delivered random hashes
- Simple smart contract integration
- Repeatable randomness workflows
Developers can focus on building their application logic while the oracle infrastructure handles randomness delivery.