01 / OVERVIEWOne pool. Published terms. One outcome.
SINGULAR runs finite-capacity prize pools on BNB Smart Chain. A pool fixes its prize amount, BNB ticket price, capacity, first-entry duration and protocol fee at creation. Participants buy numbered tickets with native BNB. A full pool requests a random word through the deployed Chainlink VRF provider; the recorded winning ticket's owner can claim the prize.
An incomplete pool that reaches its deadline does not draw a winner. Participants reclaim their original contributions through individual refund claims.
Rules are visible before payment; claims require a separate transaction.
02 / ECONOMICSHow a pool is funded
For each pool, ticket price × capacity = prize + protocol fee. The table gives the intended standard tiers. Existing pilot pools or future pools may have different valid terms; always check the selected pool's onchain values before buying.
| Prize | Ticket | Capacity | Fee | First-entry timer |
|---|
| 0.05 BNB | 0.01 BNB | 6 | 0.01 BNB | 10 min |
| 0.1 BNB | 0.01 BNB | 11 | 0.01 BNB | 10 min |
| 0.5 BNB | 0.01 BNB | 55 | 0.05 BNB | 20 min |
| 1 BNB | 0.01 BNB | 110 | 0.1 BNB | 30 min |
The timer starts with the first confirmed ticket, not at creation. Network gas is additional to the ticket price.
03 / LIFECYCLETwo paths after entry
WAITING→FIRST ENTRY→LIVE→FULL / DRAWING→RESOLVED
The first purchase starts the countdown. Entry closes immediately when capacity is reached. A full pool waits for the VRF callback before a winner is recorded. A partially filled pool that passes its deadline follows a different path: expiry and refund claims, without a winner or protocol fee.
If a full pool's VRF request has no result after 6 hours, contributors may claim refunds. A late randomness callback cannot settle an expired pool. Claims require an onchain transaction and gas.
04 / TICKETSOwnership and odds
Each confirmed purchase receives sequential ticket IDs recorded against the beneficiary wallet. Before resolution, a wallet's theoretical winning probability is its ticket count divided by the pool capacity. More tickets improve the chance but do not guarantee a win unless that wallet owns every ticket in a full pool.
EXAMPLE OWNERSHIP3 tickets
11-TICKET POOL3 / 11 = 27.27%
Purchases require exactly price × quantity in native BNB. The contract rejects underpayment, overpayment and capacity overflow rather than partially filling an order.
05 / RANDOMNESSWinner selection
The deployed provider requests one random word from Chainlink VRF 2.5. After an authenticated callback, the contract computes randomWord % capacity as the zero-based winning index and reads its owner from the ticket ledger. No administrator input supplies a winner or rerolls a completed draw.
Continued VRF operation depends on a funded subscription and the provider remaining an authorized consumer. The request and settlement transaction can be inspected onchain.
06 / RENEWALRecurring pools have a defined limit
A pool created with recurrence enabled creates a new pool with the same parameters after its verified draw succeeds. The successor starts waiting with a fresh ticket ledger; its timer begins on its own first entry.
Expiry is different: an incomplete expired pool does not automatically recreate itself in the deployed contract. New availability after expiry requires a separate creation action.
07 / CLAIMSFunds follow recorded entitlement
After a successful draw, the winning wallet can initiate a prize claim. Another caller may trigger payment for the recorded winner but cannot redirect it. After an incomplete pool's deadline or a 6-hour VRF timeout, each contributor may claim only their own recorded contribution. Claims and refunds are not automatically sent on a timer; the claim transaction requires gas.
08 / ACCOUNTINGWhen protocol fees exist
A fee is realized only when a full pool is successfully resolved. Active entries, unclaimed prizes and expired-pool refunds are separate liabilities, not protocol revenue. Expired incomplete pools realize no fee. Realized fees can be swept to a separate Fee Vault, where the fixed recipient withdraws recorded amounts.
09 / CONTROLAdministrative scope
The constructor-fixed pool creator can create new pools with disclosed terms. The fixed Fee Vault recipient can withdraw realized fees to its own address. Neither can change existing pool rules or tickets, replace the randomness provider, select a winner, reroll a result or withdraw participant liabilities through an administrative function. A new deployment may have different code or rules: always verify the address.
10 / VERIFICATIONHow to check a result
POOL TERMS→TICKET LEDGER→VRF REQUEST→WINNING INDEX→CLAIM
Use the app for a readable view, then check the contract and transactions on BscScan. Verify the fixed terms, ticket ownership, randomness request, selected index and settlement independently.
Pool Manager: 0xe7cbe024811788ed6158c10d3399ab8738ef421d ↗
VRF Provider: 0x4773f2e6ad78103ba47d5219a1a945378a49c840 ↗
Fee Vault: 0xD842BA07dacE4ca7e320B4FD8F2b253061c2ba23 ↗
11 / RISKSLimitations worth understanding
- Smart-contract defects could lock or lose funds; no independent audit is claimed.
- VRF subscription depletion, provider failure or network congestion may delay settlement.
- RPC or indexing outages may delay or omit website history even when contract state is correct.
- Wallet gas costs are separate from the ticket price.
- Legal treatment varies by jurisdiction.
This document explains the deployed mechanism. It does not guarantee profit, availability or instantaneous settlement.
12 / STATUSLive protocol versus future ideas
The native-BNB Pool Manager, VRF adapter and Fee Vault are deployed on BNB Chain mainnet. Pool participation does not require a project token. No official SINGULAR token contract, X account or public Git repository is announced on this site at present. Future token or fee-engine ideas are not part of the live prize-settlement path.
For interaction details, see the technical documentation ↗. Always read the actual onchain terms of the pool you choose.
