Pool settings & fees

These are the planned public-launch settings. The 50,000 FWA creation fee and public wallet allowance take effect when activated on chain; this table does not assert that activation has happened. Shared settings belong to the factory owner; inventory and local purchase access belong to each pool's permanent creator. Check the active settings and quoted fee before submitting a transaction.

Shared economics and access

The creation fee is paid once in FWA and sent to the dead address. It applies to both pool types and does not charge existing pools. Purchase and buyback settlement fees accrue separately in ETH, then can be paid to the factory's configured protocol recipient, currently FWAV2Buyback.

Buyback percentages and window durations are fixed for each purchase when its request is accepted. The selected NFT inherits those terms at allocation, and its settlement clock starts then. Later governance changes affect future requests. Keeping the NFT sends the backing to the owner minus that request's protocol share. A change to the additional fee applies immediately to quotes and can cause a pending draw to exceed its price-drift tolerance and receive a refund instead.

Owner choices and fixed rules

• Local purchases, automatic reload, and routing acquisition proceeds to the reload reserve start disabled. A purchase policy starts unset.
• The owner selects inventory and prices or backing. Only ERC721 listings are supported, and there is no collection whitelist.
• Ownership, pool type, and the deployed implementation are permanent. Retirement is irreversible and does not reset the creation allowance.
• Current purchase calls require a nonzero purchaser address. The caller pays and receives immediate overpayment; the named purchaser owns the NFT, settlement choices, and later refunds. Existing pools keep their deployed implementation and purchase interface.
• Standard-pool failed delivery has a fixed seven-day retry window, followed by the buyer's right to request a purchase-price refund.

Requests, queues, and pauses

A transaction can request up to five draws. Each gets an independent Chainlink request, while results are processed in order within its own pool. The shared service initially limits prepared plus outstanding requests to ten per pool and 100 globally. The factory owner may change either limit; zero removes that explicit cap while funding requirements still apply.

The deployment script uses three confirmations and a 30-block randomness deadline. That deadline is measured in blocks, not a guaranteed number of minutes. The pool snapshots a 10% positive price-drift tolerance for each purchase; the buyer supplies the negative tolerance. Timeout, empty-pool, and excessive-drift refunds exclude the separately paid VRF fee¹.

Pool creation, global purchases, and randomness requests have separate platform controls. Opening public creation does not enable a new pool's local purchases. Factory governance can pause requests or purchases and enable a withdraw-only mode. Existing callbacks, processing, settlement, refunds, and withdrawals continue. A permanent shared-service shutdown closes future requests while preserving delivery of stored randomness and pool closeout.

See creating and managing a pool for local controls and buyback pools for the effect of settlement settings.