From a trade
to a work of art.

01 · The idea

Trading funds art. A holder receives it.

The proposed 2o1 token trades on Pons, on Robinhood Chain. Part of the trading fees builds a budget to buy NFTs on Ethereum. Each funded round selects a collection and an eligible token holder. The purchased NFT goes to that holder.

The founding 2o1 Patrons NFTs have a different role: registered NFTs share the Patron allocation in ETH. Holding a Patron NFT and holding the token are two separate ways to participate.

1. 01 / Robinhood ChainTrading fees

   Pons routes creator receipts to the fee router.

2. 02 / AcrossFunds cross chains

   The art and Patron budget moves to Ethereum.

3. 03 / EthereumDraw & purchase

   A funded round selects a holder and buys an NFT.

4. 04 / The recipientArt in a wallet

   The winner receives the artwork on Ethereum.

02 · Trading fees

Creator income. Three destinations.

FeeRouter assigns 5/47 of creator receipts to the team and bridges the rest. PatronsVault assigns 5/42 of the funds received to Patrons and 37/42 to NFT purchases.

Bridge costs are deducted before the Ethereum split. The table illustrates the same fractions with no bridge cost.

03 · The two contracts

Two chains, distinct responsibilities.

FeeRouter on Robinhood Chain collects and routes creator fees. PatronsVault on Ethereum holds the art budget, accounts for Patron rewards and runs NFT rounds. Across connects the two contracts. Both contracts are deployed on mainnet with verified source code.

Robinhood Chain collects the fees

Pons supports trading on a bonding curve, followed by a pool after graduation. The fee router collects creator receipts from the Pons escrow, accounts for the team share and batches the remainder for bridging. The proposed launch requires Pons buyback to be disabled so these receipts can fund the strategy.

Ethereum holds the budget and the artwork

Across carries the funds to the Patron vault on Ethereum. The bridge worker verifies a finalized destination fill before synchronizing received WETH into the vault’s ETH accounting. A submitted bridge transaction alone does not fund a round.

The vault separates Patron liabilities from the art budget. NFT purchases can spend only the art budget. Bridge costs, finality waits and gas affect what arrives and when it becomes available; there is no guaranteed transfer time.

An unresolved bridge blocks subsequent bridges in the current worker design until it can be verified or investigated. Missing or expired transfers are not counted as delivered funds.

04 · Collections & randomness

The list defines the possibilities.
Randomness makes the selection.

The strategy buys from an explicit, ordered list of NFT collection contract addresses stored in PatronsVault on Ethereum. A collection outside that list cannot be selected. The contract does not search every collection on a marketplace or automatically rank them by price, popularity or trading volume.

Who chooses and edits the list?

The collective’s selection is implemented by the vault’s owner account through setCollections(address[]). Only that account can replace the list. It can add collections, remove collections or reorder them by submitting the complete replacement list in an Ethereum transaction. Token holders, sellers and the keeper do not have this permission merely because they participate.

The current contract has no holder vote or automatic curation rule. Choosing suitable collections is an owner responsibility. An address passing the technical checks does not establish its artistic quality, authenticity, liquidity or fair price.

What makes a valid list?

The ten selected collections are configured in the deployed Ethereum vault. It supports both ERC-721 NFTs and single editions of ERC-1155 collections, including The Memes by 6529 and Proceed w/ Caution.

• Between 1 and 64 distinct collection addresses.
• Each address must contain contract code on Ethereum and report support for the ERC-721 or ERC-1155 interface.
• No duplicate addresses: a collection cannot gain extra weight by appearing more than once.
• The founding Patron NFT contract cannot be included as a purchase target.

Collection approval and marketplace approval are separate. Being on the list makes a collection eligible for selection; a purchase still has to execute through an approved venue and fit the current offer.

When can the list change?

Only while the vault is Idle, between rounds. Committing a holder snapshot moves it into an active round and freezes the list before the VRF response is known. It remains frozen while randomness is pending, during the purchase offer and after purchase until the NFT is delivered.

After delivery, or a valid skip of an unpurchased round that has expired, the owner can update the list for a future round. Pausing does not bypass this restriction. A delayed VRF request cannot be cancelled by editing the list.

1. 01 / Between roundsOwner configures the list

   An onchain transaction sets the ordered collection addresses.

2. 02 / Snapshot committedThe list is frozen

   The keeper commits holder balances and requests randomness.

3. 03 / VRF respondsOne index is selected

   The random value maps to one entry in the frozen list.

4. 04 / Purchase & deliveryThat collection is binding

   A valid sale supplies an NFT from it for the committed winner.

How does randomness select the collection?

Chainlink VRF supplies one random value after commitment. The vault takes the remainder when dividing it by the number of collections, then uses that number as an index into the frozen list. Indices start at zero.

Every entry has equal selection weight: with four collections, each has approximately a 25% chance per round. Collection size, floor price and the winner’s balance do not change these weights. The contract uses modulo reduction of a 256-bit random value; its theoretical rounding bias is negligible.

Is the holder selected in the same way?

The same VRF response drives both selections, using different calculations. For the collection, the contract uses the random value modulo the list length. For the holder, it hashes that value with a fixed tag, then maps the result into the total eligible token balance. A holder’s committed balance range determines whether they win.

The collection draw is equally weighted across listed collections. The holder draw is weighted by token balance. Neither the keeper nor the seller supplies their preferred collection or winner once the result is fixed. Read how holder balances and proofs work below.

Does VRF select the individual NFT too?

No. VRF fixes the collection and the winning holder. A seller or bot submits a specific token ID and an executable sale from that collection, within the rising offer and through an approved venue. The vault checks delivery of that exact NFT. It does not randomly choose a token ID or certify the cheapest listing.

If no valid sale is submitted, the vault cannot switch to another collection in that round. After the one-day purchase window expires, anyone can skip the unpurchased round. A later round needs a new snapshot commitment and VRF request. The same collection can be selected again; there is no rotation or exclusion of previous winners.

How can the list and result be checked?

The owner’s updates emit CollectionsChanged with the complete ordered list. The VRF callback emits RoundSeeded with the random value, selected collection and winning point. Using the list in force for that round, anyone can reproduce the collection index. The current list may have changed since an older round, so its historical order matters. Open the contract directory and verification guide →

05 · The holder draw

Balances first. Randomness second.

A round can begin when the settled art budget covers the configured purchase cap. The keeper records eligible Robinhood Chain balances and commits a cryptographic summary of that snapshot on Ethereum before requesting Chainlink VRF randomness.

The random result selects one collection from the configured list and one point in the eligible balance total. The wallet whose balance range contains that point is the winner. Collections have equal selection weight; holders are weighted by their eligible token balance.

For example, holding 10,000 tokens out of 1,000,000,000 eligible tokens gives a 1 in 100,000 chance (0.001%) in that round. These token amounts are hypothetical, not the announced supply. Tokens are not spent to enter. Later purchases or transfers do not change a committed snapshot.

Which addresses qualify?

Addresses with code on Robinhood Chain, including some smart wallets, are excluded. Protocol infrastructure addresses, the fee router and the burn address are also excluded. The prize destination is the same address on Ethereum.

What can be verified?

Round snapshots are intended to be published so anyone can reproduce the commitment and winning balance range. VRF makes the random result verifiable; it does not prove that the keeper supplied a complete or accurate holder snapshot. Snapshot integrity remains a keeper responsibility. Follow the recorded VRF request and fulfillment →

06 · Buying the artwork

An offer that rises over time.

Once randomness arrives, the vault opens an ascending purchase offer, sometimes called an inverse Dutch auction. It starts at zero and rises linearly toward the purchase cap over a configured duration, measured in seconds.

For illustration, a 10 ETH cap over 100 seconds gives a 5 ETH offer after 50 seconds and a 10 ETH offer after 100 seconds, provided the budget covers it. These are example settings, not approved launch parameters. Contract arithmetic rounds down to whole wei.

Anyone can submit an executable sale through an approved marketplace. The NFT must belong to the selected collection, the value sent must fit the current offer, and the vault must receive the exact NFT. The caller cannot change the winner or redirect the prize.

The offer stays capped until the seeded round expires one day after randomness arrives. It is zero while purchases are paused or after expiry. Each new round starts its own clock.

Only configured Ethereum ERC-721 and ERC-1155 collections are eligible. Each purchase buys one NFT or one edition. The founding Patron collection cannot be a purchase target. Read maxPrice() and auctionDuration() on the deployed vault to check the current purchase settings.

07 · Delivery & the next round

The artwork follows the proof.

After purchase, anyone can submit the winning holder’s snapshot proof to trigger delivery. The vault checks the proof against the committed round and winning balance range, then sends the NFT to that address on Ethereum. The caller pays transaction gas; the winner does not have to submit the delivery transaction.

If no purchase happens within one day of the random result, anyone can skip the expired round. The unused art budget remains available. An already purchased NFT cannot be skipped into a new draw: it remains assigned to the committed winner.

A pending randomness request has no equivalent timeout escape in the current vault. If VRF is delayed, that round waits. After delivery or a valid skip, a new round can begin if funding and execution conditions are met. There is no fixed draw schedule.

08 · Patron payments

An equal share per registered NFT.

The Patron portion of received funds accrues equally across registered Patron token IDs. It is separate from the holder draw and from the art budget. A newly registered token participates in subsequent income, not earlier allocations.

The intended experience is automatic ETH delivery to the NFT’s current owner on Ethereum. A dedicated service checks accrued balances and sends payments when the configured minimum and gas budgets allow. Its wallet pays gas separately from the vault’s reward liabilities.

Anyone can also trigger the contract’s distribution function. The caller cannot choose a different recipient or amount. If a wallet rejects ETH, its unpaid balance is preserved for another attempt. Owners retain a manual claim fallback, which requires their own transaction and gas.

Payments depend on actual fee income and service operation. They are not a fixed yield, a promised return or an instant payment after every trade. Automatic delivery is implemented but requires a compatible vault and an explicitly activated service for production.

09 · Controls & dependencies

What the system relies on.

The keeper

Commits eligible balances and initiates the draw. Public purchase and delivery functions do not remove this snapshot authority.

The owner

Can change the keeper, collection list, approved purchase venues, cap and auction duration between rounds. Can pause new commitments and purchases. Existing Patron claims and prize delivery remain available.

Chainlink VRF

Supplies randomness after commitment. A delayed callback delays the draw and the purchase clock.

Across & the networks

Provide the bridge and transaction settlement. Fees, finality, outages and bridge failures can delay funding.

Sellers & transaction senders

A valid sale, a funded gas payer and a delivery transaction are still needed. Permissionless execution does not guarantee that someone will execute it.

10 · Verify onchain

The addresses.
The evidence. The reads.

Use the directory below to inspect the published contracts and follow the recorded randomness request. Production and testnet entries are labelled separately.

11 · Before launch

The design is ahead of the launch.

The repository contains the fee router, vault, rising purchase offer, payout service and bridge worker implementations. Local tests and rehearsal evidence do not establish that the production strategy is live or independently audited.

• Confirm Pons receipts and the final allocation of all creator income.
• Publish the official token address; the two verified mainnet strategy contracts are listed above.
• Review the configured collections, purchase cap and auction duration before activation.
• Complete production review, snapshot publication and round execution operations.
• Configure and fund the bridge, randomness and payout services.

There is no official token purchase address on this page. Launch details will be announced through the collective’s channels and reflected on the token page.

12 · Common questions

A few useful distinctions.