Pool settings & fees
How custom-pool pricing, fees, settlement windows, and platform settings fit together.
These are defaults in the custom-pool contracts and deployment script, not a report of live deployed settings. Shared settings belong to the factory owner; inventory and local purchase access belong to each pool's permanent creator. Read the settings for the pool you are using before submitting a transaction.
Shared economics and access
| Setting | Default | What can change |
|---|---|---|
| Purchase edge | 5% above expected value | Factory owner may set 0% through 10% |
| Edge distribution | Half to owner, half to protocol | Fixed split; the owner also receives all base expected value |
| Inventory cooldown | 5 minutes after a change | Factory owner may set zero through 7 days |
| Buyback ETH split | 90% buyer / 0% owner / 10% protocol | Factory owner may change the shares; they must total 100% |
| Buyer-exclusive choice | 6 hours from allocation | Factory owner may change this to a positive duration |
| Public NFT finalization | 24 hours from allocation | Must remain later than the buyer-exclusive window |
| Beta creation access | Enabled; allowance equals beta-one activations | Factory owner may switch to the ordinary lifetime cap |
| Ordinary creation cap | 1 pool per wallet | Factory owner may set any nonzero cap |
| Creation fee | 0 FWA | Factory owner may set an FWA fee; the dead-address recipient is fixed |
| Protocol fee recipient | FWAV2Buyback after V2 configuration | Factory owner may change the recipient, including for fees awaiting payout |
The infrastructure deployment initially points protocol fees at FWAToken. The V2 configuration script changes the recipient to FWAV2Buyback before purchases open. Read the factory's current recipient for the actual payout destination.
Buyback percentages and windows apply at settlement, including to existing allocations. Keeping the NFT sends the backing to the owner minus the live protocol share. A purchase-edge change 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 fee1.
The deployment script leaves pool creation and global purchases disabled, with new randomness requests paused. Once available, 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.
Technical breakdown
- 1.The service fee is
gas estimate × transaction gas price × (1 + margin) + flat fee. The deployment script sets a 1,500,000-gas estimate, a 30% margin, and no flat fee. These service settings are factory-controlled. Quote using the intended gas price; a refund returns the escrowed pool price, not the service charge. Direct processing remains permissionless if a background processor is unavailable.