Deployment & integration

Contract addresses are listed on the deployments page as they become available.

Create a custom pool

A personal NFT pool uses the custom-pool factory. Choose the standard or buyback implementation, meet the factory's creation allowance, and supply your inventory. You do not need to deploy a new FWA token, main pool, or randomness subscription for each custom pool.

Start with Create and manage a pool.

Launch a collection

FWAIR campaigns are created through the approved launch manager. The artist needs approval for the campaign terms before creating it. The manager deploys a campaign and its dedicated randomness consumer. Read the FWAIR guide for funding and distribution.

Integrate a main pool

Compile main-pool integrations against FWAV2 and use the ABI and deployment addresses for the target chain. Confirm its linked rewards, randomness service, floor oracle, and purchase notifier. Custom-pool and launch interfaces are separate from the main-pool interface.

Main-pool purchase interface

The current main pool has one payable acquisition entry point. It takes an explicit purchaser and count, and always returns an array of request IDs:

function acquire(
    address purchaser,
    uint256 count,
    uint256 maxAcquisitionFee,
    uint256 minWeightedValue,
    uint256 maxNegativeSlippageBps
) external payable returns (uint256[] memory requestIds);

Use a count of one for a single purchase or a larger count up to the pool limit. Send the count multiplied by the total per-request quote. The purchaser must be nonzero; direct buyers pass their own address and routers pass the intended recipient. Supply the negative-slippage tolerance explicitly. The main pool has no separate acquireBatch or scalar-return overload.

The caller funds the request and receives immediate overpayment refunds. The named purchaser owns allocations, acquisition rewards, later refund credits, and settlement rights. A router does not gain those rights by paying, and must handle any excess ETH returned to it. All requests in one call use the same pool and purchaser; purchasing across pools requires separate calls with each pool's quote and limits.

Read settlementDiscountBps() for the ETH cashout rate and tokenSettlementDiscountBps() for the FWA purchase budget. They are separate, live settlement settings. The token budget is ETH spent, while swap output and minOut are FWA token amounts. For collection eligibility, read both canDeposit(collection) and oracleExemptCollections(collection); an oracle exemption does not grant admission or FWAIR fee terms.

Custom pools retain separate single and batch methods, now with the purchaser as the first argument. Existing deployed pools keep their own implementation and ABI. Use the target's exact interface and decode its return shape instead of assuming every pool follows the main-pool signature.

Index positions by pool address and listing ID, and campaigns by their contract address. Numeric launch IDs are scoped to a manager. The testing guide covers deployment selection, assets, randomness, and settlement checks.

Collections that want to react onchain to a completed purchase can implement the pool's optional settlement notification interface. Read NFT callbacks for the interface, receiver authentication, gas budget, and fallback behavior.

Deploy a separate main pool

A main-pool deployment requires coordinated rewards, randomness, collection admission, and fee routing. V2 also needs its floor oracle and purchase notifier. Its launch manager, authority, wrappers, and strategies bind to the selected pool. The contracts repository's numbered V2 deployment scripts and launch runbook describe that setup; this creator guide does not replace those deployment checks.

The deployment reuses the existing FWA token and market. It does not require a new token supply. Pool-bound reward and randomness accounting, approved token integrations, and fee destinations still need to be wired for the target deployment.