Pricing & allocation

The main pool (V2) prices an acquisition from the expected ETH backing of the position selected, plus the pool's configured surcharge¹. Because lower-backed positions have more selection weight, they have more influence on this price. The calculation does not promise that the NFT's resale value, or the bid you can accept, will cover your acquisition cost.

The surcharge can be divided between depositor fee income and an FWA-buy allowance for a successful purchaser. That division depends on the reward module's activity settings. The protocol acquisition cut is applied separately. See Fees for the distribution and the main pool overview for its policy settings.

The full purchase quote

You pay the pool acquisition fee plus a VRF service fee. The pool has its own service and dedicated Chainlink subscription. The service fee funds callback coverage separately from listing backing and depositor earnings. Any overpayment returns immediately to the caller who funded the transaction. Request-time limits can reject a transaction if the pool moves beyond your bounds before it is mined ².

Choose the recipient and purchase count

Every request names a purchaser. Pass your own address when buying for yourself, or another recipient when buying for someone else. That address receives allocations, FWA acquisition rewards, later refund credits, and settlement rights. Paying for a request does not give the payer those rights when a different purchaser is named.

One acquisition call handles both a single purchase and a batch from the same pool. A count of one opens one request; a larger count opens that many independent requests for the same purchaser, up to the pool's configured limit. The total payment is the count multiplied by the per-request pool and VRF fees. Each request checks price drift at its own ordered processing turn. Only the first request can benefit from time since the previous request when calculating its surcharge allowance; later requests in the same call have a zero-second gap.

Randomness and request order

Chainlink VRF supplies the random word³. The acquisition fee stays escrowed until the request resolves, and requests process in the order they were created. Deposits made while acquisitions remain unresolved join a staging queue. A later request reserves its own bounded batch of staged positions before asking for randomness; an already-issued request cannot adopt newer deposits.

A callback may process ready work directly. Otherwise, a processor advances the next ready or expired request. Anyone can call that onchain processor; it does not choose the random word or skip an earlier request.

Purchase blackout windows

The pool rejects new single and batch acquisitions from 11:45–12:00 UTC and 23:45–00:00 UTC every day. Existing requests can still receive callbacks, process, and settle. These cold windows allow the queue to drain and over-ceiling listings to be removed; they do not guarantee that the queue is already clear.

When a request becomes a refund

• Empty pool. If earlier acquisitions exhaust the eligible active positions, the request's pool fee becomes a withdrawable refund credit.
• Price drift. If the live acquisition fee moves beyond the request's snapshotted tolerances, its pool fee becomes a refund credit instead of allocating a position.
• Late or missing randomness. A word received at the deadline is on time. Strictly afterward, the next unresolved request can expire, release its pool-fee credit, and let later ready requests proceed.

Refunds must be claimed by the named purchaser, even if a different caller originally paid. The VRF service fee is not included because it paid for request coverage. A refunded acquisition earns no successful acquisition FWA reward.