FOSNFT & Processor

Mint entry point

buyAndMint(lotteryType, tokenURI) is called on FOSNFT with type 3, 13, or 25. It checks the next position. Ordinary positions require exact configured ETH price; positions 10, 100, 200, 300, and 400 require zero purchase value. Successful execution mints the NFT, registers the collectible through the authorized FOSNFT→Processor path, transfers the matching cycle contribution, and optionally issues a Verify certificate.

Payment split

Dollar amounts describe the product model, not a dollar-denominated contract balance or guaranteed allocation. Payments and allocations use native ETH. Read the configured on-chain price before sending a transaction; the production USD-to-ETH conversion policy is not supplied in the contract specification.

adminCut = price * adminBps / 10000
prizeShare = price - adminCut

The admin amount is retained in FOSNFT. Free-position pool contributions are paid from its balance. Admin withdrawal must leave sufficient reserves for free positions still to come. Processor must reject a contribution that differs from the cycle's stored contribution. No fee is deducted again when recipient allocations are calculated.

Cycle state

Each collection has separate consecutive cycles. Collectible registration increments the cycle collectible count and purchaseCount[user][type]. At cycle start the capacity, per-collectible pool contribution, recipient group counts/percentages, and double-weighted collectible count are stored for that cycle. Changed settings affect future cycles, except updates permitted for an empty active cycle.

Target capacity is 500; old 20-collectible examples are historical tests. The specification does not supply the full cycle-state ABI or the final bridging callback names, so conceptual lifecycle labels must not be treated as callable methods.

Selection pool

Collectibles 1–100 contribute two weighted entries; collectibles 101–500 one. After selecting a collectible, remove all entries for that collectible before drawing again. Distinct-collectible selection allows the same wallet to be selected via multiple collectibles. Positions 10 and 100 combine zero purchase payment with double weight.

Randomness lifecycle

1. FOSNFT registers collectible 500 with Processor on Robinhood Chain. That cycle closes to further collectibles.
2. A cycle-specific randomness request is sent through Chainlink CCIP to the Base-side integration.
3. Chainlink VRF on Base produces verifiable randomness.
4. CCIP returns the result to the Robinhood-side integration.
5. Processor uses the returned randomness and collectible weights to select 17 distinct collectibles and process allocations.
6. After the selection completes, the next cycle of that collection starts automatically.

The last mint starts this asynchronous sequence. Selection, transfers, and the next cycle do not all finish in the last buyer's transaction. Bridge contract names, callbacks, fee funding, supported CCIP lane, and deployed bridge addresses must be checked against the final implementation; this repository contains documentation, not those Solidity contracts.

Implementation validation must verify request/cycle binding, allowed CCIP sender/source chain, VRF callback authority, replay protection, stale responses, and exactly-once finalization. Those requirements are not claims that an unaudited deployment already implements them.

Allocation and deferred payment

All integer-rounding residue goes to the primary recipient. Direct ETH transfer is attempted; failed transfers are booked in pendingWithdrawals and collected with claim(). A rejected recipient must not be documented as forcing the entire selection to revert.

Unsupported historical assumptions

The supplied update does not establish liquidatePool(), a permissionless selection retry ABI, an 18-transfer gas stipend, fee reimbursement, a metadata-retirement guarantee, or a fixed 100-generation limit. Validate those separately if required. Never replace the specified VRF/CCIP flow with production timestamp/prevrandao selection.