Orochinetwork
Orochinetwork randomness: Orand Use Cases
Orand is Orochi Network’s verifiable randomness service, designed for applications such as digital asset distribution, lottery-related tasks, and game item drops. Its Elliptic Curve Verifiable Random Function (ECVRF) design supplies randomness that can be checked independently or by smart contracts. The consuming application defines how that input determines an outcome.
Asset Draws and Game Applications
- Digital Asset Distribution
- Orand can supply a random input for an asset allocation. The application defines eligible recipients and the rules that turn the input into a selection; supplying randomness and distributing the asset are separate responsibilities.
- Lottery-Related Tasks
- A lottery application can use verifiable randomness as the input to a draw. Its draw rules determine how that value selects an outcome and how any prize is allocated.
- Game Item Drops
- Random values can feed a game’s item-drop calculations. The game defines the drop probabilities and the mapping from random values to items. A proof for the randomness does not establish that the game’s reward logic was executed correctly.
Randomness Verification and Its Scope
Orand organizes randomness into epochs, which can contain batches of random values. An epoch can be verified outside the service or by smart contracts, allowing verification separately from generation.
Random selection and external-data retrieval serve different needs. Orocle, Orochi Network’s oracle service, retrieves and validates off-chain data for smart contracts. That role fits an application that needs information about an existing external state; Orand supplies a verifiable random input for a choice among possible outcomes.
Submission Options and Cost Inputs
- Self Submission
-
The application’s backend requests randomness from Orand, and the submitter sends it to its smart contract. Epochs must be submitted in sequence, beginning with genesis epoch
0. The submitter controls gas consumption. - Delegated Submission
- The user first deposits native token to an operator address supplied by Orochi Network. Orochi Network then handles the submission process automatically.
- Request Submission
- The application requests randomness through Orochi Network’s oracle contract. Orand fulfills the request and submits the randomness to an Orand provider contract.
Orand supports a configurable batching limit for each epoch. Grouping random values into an epoch can reduce costs, while self-submission leaves gas consumption under the submitter’s control.
An Item-Drop Batch With an Epoch Gap
A hypothetical game uses self-submission with a hypothetical batch limit of 16 random values per epoch. All queue and submission states in this example are hypothetical: genesis epoch
0
has already been submitted, making epoch
1
the next required submission.
In the normal case, epoch
1
and its ECVRF proof are ready. The game’s integration checks the proof and expected epoch number before submitting. If that submission succeeds, the game records epoch
1
as submitted and checks for epoch
2
next.
In the gap case, only epoch
2
is ready, while epoch
1
is missing. The game’s local sequence check stops the attempt before submission, leaving epoch
0
as the last submitted epoch. A retry requires epoch
1
and its proof to be available; epoch
2
must follow it.
The 16-value limit controls batching, and gas consumption contributes to submission cost. Changing that limit cannot resolve the missing epoch or determine which item the game’s drop rules award.
updated