Verifiable randomness is a core primitive for many Web3 applications, from community lotteries and giveaways to games, NFT drops, and probabilistic mechanics. Over the past months, we've been iterating on Randcast Playground to make decentralized randomness easier to try, easier to understand, and easier to build with.
Randcast is an on-chain verifiable randomness service that leverages the ARPA Network to generate decentralized, verifiable randomness. Randomness requests are handled by multiple ARPA Network nodes performing BLS threshold signature tasks. The resulting signature is verified on-chain by the Randcast Adapter contract and then used as input for randomness generation.
The Randcast Playground provides a public interface for interacting with deployed Randcast consumer contracts, allowing users to submit randomness requests and observe on-chain results without deploying contracts themselves.
Recent Updates to the Randcast Playground
The Randcast Playground has recently been upgraded to support a broader range of networks and use cases. A new version of the Playground frontend is now live, making it easier to interact with Randcast across different environments. The Randcast product page has also been updated to make the Playground entry easier to discover.
Alongside the frontend update, new versions of the Playground consumer contracts have been deployed on multiple major blockchain networks, including BSC, Ethereum mainnet, Base, Optimism, Taiko, and the Ethereum Hoodi testnet. These deployments allow users to interact with the Playground directly on their preferred chain while using the same underlying randomness flow and contract logic.
In practice, the Playground is designed to remain lightweight and responsive. Randomness requests are typically fulfilled within around ten seconds, which makes it suitable for live community activities such as lotteries or draws. The cost model is intentionally simple: users pay only for the randomness request transaction, while response callbacks from the trial subscription are free. This helps lower the barrier for experimentation and repeated use.
The upgraded Playground also supports multiple randomness modes that reflect common real-world scenarios. Users can roll dice, draw winners from a pool of tickets, or perform gacha-style weighted draws. These modes are designed to cover a wide range of community lotteries and gaming mechanics without requiring custom contract deployment.
Each randomness request can include an optional message. In practice, this message is often used to store a Merkle root of a ticket list or participant dataset. While the full list remains off-chain, committing its Merkle root on-chain allows results to be publicly verified after the draw, helping improve transparency and fairness in community use cases.
All of the Playground's consumer logic is open source and available. This allows developers to audit the contracts, understand how Randcast is integrated in practice, and reuse or adapt the code for their own applications.
SharedConsumer: A Deployed Randomness Consumer Contract
At the center of the Randcast Playground is a contract called SharedConsumer. SharedConsumer is a ready-to-use randomness consumer built on Randcast and deployed across all supported Playground networks.
The contract is intended to serve two purposes. For communities, it provides an immediate way to run fair lotteries or random draws without deploying custom contracts. For developers, it acts as a reference implementation that shows how Randcast can be integrated into a consumer contract in practice.
SharedConsumer is open source and available.
Rather than abstracting away implementation details, the contract exposes how randomness requests are submitted, how fulfillment callbacks are handled, and how subscriptions are managed across different request types.
Supported Randomness Workflows
SharedConsumer supports three primary randomness workflows that reflect common patterns in community and gaming applications.
The first workflow is ticket drawing. In this mode, a specified number of winners is selected from a pool of tickets, with an upper limit of 1,000 total tickets. This pattern is commonly used for community giveaways, airdrops, and contest-style selections. Once a request is made, the contract emits an on-chain event recording the parameters of the draw, followed by a result event that includes the winning ticket indices after randomness is fulfilled.
The second workflow is dice rolling. This allows multiple dice rolls to be performed in a single request, with configurable dice sizes. Up to 100 rolls can be included in one request, making this mode suitable for simple games, simulations, or general-purpose random number generation. The results are returned as indexed values and emitted on-chain for later inspection.
The third workflow is gacha, which introduces weighted random selection with rarity tiers and upper limits. Each request defines a set of weights that determine how often each tier is selected, along with index ranges that map to specific items. For each draw, the contract emits both the selected tier and the final item index, allowing the randomness process to be verified and audited.
To align with user expectations, indexing starts from 1 across all modes. Across all three workflows, requests and results are linked by a request ID, ensuring a one-to-one correspondence between each randomness request and its fulfillment. Together, these design choices help maintain consistency between displayed results and on-chain events, enabling users to independently verify outcomes on-chain.
Subscription Handling and Cost Model
SharedConsumer supports both trial subscriptions and user-provided subscriptions. In the context of the Randcast Playground, a trial subscription is used so that users only need to pay for the randomness request transaction. The gas cost associated with randomness verification and callback execution is covered by the trial subscription.
This setup is intended to demonstrate how Randcast's subscription mechanism works while keeping the Playground accessible for experimentation and repeated use. Developers integrating Randcast into their own contracts are not limited to this model and can manage subscriptions directly based on their application's requirements.
Contract Design and Architecture
From an architectural perspective, SharedConsumer is designed to handle multiple randomness request types within a single consumer contract. It builds on the Randcast consumer base and incorporates standard upgradeability and access-control patterns.
The contract is upgradeable using the UUPS pattern and includes ownership-based administrative controls. It also demonstrates how to dynamically estimate callback gas requirements and handle fulfillment logic in a way that is compatible with Randcast's two-phase request and fulfillment lifecycle.
For developers, this makes SharedConsumer a practical reference not just for randomness usage, but also for structuring consumer contracts that need to handle asynchronous callbacks and subscription-based costs.
Using the Playground in Practice
For communities, the Randcast Playground provides a way to run transparent randomness processes without deploying custom contracts. Users can select a network, choose a randomness mode, submit a request through the Playground's command-style interface, and observe the result once it is fulfilled.
For developers, the Playground offers a live environment where deployed contracts, real transactions, and on-chain events can be observed. Studying how SharedConsumer behaves in production-like conditions can help inform design decisions when building custom consumer contracts.
A recent example of community usage is the RaveDAO Genesis Rewards Raffle, which used Randcast Playground on BNB Chain to run a gacha-style weighted draw. The raffle relied on on-chain verifiable randomness to ensure that selections were transparent and could not be influenced or manipulated, including by the organizers themselves. The execution was publicly shared by the community for verification.
In this raffle, every Genesis NFT holder was automatically included. Each NFT represented one raffle entry, with selection odds weighted by tier. Higher tiers received higher weights, while all tiers remained eligible. Members holding passes across multiple tiers participated independently in each eligible tier.
The selection followed a two-step weighted randomness model. First, a weighted draw determined which tier would receive a prize. Second, a winner was randomly selected from within that tier. This structure matches the weighted randomness pattern supported in the Randcast Playground's gacha mode, where category selection precedes final result selection, and outcomes can be audited on-chain.
Closing Thoughts
Randomness is one of those primitives that often fades into the background until something goes wrong. In decentralized systems, getting it right is not just about producing a number, but about making the entire process transparent, verifiable, and understandable to anyone who chooses to look closer.
The Randcast Playground is not designed to hide this complexity. Instead, it aims to make it easier to engage with it directly. By working with real contracts, real transactions, and real on-chain results across multiple networks, the Playground offers a practical way to observe how verifiable randomness behaves in live environments rather than in abstract examples.
For some, the Playground may simply be a convenient way to run a transparent draw or community lottery. For others, it may serve as a first step toward understanding how verifiable randomness can be integrated into more complex applications and systems. In both cases, the intent is the same: to reduce the distance between learning, experimenting, and building responsibly on-chain.
As always, users are encouraged to read the code, understand the assumptions being made, and test thoroughly. The Playground is not meant to be an endpoint, but a place to explore, one that reflects how Randcast operates in practice and where clearer designs, better questions, and more informed decisions can begin.
