TLDR
The Project is a decentralized pack protocol on Robinhood Chain. Buyers pay a fixed price for a pack and receive one item drawn from an on-chain vault of NFTs and tokenized assets. Collectors supply those items at prices that RWA token holders approve, and a shared USDG reserve backs every payout. Each draw uses a public drand beacon, with odds weighted so the average item's approved price matches the pack price.
After a draw, the buyer either keeps the item or cashes it out for USDG from the reserve. If they keep it, the reserve pays the depositor for it. Pack sales top the reserve back up, and anything above its target goes mostly to RWA buybacks, with a smaller cut to the team.
The contracts can't be upgraded, and no admin key can move funds, change the odds or cancel a vote. Listings, collections and settings are decided by holder votes.
The problem
Buying a pack from a seller means taking their word. They run the draw, so buyers can't check the odds. They price what goes inside. They decide whether they'll buy anything back and whether they can afford to, and they can rewrite the rules whenever they like. The Project puts each of those pieces into public contracts that anyone can inspect.
The pack price stays fixed. When inventory changes, the odds adjust instead, which keeps the average approved price of a pull equal to the pack price.
How it works
The diagram follows one pack from listing to payout, with the USDG flows on the right.
When a buyer cashes out, the item goes back into its band and can be drawn again. It only leaves inventory when someone keeps it, and that is when its depositor gets paid. Buyers and depositors also earn RWA rewards along the way.
Packs and randomness
Tiers and bands
Items are grouped into price bands. The band boundaries and the maximum item price are set in code, and each pack tier is priced at one of those boundaries. Holders can turn tiers on or off by vote, but they can't change the prices.
How the odds are set
For a pack at price P, bands at or below P form the LOW side and bands above it form the HIGH side. Inside a side, each band's chance is proportional to the sum of 1/price over its items, and every item in a band is equally likely. The chance q of drawing from the HIGH side then balances the average outcome to the pack price:
μL and μH are the expected prices of a LOW and a HIGH draw. If either side is empty, the odds usually can't balance, so the purchase is refunded in full.
Current odds can be read on-chain at any time. Each draw is calculated against the inventory at the moment it settles, so the odds can move a little within a batch as items are taken.
The draw, step by step
- Buy. The buyer pays in USDG. If a batch is open, the purchase joins it. Otherwise it waits in line until a processor opens the next batch.
- Join window. A batch stays open for a short window that holders control and holds a limited number of purchases. It closes early if it fills up or has to turn someone away. Inventory is frozen until the batch is done.
- Commit. Anyone can then seal the batch, which locks it to a drand round a few seconds ahead.
- Prove. Once drand publishes that round, anyone submits its signature, and the contract verifies it against the League of Entropy evmnet key.
- Settle. Each purchase gets a rank derived from the beacon and its own ID. Inventory is sorted by price, and the rank picks a spot in it, so low ranks land on cheaper items and high ranks on pricier ones.
- Refund if stuck. If a purchase isn't admitted in time, or a batch gets no proof before its deadline, the buyer gets the full price back as USDG credit. Once a proof is accepted, refunds are off the table.
These steps are open to anyone, and the people who run them (processors) get paid for it. A small part of every pack price goes into a processor pool, which reimburses each call's gas cost plus a margin set by holders. Gas is priced with Chainlink's ETH/USD feed and capped per call, and anything in the pool above a holder-set ceiling flows to the reserve. Buyers never pay for a batch's setup. A draw usually settles within seconds of its batch closing, though backlogs or processor outages can slow it down.
Keep or cash out
After a draw, the buyer has a set amount of time to keep the item or cash out for part of its approved price in USDG.
| Outcome | Buyer gets | Depositor gets | Reserve pays |
|---|---|---|---|
| Keep | The item, delivered to the buyer's wallet | A fixed share of the approved price plus the listing fee back, in USDG, and keep rewards | The depositor's payout and the fee |
| Cash out | A fixed share of the approved price in USDG | The item returns to the back of its band's queue, still listed | The buyer's cash-out |
| No choice in time | Anyone can trigger the cash-out, and the USDG still goes to the buyer | Same as cash out | The buyer's cash-out |
| Batch refunded | The full pack price as USDG credit | Nothing changes | Nothing |
The buyer's cash-out share is slightly lower than what a depositor receives on a keep, and both are set in code. A keep only goes through if the item actually reaches the buyer's wallet. If delivery fails, nothing changes hands and the buyer can cash out instead.
Buyers can also sign their choice off-chain and have someone else submit it. The signature doesn't name a recipient, so the item or USDG always goes to the buyer.
A buyer who cashes out every pull gets back less than the pack price on average, and the difference funds the reserve and the processors. Kept items average out to the pack price in approved value, but what they resell for depends on the market.
Wrapped tokens work the same way. Keeping one gives the buyer a receipt that can be redeemed for the exact tokens inside.
The reserve
One shared USDG reserve pays every keep and cash-out, and the contracts won't allow a draw it couldn't cover. It starts with the team's launch funding. Pack sales refill it up to its target, and anyone can forward what sits above that.
Where a pack payment goes
A pack payment splits in two. A small fixed bounty goes to the processor pool, and the rest goes into the reserve, which then pays out the keep or cash-out on whatever was drawn. Both payouts are a fixed share of the item's approved price and sit below it. Since the average pull is worth the pack price at approved prices, the reserve comes out a little ahead on an average pack, and further ahead when the buyer cashes out than when they keep.
Listing fees go into the reserve once a listing is approved and come back out if a buyer keeps the item. Processor-pool credit above its ceiling flows in too.
Coverage rules
- Batch cover. A purchase only gets into a batch if the free reserve could pay for the most expensive items that batch might draw, each at the most a keep could pay, on top of payouts already owed.
- Item cover. When a batch starts, each band looks at its most expensive item. If the free reserve doesn't cover it a fixed multiple over, the item is parked in the band's queue, and if the next item is still uncovered the band sits that batch out. That caps how much of the reserve a single draw can take. The multiple is the same one the reserve target uses, so a reserve sitting at its target can cover every approved item.
- Parked items. A parked item goes to the back of its band's queue and earns no emissions while it waits. It barely delays the covered items behind it, and it returns to the draws once the reserve covers it.
Target and overflow
The reserve target is whichever is larger, a minimum that holders set or a fixed multiple of the highest approved price. When the free reserve climbs above it, anyone can forward the excess. Most goes to RWA buyback auctions and a small share goes to the team wallet. A higher minimum means a bigger cushion, and forwarding starts later.
Listing an item
Anyone can list an NFT from an approved collection, or a wrapped-token receipt, at a price within the protocol's range. RWA holders then approve or reject that price.
- Deposit. The depositor sends the item to the vault, proposes its price and pays a USDG listing fee. The fee is held aside until the vote decides it.
- Approval vote. The vote opens by itself with a small block of Yes votes already cast. It runs longer for high-priced items, and the price passes if Yes is at least equal to No.
- Activate. Anyone activates an approved listing. It joins its band, or that band's queue if the band is full or a batch is running.
- Earn. While active in the draws, the listing earns RWA rewards.
- Exit. It leaves when a buyer keeps it, when the depositor withdraws it, or when holders vote to remove it.
Listing fee
The fee is the greater of a flat minimum and a small share of the price, with a hard cap as a share of the price. Holders can reprice it by vote, but never above the cap and never to zero.
Each listing keeps the fee it paid, and a deposit reverts if the fee has gone up past what the depositor agreed to. On an approved listing, the fee joins the reserve and comes back only if a buyer keeps the item. A rejected listing gets its fee refunded. The exception is a listing that an overwhelming majority voted down, which starts a follow-up vote on whether the deposit was a deliberate mispricing. That vote starts weighted against a finding, and the fee is only kept on a Yes.
Withdrawals and removals
The depositor can withdraw any listing still in the vault, and the item always returns to the depositor. If the item is in a running batch, the withdrawal waits for that batch to end. Should the batch draw the item, a cash-out completes the withdrawal and a keep sells it.
Some time after approval, any holder can challenge a listing by burning a removal cost. The removal vote starts weighted against removal and needs a strict Yes majority. A removed item leaves all future draws, and its depositor can withdraw it.
Band caps
Each band takes a limited number of active items, with tighter limits for expensive bands. The caps bound the work in each batch and how many expensive items earn emissions at once. Holders can raise them up to a hard limit. Approved items beyond the cap wait in their band's queue, first in, first out.
Wrapped tokens
An approved ERC-20 can join the same inventory. A holder locks an exact amount in the wrapper and gets back an ERC-721 receipt. Its on-chain metadata names the token and the amount and carries the token's branded image. The receipt lists and draws like any NFT. If holders later vote a token out, new listings of its receipts are refused, but open listings continue and every receipt stays redeemable.
Token and incentives
RWA is a fixed-supply governance and reward token. Most of the supply is set aside for user rewards, and no more can ever be minted. The supply only goes down, through buybacks and the burns that come with governance.
Emissions
Rewards flow out of the pool continuously. Each stretch of activity releases a small share of what's left, so emissions start at their highest and taper off over time.
| Recipient | Share | How it is split |
|---|---|---|
| Pack buyers | The largest share | Shared among buyers by their pack purchases |
| Active listings | A small share | Shared among listings active in the draws |
| Kept listings | A small share | Shared among depositors whose items were kept |
Rewards don't vest, and a single claim collects everything earned. Holders can change the emission rate and the split by protocol vote.
Buybacks
Most of the reserve overflow pays for reverse auctions, where bidders offer RWA in exchange for a lot of USDG. Anyone can start an auction once the lot is big enough. Each lot is a small share of the USDG waiting, capped in size and spaced out, so buyback spending stays steady.
Bidding runs for a fixed period, and the bids offering the most RWA per USDG win. Part of the RWA bought is burned, and the rest returns to the rewards pool.
Launch liquidity
RWA's official RWA/USDG pool on Uniswap v4 opens at the token sale's clearing price, rounded so RWA is never cheaper there than in the sale. The pool starts with RWA only, laid out as a ladder of price positions that a locker contract holds for good.
Swap fees go to the team wallet.
Governance burns
Voting costs RWA. Every ballot burns a small fixed share of its weight from the voter's stake, and opening a vote burns that vote's proposal cost.
Governance
RWA holders run the Project by staking and voting, and no admin key can override them.
Every action starts with staked RWA except the curator's, and the curator can only add to the allowlists.
Staking and voting
Holders stake RWA in the voting contract, and that stake counts in every open poll. A ballot can carry any weight up to the holder's stake. It locks the stake until the poll ends and burns a small share of its weight, though the full weight still counts. Thresholds are shares of total RWA supply, including RWA still in the rewards pool.
| Vote | Opened by | Cost to open | Length | Passes when |
|---|---|---|---|---|
| Listing approval | Automatically, on deposit | Free, but the USDG listing fee applies | Short, longer for high-priced items | Yes at least equal to No, starting with some Yes votes |
| Mispricing finding | Automatically, after an overwhelming No | Free | Short | Yes above No, starting with some No votes |
| Listing removal | Any holder, some time after approval | A proposal cost | Short | Yes above No, starting with some No votes |
| Add or remove a collection or token | A holder with a minimum stake | A proposal cost | Short | Yes above No |
| Protocol setting | A holder with a minimum stake | A proposal cost | Several days, set by holders within fixed bounds | Yes above No, and a minimum share of supply voting Yes |
| Shortening the drand lead | A holder with a minimum stake | A proposal cost | As a protocol setting | A supermajority of ballots and a larger share of supply voting Yes |
| Emergency pause extension | Automatically, during a pause | The pause itself burns a fixed amount | One window at a time | Yes above No, and a minimum share of supply voting Yes |
No last-second swings
If a ballot flips a listing, curation or protocol result near the end of the vote, the vote is extended. It happens every time, with no cap. During that overtime each ballot has to meet a minimum size, and stake added after the scheduled end can't vote.
From vote to execution
- A holder with a minimum stake proposes an exact list of calls and burns the proposal cost.
- Holders vote for a period they set themselves, within fixed bounds.
- Anyone queues a passed proposal soon after the vote ends.
- After a fixed delay, anyone can execute it within a fixed window. After that it lapses and holders vote again.
What votes can and cannot change
| Holders can change | Fixed in code or at deployment |
|---|---|
| Pack tiers on or off | Pack prices, band boundaries and the price cap |
| Band caps, up to a hard limit | Draw math and batch order |
| Batch join window, within fixed bounds | Cash-out and keep payout shares |
| Processor pay: price feed, margin, per-call cap and pool ceiling, within fixed bounds | The processor bounty inside each pack price |
| Emission rate and reward split | The listing fee cap and the fee's path |
| Listing fee, up to its cap | Target formula and the cover rule |
| Minimum reserve target, within fixed bounds | The ballot burn, windows and thresholds |
| Proposal costs, up to a cap | The timelock's delay and lapse window |
| Protocol vote length, within fixed bounds | The drand key and round formula |
| drand lead, within fixed bounds | Buyback rules, the team wallet and its share |
| Wait before a removal vote, up to a cap | Contract links, each set once |
| Receipt images for wrapped tokens | |
| Revoking the curator |
The curator
A curator address adds NFT collections and wrapped tokens instantly and at no cost. It can't remove them, and it can't re-add one that holders voted out. Holders can't appoint a curator, but they can revoke the role for good by protocol vote, and after that collections and tokens are added only by holder votes. A curation vote becomes void if its item changes before the vote is finalized, so an old vote can never undo a newer decision.
Emergency pause
Any holder with a minimum stake can burn a fixed amount of it to stop new pack sales, batch admissions and sealing for a short first window. Holders then vote to extend the pause one window at a time. Everything already in motion keeps working. Sealed draws settle, refunds go out, keeps and cash-outs complete, claims, withdrawals and deposits go through, and every vote carries on.
Launch handoff
At launch the deployer schedules a single batch that hands every contract it owns to the timelock, which uses up its one chance to do so. The handoff takes effect after the timelock delay, and from then on only holder votes can change settings. If the batch isn't executed in time it lapses, and holders can restore it by vote.
Architecture and security
The Project's core is a set of immutable contracts built for Robinhood Chain.
The vault contract holds every listed item and the USDG reserve. The other contracts govern it, supply it with items and randomness, or handle rewards and buybacks.
Decentralized by design
- Immutable. No contract can be upgraded.
- Open to anyone. No step needs a privileged caller, so no single processor can stall the system.
- Paid to the owner. Withdrawals go to the depositor, draws to the buyer and claims to the caller, and nobody can redirect them.
- Pull fallbacks. If a USDG payment or a returned NFT can't be delivered, it becomes a claim its owner can collect later.
- Bounded work. Batches, bands and settlement calls all have fixed size limits, so no call's work can grow without bound.