Testing integrations

Test an integration against the exact contracts it will use: a main pool, a FWAIR campaign, or a custom pool. A local test harness or a selected test-network deployment should reproduce that contract family's assets, configuration, and randomness flow.

Choose the target contracts

Record the chain ID, deployed addresses, implementation version, and ABI for each dependency. Main-pool integrations use FWAV2 and its bound rewards, buyback, randomness, oracle, and notification contracts. FWAIR uses its campaign and manager; custom pools use the appropriate standard or buyback pool and its factory.

Confirm those bindings and read the target's current settings before preparing transactions. Source defaults describe a starting configuration, not the state of a selected deployment. See deployment and integration for the contract families.

Prepare funding and assets

• Fund test wallets with the network's test ETH for gas, purchase payments, backing where required, and the separately quoted VRF fee. Quote with the transaction's intended gas price.
• Use compatible ERC-721 test assets and approve the contract that will take custody. Listing creates the tracked position; a direct NFT transfer does not.
• If your integration moves FWA, verify the target token's transfer permissions as well as balances and allowances. Main-pool rewards and token purchase paths also need the corresponding funded modules and market configuration.

Check collection admission

A main-pool listing needs an admitted collection. Unless an oracle exemption applies, it also needs an accepted, fresh observation and backing within the configured cap. Minimum backing applies either way. A pending oracle challenge is not an accepted observation. Test with the target pool's actual admission settings.

If the integration uses an approved collection oracle exemption, verify admission independently and cover revocation for existing positions. Enabling this setting does not create adapter custody or valuation logic, FWAIR status, or settlement-fee exemptions.

Recognized FWAIR campaign listings receive their launch exemptions through the configured manager and registry. Test the complete approved campaign, NFT escrow, support, randomness, and listing workflow. Custom pools use owner-supplied inventory and do not use the main pool's collection whitelist or floor oracle.

Test randomness and settlement separately

The main pool uses a dedicated subscription. Custom pools share their own randomness service, while each FWAIR campaign has a separately paid, single-use randomness consumer. Use the chain's matching service configuration or the contract family's local test harness.

A transaction receipt confirms the request was submitted; it does not mean an NFT has been allocated. Observe randomness fulfillment and ordered processing separately. Later requests can wait for earlier requests in the same pool. If an automatic processing attempt leaves work ready, exercise the permissionless processing path.

• Buy for the caller and for a different purchaser, using both single requests and batches. Verify that immediate overpayments return to the caller while allocations, rewards, deferred refunds, and settlement rights belong to the named purchaser. Decode the current main pool's request-ID array even when the count is one.
• Cover successful allocation, staged inventory activation, delayed processing, and timeout or price-drift refunds. Verify refund claims separately from the buyer-paid VRF service fee.
• Exercise each supported outcome: main-pool NFT or bid settlement, standard-pool NFT delivery, and buyback-pool NFT or ETH choice. Include the applicable choice windows and delivery recovery.
• Quote main-pool ETH and FWA cashouts independently. Check each live rate at settlement, FWA token output against its minimum, and the actual ETH purchase budget recorded in token-settlement callbacks and FWAIR receipts.
• For FWAIR, verify direct awards, pool settlement synchronization, supporter and artist claims, and refunds for positions left unprocessed at the campaign deadline.

Index contract-scoped records

Key listings by chain ID, pool address, and listing ID. Scope acquisitions to their originating pool and randomness service. Identify campaigns by contract address; numeric launch IDs belong to one manager. Decode events with the ABI for the emitting contract's version.

Keep requested, fulfilled, allocated, settled, and claimed states distinct. Reconcile indexed state with contract reads after delayed processing or recovery, and retain block and log identity so reorgs and repeated syncs do not duplicate balances or outcomes.

Continue with the main pool, FWAIR, or custom-pool guides. The V2 Sepolia deployment provides testnet addresses, fixed-price oracle instructions, and listing requirements.