Ecosystem integrations

An ABX object can hold data, govern interactions, relate to a community, respond to a pool's state, or trade in that pool itself. Start with its purpose and behavior; its appearance is one part of the design. On-chain, off-chain, and hybrid approaches are possible. For long-lived, self-contained output, prefer same-chain EVM reads and usable fallbacks that survive loss of a website or third-party API.

Read the chain, or act on it

Integration runs both ways. An ABX object can read other contracts: a renderer or augment hook pulls a pool's price, a treasury's balance, or a community token's supply into what it shows. It can also act: a configure hook, transfer hook, or custom minter runs contract calls as a side effect of a mint, a transfer, a burn, or a setting change.

Hooks are contracts you write and attach to a code project (abx deploy-code), so whatever a contract can do onchain, a hook can do. Side effects are atomic: if one fails, the mint, transfer, or edit reverts with it. A hook never gets the holder's wallet. Give it its own funds and approvals, authenticate the calling token, bound what it can spend, and test every path on a fork first. Custom mechanics covers the details.

Use official tools

ABX handles its collection and parameters. Use each provider's official skills, MCP servers, CLIs, SDKs, APIs, or contract interfaces for that provider's workflow. Separate tools used to research or create a project from services the finished NFT would need forever. Official tooling can simplify creation without becoming a runtime dependency. Low setup cost does not establish permanence.

Discover by network and purpose

The agent skill has a context entry for every selectable ABX network: Ethereum, Base, Arbitrum, Robinhood Chain, and each separate testnet. Entries without additional chain-specific research say so and point to shared references. It loads the selected chain and relevant topics, keeping shared providers in one place rather than copying their instructions into each network file.

The examples below are a non-exhaustive starting point, not an approved-provider list or ranking. Countless other protocols and communities may suit your project. Agents should explore beyond these references using official sources, starting from your theme, audience, and distinctive mechanics. Evaluate what the actual on-chain data means, how reliably it can be read, and why it strengthens this particular project. A familiar token or protocol should not dictate the project's concept. Apply the same provenance, reliability, tooling, and dependency checks to every new candidate.

These are discovery routes, not tested ABX adapters or a promise of support on every network. Check each selected tool, protocol version, and exact deployment. Production coverage does not imply the same testnet deployments, assets, or liquidity. An unlisted integration needs research; it is not automatically unsupported. Consult the ABX network summary independently of third-party coverage.

Choose inputs that fit the object

For an on-chain NFT, an ABX Solidity renderer or augment hook can read same-chain contract state live. For example, a community treasury's token balance could change an SVG's density without a hosted data API. State-based rules or eligibility may instead be central to the object. Specify the exact contract, field, and wallet whose state matters; configure/transfer hooks require deliberate failure rules and tests across mint, transfer, burn, and parameter writes.

Label each proposed input on-chain, off-chain, or mixed, and name the access path. An API response remains an off-chain input even when it indexes a blockchain. Solidity cannot fetch HTTP. Use APIs for discovery and creation without making the NFT call them every time it is viewed. For durable output, prefer these options in order:

1. Read the required same-chain state inside the EVM and render self-contained output.
2. Capture the actual bounded input on-chain and render from it, disclosing its source and capture time/block. It is a snapshot, not a live feed. A URL or hash alone does not preserve the input.
3. Keep hosted analytics, trading interfaces, and artwork embeds in an optional companion app whose disappearance leaves the NFT usable.

On-chain reads still need careful design. Check upgrade/admin/pause powers; a fixed address can change behavior. Bound calls, gas, returndata, and output, and return meaningful fallback art on failure. A read-only renderer cannot save a last-good value without a separate state-writing flow. For eligibility gates, define failures without silently bypassing the intended rule.

An on-chain script or on-chain URI does not preserve the network services its JavaScript fetches. A hardcoded RPC URL inside the live view is also a service dependency; prefer state computed inside the EVM. Oracles and cross-chain attestations require their own publisher, update, funding, and staleness assumptions even when the resulting value is stored on-chain.

The initial token references include USDC's official deployments, ARB's official deployment directory, and Aerodrome's AERO contracts. A balance can select a palette or inform eligibility, but token identity, units, chain, and the intended wallet must be verified. Native and bridged assets differ; liquid tokens and locked voting positions differ too. Balance alone does not prove sustained ownership or governance participation.

A companion token is optional. ABX creates the NFT collection; an external protocol creates and manages the ERC-20. Launch it once with the protocol's own tools, or have a hook call the protocol's onchain factory as a side effect, so a mint or a setting change launches a token. Clanker is a general starting reference with official launch and management tools, not a required provider. Agents can use another protocol's official tooling where it fits. Review the token's launch terms, liquidity, and fees on their own, separately from the ABX deployment, even when a hook performs the launch later.

Keep track of setup

Compare accounts, credentials, and runtime services separately. A tool can avoid a new account yet still require an expiring API key, RPC access, or a hosted data service. Check what you already have before adding another connection, and distinguish your setup from what each collector must do.

These official access paths were reviewed on October 30, 2026. Recheck their terms, authentication, limits, and renewal requirements when choosing a route. Documentation discovery does not require creating accounts, minting keys, installing every provider's tool, or granting a wallet permission.

Ask your agent for a small setup summary with each proposal: the selected tool and chain, existing connection to reuse, any new account/key/OAuth/RPC requirement, read or signing authority, cost and renewal work, and whether the deployed project will depend on the service. Keep secret values out of that summary. A simpler setup should also have a clear way to remove or replace the dependency.

Make the integration boundary explicit

An idea is ready for implementation when you can name the input, its provenance, the ABX behavior it controls, and how you will verify both ends.

A live view and its marketplace still can differ until the still is refreshed. Being an NFT does not establish lending eligibility or available offers. Pool spot values and temporary balances need a separate manipulation assessment before they control financial rules. Changing the input can also change the idea: a pool's spot price is not an NFT floor price, and a current contract field does not necessarily reproduce indexed historical volume.

A multichain data API does not let a contract directly read another chain's ownership. A cross-chain holder gate needs a separate snapshot or proof design with explicit freshness and trust assumptions. If a proof is needed, preserving its root alone does not preserve the proof data collectors need.

When a live external service is essential

HTTP-dependent NFT live views are an exception requiring an explicit creator decision. Explain plainly: the service must remain available for as long as the NFT promises this live behavior. Show an EVM or on-chain snapshot alternative before choosing the service-dependent design.

At minimum, establish and verify:

• Lifetime operation: who hosts and pays for the API, media, proxy, credentials, renewals, and updates; what disappears if they stop. A free or signup-free service still needs an operator.
• Owner-controlled replacement: which owner/admin can replace the endpoint/provider and adapt response handling. Distinguish the collection owner from an individual NFT owner, and verify the actual configuration or custom extension rather than assuming ABX provides an endpoint setter.
• Usable fallback: bound requests and timeouts; preserve meaningful, self-contained output if the service, credentials, or media vanish. An art-data API failure must not block minting or transfers.
• Integrity and recovery: handle stale or incompatible data explicitly, keep credentials out of public NFT code, and test replacement after ownership handover and planned locks. A server-side proxy adds another lifetime service; it does not remove the dependency.

Disable the service and exercise the fallback before launch. Owner configurability helps recovery, but cannot guarantee a replacement service or equivalent data will exist forever. If the design cannot meet these requirements, choose the EVM/snapshot alternative or an optional companion app. Externally stored, content-addressed media also needs an availability plan; a CID alone is not a guarantee that the bytes will remain available. Disclose the permanence and control of each surface separately, including any hosted live view, resolver, and marketplace still.

Keep ABX operations in its CLI. A third party's token deployment flow does not create an ABX collection, and a connected tool or unsigned transaction does not authorize a trade or approval. See custom mechanics for ABX extension points and royalty enforcement for transfer-validator choices.