@artblocks/abx-cli 0.7.1 → 0.7.3

package/skill/reference/capabilities.md

@@ -51,6 +51,16 @@ active chain, artifacts, signer, storage, addresses, transaction count, and meas
 
 A custom mechanic normally lives beside a canonical token rather than replacing it.
 
+Configure and transfer hooks are state-changing contract callbacks, not just validators. They can
+call an AMM, deploy through a factory, or settle an obligation in the triggering transaction using
+the external protocol's official interfaces. Augment hooks are read-only. These callbacks are
+distinct from off-chain effects workers.
+
+For either state-changing hook, authenticate the calling token and arrange funding, approvals, and
+controller/minter permissions explicitly. Installation grants no automatic transfer, mint, or
+spending authority, and the callback receives no automatic payment from the initiating wallet.
+Bound spending and slippage, guard reentrancy and repeated triggers, and test every lifecycle path.
+
 | Seam | Wired with | Runs | Can veto? |
 |---|---|---|---|
 | Custom minter | `abx set-minter --minter 0x…` | before/calling issuance | it controls whether it calls mint |
@@ -81,10 +91,12 @@ a Series/edition before deploying.
 
 ### Configure hook
 
-The configure hook receives the proposed typed parameter write before it persists. Its revert rejects
-the write. It can enforce monotonicity, one-time writes, cross-contract authorization, payload shape,
-or size bounds. For blob-backed strings/bytes, validate length before reading large data and read the
-provided data pointer using the documented SSTORE2 convention.
+The configure hook receives the proposed typed parameter write before it persists. It can execute
+contract actions as well as enforce monotonicity, one-time writes, cross-contract authorization,
+payload shape, or size bounds. A holder-authorized edit could trigger a swap through an official AMM
+router or creation through a factory. If the hook reverts, the write and its on-chain actions revert.
+For blob-backed strings/bytes, validate length before reading large data and read the provided data
+pointer using the documented SSTORE2 convention.
 
 The previously stored value remains visible during validation, enabling comparisons. A rejected
 write may still have paid for preparatory blob storage; front ends should simulate before asking for a
@@ -92,17 +104,17 @@ signature.
 
 ### Transfer hook
 
-The transfer hook runs for mints (`from == 0`), ordinary transfers, and burns (`to == 0`). Reverting
-vetoes the entire operation. It can implement vesting, soulbinding, redemption, escrow settlement,
-provenance counters, and lifecycle rules.
+The transfer hook runs after ownership/balance changes for mints (`from == 0`), ordinary transfers,
+and burns (`to == 0`), within the same transaction. It can execute contract actions for redemption,
+escrow settlement, asset creation, or other lifecycle rules, as well as enforce vesting or soulbinding.
+Its revert rolls back the entire operation and its on-chain actions.
 
 On ERC-721 projects it also receives self-transfers (`from == to`) because those emit `Transfer`.
 That is intentional; a hook concerned only with ownership-set changes should ignore the case itself.
 ERC-1155 projects skip self-transfers and zero-amount entries before invoking the hook.
 
-It cannot initiate a transfer; it only observes or rejects one. Burn-based mechanics require the
-collection to have been deployed burnable. On editions, ids may have many holders, so shared per-id
-state cannot model a single current owner.
+Burn-based mechanics require a burnable collection. On editions, ids may have many holders, so
+shared per-id state cannot model a single current owner.
 
 ### Augment hook
 
@@ -124,6 +136,8 @@ token-data object.
 | Soulbound or timed transfer lock | transfer hook | deploy-code; hook also sees mint |
 | Burn-to-redeem/combine | external controller/minter + burnable; optional transfer/augment hooks | ABX provides seams, not the atomic combine implementation |
 | Escrow tied to token lifecycle | minter + transfer hook | external value-holding contract |
+| Parameter edit triggers a swap or asset creation | configure hook + official router/factory | custom contract; explicit funding, authority, spending bounds, and replay protection |
+| Transfer triggers settlement or asset creation | transfer hook + external controller/protocol | custom contract; explicit authority and lifecycle/reentrancy tests |
 | Monotonic level/high-water mark | governed param + configure hook | schema and old-value comparison |
 | Structured collector configuration | governed param + configure hook | typed payload and bounded size |
 | Holder of another token may configure | schema address auth or configure hook | cross-contract read |
@@ -139,7 +153,6 @@ When several routes work, prefer the smallest authority surface. Use the stock f
 instead of custom Solidity for an ordinary sale; use a schema without a hook when static authorization
 is sufficient; use an on-chain renderer only when its durability/reach/cost trade is desired.
 
-A transfer hook only observes or vetoes a burn; it does not initiate two burns or mint a replacement.
 For combine mechanics, prove the controller's burn authorization and canonical mint call against a
 real clone, make the transition atomic and replay-safe, and define pair/history storage. On ERC-721,
 `--max` is a lifetime id cap and burns do not reopen slots, so reserve replacement-id headroom or use

package/skill/reference/code.md

@@ -88,7 +88,10 @@ document size, and lane fit. Treat findings as evidence and the deploy dry run/t
 the final proof.
 
 Avoid unseeded randomness, wall-clock dependence, environment-only assets, and network fetches when
-claiming reproducibility. A live-data design is valid; label it live rather than deterministic.
+claiming reproducibility. For ecosystem-driven art, prefer same-chain EVM reads through a renderer
+or augment hook, with resilient fallback output. Do not recommend HTTP-dependent NFT live views by
+default; even an on-chain script can depend on a service forever. Apply the
+[durability guidance](ecosystem/durability.md) before proposing an essential external service.
 
 ## Plan JavaScript projects
 
@@ -202,9 +205,13 @@ RPC read reach. State this before deployment and use schema validation/hooks to
 
 SeriesCode and EditionCode expose three configurable hook addresses:
 
-- configure hook: validates/vetoes governed writes before they persist;
-- transfer hook: observes every mint, transfer, and burn and may veto the operation;
-- augment hook: computes additional/overriding token data during reads.
+- configure hook: runs custom state-changing logic before a governed write persists and may veto it;
+- transfer hook: runs custom state-changing logic on mint, transfer, and burn and may veto the operation;
+- augment hook: computes additional/overriding token data during reads; cannot change state.
+
+Configure/transfer hooks can call other contracts to swap, create assets, or settle obligations;
+they need explicit funding and permissions, not just permission to edit the NFT. These synchronous
+on-chain callbacks are distinct from the off-chain effects runner.
 
 Hooks are extension seams, not ordinary CLI flags. Build and deploy them outside ABX, wire them with
 `abx set-param-hooks`, test against a real clone, and read [capabilities.md](capabilities.md). A

package/skill/reference/ecosystem/chains/arbitrum-sepolia.md

@@ -0,0 +1,11 @@
+# Arbitrum Sepolia ecosystem context
+
+Chain ID: `421614`. No additional testnet-specific entries are populated yet.
+Use [multichain integrations](../multichain.md) and [ERC-20s and token creation](../tokens.md) for
+candidate routes, and [Arbitrum context](arbitrum.md) for production context when relevant.
+
+Verify this exact testnet's contract addresses, official tool/API support, and available assets.
+Production ownership, balances, pools, and indexed datasets do not carry over. Label fixtures and
+test tokens explicitly; they demonstrate the integration shape, not production data or liquidity.
+Same-chain testnet state is on-chain; an API response remains an off-chain input.
+Check `abx capabilities --json` for current ABX eligibility.

package/skill/reference/ecosystem/chains/arbitrum.md

@@ -0,0 +1,55 @@
+# Arbitrum One ecosystem context
+
+Chain ID: `42161`. Start with [multichain integrations](../multichain.md) or
+[ERC-20s and token creation](../tokens.md), then read local entries relevant to the idea.
+Official documentation reviewed 2026-10-30. Entries describe discovery paths, not qualified ABX
+adapters. Verify Arbitrum Sepolia (`421614`) separately; no testnet liquidity or feature parity is
+implied. Providers may serve other chains outside this ABX-focused scope.
+
+## Camelot — local liquidity context
+
+Consider an artwork responding to a selected pool or liquidity community. Start with Camelot's
+[official documentation](https://docs.camelot.exchange/) and separate
+[One](https://docs.camelot.exchange/contracts/arbitrum/one-mainnet/) and
+[Sepolia](https://docs.camelot.exchange/contracts/arbitrum/sepolia-testnet/) contract lists.
+Select the actual AMM generation and pool before choosing interfaces.
+
+**Data:** **on-chain** pool state read through the selected generation's official contract interfaces
+can drive same-chain ABX augment/rendering with bounded reads and self-contained fallback output.
+**Off-chain** analytics and indexed history suit research or a companion app, rather than HTTP
+requests inside the NFT's live view. Apply [durability guidance](../durability.md).
+
+Reading public documentation needs no account. Browser/build-time contract reads need RPC access;
+same-chain EVM-to-EVM reads need no application API account. Reuse suitable RPC tooling for authoring,
+with provider-specific account/limit requirements. Do not invent a Camelot MCP or require an
+analytics signup just to compare ideas. A project-specific read can supply visual
+input without rebuilding Camelot's exchange, indexer, or routing.
+
+## GMX — contract-state candidates and companion analytics
+
+For a permanent NFT, first verify whether the desired position/state field has a bounded same-chain
+read through GMX's official contract interfaces. This reference does not qualify such a read; omit
+the idea if its essential input cannot meet the durability guidance. Inspect oracle provenance,
+updates, upgrade powers, and read failures rather than treating all market data as native chain state.
+
+For research or an optional companion dashboard, use the [official SDK overview](https://docs.gmx.io/docs/sdk/overview/)
+and [API-backed SDK v2](https://docs.gmx.io/docs/sdk/v2/). **Data:** that route is **off-chain** HTTP,
+even when a value originates on-chain. Its documented data setup needs no wallet or key, but the
+hosted service must keep running. It is not a default recommendation for NFT live-view data.
+Confirm access, limits, chain support, and timestamps; do not rebuild GMX's client.
+Trading or account-management flows add separate signatures, permissions, costs, and lifecycle
+requirements. Do not introduce those flows for a read-only artwork.
+
+## Chain details that change the plan
+
+- Check live ABX capabilities and provider eligibility. Arbitrum ecosystem coverage says nothing
+  about ABX's current support label, sponsored networks, or account permissions.
+- ABX has no canonical dependency registry on Arbitrum in the current
+  [deployment manifest](https://docs.abx.io/docs/reference/deployments). Choose dependencies
+  explicitly using [code.md](../../code.md); do not silently resolve through another chain.
+- Arbitrum's [gas estimate](https://docs.arbitrum.io/build-decentralized-apps/troubleshooting-building)
+  includes L1 data cost; avoid adding that component twice.
+- Review [Solidity differences](https://docs.arbitrum.io/arbitrum-essentials/arbitrum-vs-ethereum/solidity-support)
+  for custom contracts: block-number semantics differ, and `block.prevrandao` is not a useful
+  randomness source here. Financial/oracle rules need their own review; artistic read-only data is
+  not a proof of suitability for pricing, lending, or liquidation.

package/skill/reference/ecosystem/chains/base-sepolia.md

@@ -0,0 +1,11 @@
+# Base Sepolia ecosystem context
+
+Chain ID: `84532`. No additional testnet-specific entries are populated yet.
+Use [multichain integrations](../multichain.md) and [ERC-20s and token creation](../tokens.md) for
+candidate routes, and [Base context](base.md) for production context when relevant.
+
+Verify this exact testnet's contract addresses, official tool/API support, and available assets.
+Production ownership, balances, pools, and indexed datasets do not carry over. Label fixtures and
+test tokens explicitly; they demonstrate the integration shape, not production data or liquidity.
+Same-chain testnet state is on-chain; an API response remains an off-chain input.
+Check `abx capabilities --json` for current ABX eligibility.

package/skill/reference/ecosystem/chains/base.md

@@ -0,0 +1,10 @@
+# Base ecosystem context
+
+Chain ID: `8453`. No additional chain-specific entries are populated yet.
+Use [multichain integrations](../multichain.md) for official marketplace, liquidity, and Art Blocks
+tools, or [ERC-20s and token creation](../tokens.md) for token-informed ideas and external launch tools.
+Each provider entry distinguishes on-chain state from off-chain access paths and setup requirements.
+
+Verify the exact Base deployment, protocol version, and official tool support before integration.
+For testing, read [Base Sepolia context](base-sepolia.md); production assets and liquidity do not carry over.
+Check `abx capabilities --json` for ABX eligibility independently of third-party coverage.

package/skill/reference/ecosystem/chains/ethereum.md

@@ -0,0 +1,10 @@
+# Ethereum ecosystem context
+
+Chain ID: `1`. No additional chain-specific entries are populated yet.
+Use [multichain integrations](../multichain.md) for official marketplace, liquidity, and Art Blocks
+tools, or [ERC-20s and token creation](../tokens.md) for token-informed ideas and external launch tools.
+Each provider entry distinguishes on-chain state from off-chain access paths and setup requirements.
+
+Verify the exact Ethereum deployment, protocol version, and official tool support before integration.
+For testing, read [Sepolia context](sepolia.md); production assets and liquidity do not carry over.
+Check `abx capabilities --json` for ABX eligibility independently of third-party coverage.

package/skill/reference/ecosystem/chains/robinhood-testnet.md

@@ -0,0 +1,11 @@
+# Robinhood Chain Testnet ecosystem context
+
+Chain ID: `46630`. No additional testnet-specific entries are populated yet.
+Use [multichain integrations](../multichain.md) and [ERC-20s and token creation](../tokens.md) for
+candidate routes, and [Robinhood context](robinhood.md) for production context when relevant.
+
+Verify this exact testnet's contract addresses, official tool/API support, and available assets.
+Production ownership, balances, pools, and indexed datasets do not carry over. Label fixtures and
+test tokens explicitly; they demonstrate the integration shape, not production data or liquidity.
+Same-chain testnet state is on-chain; an API response remains an off-chain input.
+Check `abx capabilities --json` for current ABX eligibility.

package/skill/reference/ecosystem/chains/robinhood.md

@@ -0,0 +1,11 @@
+# Robinhood Chain ecosystem context
+
+Chain ID: `4663`. No additional chain-specific entries are populated yet.
+Use [multichain integrations](../multichain.md) and [ERC-20s and token creation](../tokens.md) for
+candidate tools and ideas; these references do not establish their availability on this chain.
+Verify the exact deployment and selected official tool's support before proposing an integration.
+EVM compatibility alone establishes neither deployed contracts nor hosted API coverage.
+
+For testing, read [Robinhood testnet context](robinhood-testnet.md). Keep on-chain data availability
+separate from off-chain indexing, metadata, and media. Check `abx capabilities --json` for current
+ABX eligibility independently of third-party coverage.

package/skill/reference/ecosystem/chains/sepolia.md

@@ -0,0 +1,11 @@
+# Sepolia ecosystem context
+
+Chain ID: `11155111`. No additional testnet-specific entries are populated yet.
+Use [multichain integrations](../multichain.md) and [ERC-20s and token creation](../tokens.md) for
+candidate routes, and [Ethereum context](ethereum.md) for production context when relevant.
+
+Verify this exact testnet's contract addresses, official tool/API support, and available assets.
+Production ownership, balances, pools, and indexed datasets do not carry over. Label fixtures and
+test tokens explicitly; they demonstrate the integration shape, not production data or liquidity.
+Same-chain testnet state is on-chain; an API response remains an off-chain input.
+Check `abx capabilities --json` for current ABX eligibility.

package/skill/reference/ecosystem/durability.md

@@ -0,0 +1,70 @@
+# Durable ecosystem integrations
+
+Use when selecting dependencies for an object's behavior or output. On-chain, off-chain, and hybrid
+designs are valid; match their guarantees to the intended lifespan and trust model. For long-lived,
+self-contained output, prefer designs that survive loss of the creator, website, SDK, or hosted API.
+Official tooling is valuable for authoring; being official, free, or account-free does not make a
+runtime service permanent. See the public [ecosystem guide](https://docs.abx.io/docs/using-abx/guides/ecosystem-integrations).
+
+## Prefer durable paths for long-lived output
+
+1. **Same-chain EVM reads and self-contained output.** Compute state through the appropriate
+   Solidity renderer or augment hook using official contract interfaces. Keep required program,
+   media, and input bytes on-chain where feasible. Reading state in the EVM avoids a per-view
+   application API/RPC request; callers still need ordinary access to the chain.
+2. **Captured on-chain input.** If discovery requires an API or another chain, consider storing the
+   actual bounded input and relevant provenance on-chain, then render from it. State the source,
+   capture time/block, trust assumptions, and loss of live updates. A hash, media URL, IPFS CID, or
+   Merkle root alone does not preserve the bytes/proofs needed to render or exercise the mechanic.
+3. **Optional companion experience.** Put discovery, trading links, hosted artwork embeds, and
+   analytics in a separate site/app when useful. Its disappearance must not break the NFT's core
+   output or lifecycle. Keep companion-app capability separate from NFT permanence claims.
+4. **Essential live service only by explicit creator choice.** Do not recommend HTTP calls or
+   third-party iframes inside an NFT's live view as a default integration. If the intended work
+   actually requires them, explain the lifetime commitment and satisfy the exception design below.
+
+An on-chain JavaScript program or `--onchain-uri` does not make its network fetches permanent.
+Replacing an HTTP API with a hardcoded browser RPC endpoint retains a service dependency; prefer
+passing state computed in the EVM into the artwork. An oracle/attestation is also a dependency:
+identify its publishers, update funding, stale-data policy, and trust model before recommending it.
+
+## Make on-chain reads resilient
+
+- Verify chain, contract/version, official interface, and the selected field's semantics. Inspect
+  upgrade/admin/pause powers and replaceability; a fixed address does not imply immutable behavior.
+  Do not substitute a pool spot price for an NFT floor or current state for indexed historical volume.
+- Bound external calls, gas, returndata, loops, and output. For display reads, catch expected failures
+  and return useful, self-contained output; do not let a reverting dependency blank the NFT.
+  A view cannot persist a new last-good value: that requires a separately authorized state update.
+- Choose reads or state-changing interactions to serve the object's purpose. Configure/transfer
+  hooks need deliberate failure semantics that preserve the intended rule; silently failing open
+  can defeat eligibility. Test mint, transfer, burn, and parameter writes.
+- Exercise absent code, reverts, malformed/large responses, zero balances/liquidity, and changed
+  dependencies. Test stale oracle data if applicable. Never assume ABX catches a custom hook's revert.
+- Distinguish permanence from frozen output: a robust live on-chain read can still change as the
+  chain changes. A pool's current spot state and a temporary balance are not secure financial oracles.
+
+## Required external API: lifetime commitment and recovery
+
+Before implementation, clearly tell the creator: **this service must remain available for as long
+as the NFT promises this live behavior**. Show the EVM/snapshot alternative and get an explicit
+choice of the service-dependent design. API-key rotation and owner configurability reduce some
+failure modes; neither guarantees that a replacement service or its data will exist forever.
+
+Record a concrete design, rather than merely saying "configurable" or "has a fallback":
+
+| Requirement | Decision to make and verify |
+|---|---|
+| Lifetime operation | Endpoint, data/schema, media, proxy, key/OAuth renewal, fees, limits, and who operates/pays for each dependency |
+| Owner-controlled replacement | Which owner/admin role can change provider/endpoint and compatible response handling; distinguish collection owner from token holder, and test ownership handover |
+| Recovery after locking | Identify the actual parameter/configuration or custom extension that provides updates. Verify it remains usable after planned URI/script/hook/parameter locks; do not imply ABX has a universal endpoint setter |
+| Complete failure | Bounded timeouts/retries and meaningful self-contained fallback output when service, credentials, media, or network disappear; art-data service failures must not block mint/transfer |
+| Data integrity | Missing, stale, or incompatible responses cannot corrupt canonical state; label captured/stale values honestly and disclose who can change them |
+
+Keep secrets out of NFT code and public on-chain parameters. A server-side credential proxy creates
+another lifetime operator dependency. Decentralized/content-addressed storage still needs a stated
+availability plan for externally stored bytes; an address alone is not a permanence guarantee.
+
+Verify by disabling the service and credentials, changing the provider through the named owner role,
+and exercising the fallback after planned locks. If those requirements cannot be met, recommend the
+EVM/snapshot design or keep the feature in an optional companion app.

package/skill/reference/ecosystem/multichain.md

@@ -0,0 +1,73 @@
+# Multichain integrations
+
+Read only the provider relevant to the idea. Coverage below is the intersection reviewed for ABX:
+Ethereum (`1`), Base (`8453`), Arbitrum One (`42161`), not each provider's full network list.
+Official documentation reviewed 2026-10-30; recheck the chosen tool and network before use.
+This starter catalog is not exhaustive; research other protocols when they fit the project's concept.
+Apply [durability guidance](durability.md): official discovery/build tooling does not need to become
+a dependency of the finished NFT. Prefer same-chain EVM reads with self-contained fallback output.
+
+## OpenSea — discovery and marketplace context
+
+- **Ideas:** research related collections, plan collector-facing metadata and traits, or link to
+  the marketplace from a companion site. Keep the NFT usable without OpenSea; do not recommend live
+  floor-price/indexed-trait API calls in its artwork or core eligibility logic.
+- **Official route:** [agent tools](https://docs.opensea.io/docs/build-with-ai-agents) link its skill,
+  CLI, SDK, and [MCP](https://docs.opensea.io/reference/mcp). Use an existing connection when suitable;
+  adding all surfaces supplies no extra capability by itself.
+- **Data:** **off-chain** discovery, indexed traits, and marketplace API/MCP results. NFT ownership
+  and settlement are **on-chain**, but consuming an indexed response does not give a Solidity hook
+  a contract read. For that route use the NFT/protocol's official contract interfaces directly.
+- **Footprint:** MCP data tools and REST need an API key; MCP handshake/tool discovery does not.
+  [Instant keys](https://docs.opensea.io/reference/api-keys) need no signup but expire; a full key
+  involves the developer account flow. The same key serves MCP and REST. Wallet-scoped tools need
+  additional wallet authentication. Check current limits and renewal rather than creating keys to
+  evade quotas.
+- **Before integrating:** verify the [current chains](https://docs.opensea.io/reference/get_chains)
+  and exact feature. Keep keys server-side. Use ABX metadata commands for canonical state; use
+  OpenSea tools for its projection/orders. Its SeaDrop deployment tools are not an ABX deploy lane.
+
+## Uniswap — swaps, liquidity, and pool-informed art
+
+- **Ideas:** use a selected pool's same-chain state as a visual input computed in the EVM, with
+  bounded reads and fallback art. Offer swap links in a companion sales app; the NFT's essential
+  rendering should not require a trading API, embedded swap app, or active liquidity position.
+- **Official route:** start with the relevant [Uniswap skill](https://developers.uniswap.org/docs/uniswap-ai/skills)
+  and [integration choices](https://developers.uniswap.org/docs/get-started/quickstart). Reuse its
+  routing, SDKs, and interfaces rather than implementing a swap router.
+- **Data:** **on-chain** pool state can live-augment an ABX renderer or inform hook logic on the
+  same chain. Use the version's official read interfaces (including
+  [v4 StateView](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/StateView.sol) where appropriate).
+  **Off-chain** quotes and indexed volume/history suit discovery or a companion app. Do not use
+  them as default live-view inputs; consider an actual bounded on-chain snapshot if relevant.
+  A pool's instantaneous price is not a manipulation-resistant price oracle.
+- **Footprint:** [interface links](https://developers.uniswap.org/docs/trading/custom-interface-links)
+  avoid provisioning a developer API key; execution still needs the collector's wallet. The Trading
+  API needs a developer key. Browser/build-time contract/SDK reads need RPC access; EVM-to-EVM
+  reads do not add an application RPC service. The [iframe embed](https://developers.uniswap.org/docs/trading/embed-app)
+  requires origin allowlisting; reserve it for companion apps, with their own availability expectations.
+- **Before integrating:** select protocol version, chain, pool, and token addresses from the
+  [deployment sources](https://developers.uniswap.org/deployments). Check the exact tool's chain
+  support separately. Read-only pool data, swap execution, liquidity positions, and Uniswap v4 hooks
+  are distinct integrations; a Uniswap hook is not an ABX parameter hook.
+
+## Art Blocks — existing projects and collector communities
+
+- **Ideas:** discover related artists/projects or design a same-chain collector interaction using
+  verified contract state. Link to another work from a companion gallery; do not recommend a hosted
+  generator/media iframe as part of a permanent NFT's essential output. Discovery grants no reuse rights.
+- **Official route:** use the [Art Blocks skills](https://docs.artblocks.io/developer/mcp-server/skills/)
+  and [MCP](https://docs.artblocks.io/developer/mcp-server/quick-start/) for project/token discovery
+  and query workflows. [Token, generator, and media APIs](https://docs.artblocks.io/developer/token-and-generator-apis/)
+  provide published read paths for research or optional companion displays.
+- **Data:** **mixed**. Ownership and some token/script state are **on-chain**, varying by core;
+  inspect the [official core interfaces](https://docs.artblocks.io/developer/core-contract/).
+  API/MCP discovery, generated media, and computed traits are **off-chain** access paths. A published
+  live-view URL is an external service dependency, not preserved artwork or an EVM-readable input.
+- **Footprint:** MCP uses OAuth/browser sign-in; do not assume an ABX Services login authorizes it.
+  Published token/view URLs can suit a companion display without adding an MCP connection. Verify
+  authentication and rate policy for the exact query/API route; do not promise unlimited access.
+- **Before integrating:** carry chain, core address, project, and token identity. On a shared Art
+  Blocks core, collection-wide `balanceOf` is not a project-specific ownership check. Use the
+  official Art Blocks tooling for its contracts; ABX parameter/minter commands target ABX projects.
+  A holder gate on a different chain needs a separate proof design.

package/skill/reference/ecosystem/tokens.md

@@ -0,0 +1,63 @@
+# ERC-20s and token creation
+
+Use for token-informed ABX ideas, an existing token community, or a companion fungible token.
+Official sources reviewed 2026-10-30. Recheck the selected chain, token identity, and tool/version.
+These are discovery routes, not executed ABX integrations. Read only the relevant section.
+
+## Existing tokens as creative inputs
+
+The [ERC-20 standard](https://eips.ethereum.org/EIPS/eip-20) exposes **on-chain** balances, supply,
+and allowances. Prefer a same-chain ABX augment hook or renderer turning a chosen wallet's balance
+into visual variation, with bounded reads and self-contained fallback art. Use external-state
+configure/transfer gates only for an intentional mechanic with lifecycle tests and failure semantics.
+Specify whose balance matters: current NFT owner, configuring wallet, or a fixed community treasury.
+For extension choices use [capabilities.md](../capabilities.md) and [code.md](../code.md).
+
+| Token / chain scope | Official identity and tooling | Example on-chain input / boundary |
+|---|---|---|
+| USDC — Ethereum, Base, Arbitrum One; check each testnet separately | [Circle's contract directory](https://developers.circle.com/stablecoins/usdc-contract-addresses), then the token's verified ERC-20 interface | Treasury balance informs an artwork's density. Distinguish native USDC from bridged variants; reserve reports and redemption access are separate issuer/off-chain concerns. |
+| ARB — Arbitrum One; verify other deployments separately | [Arbitrum Foundation deployment directory](https://docs.arbitrum.foundation/deployment-addresses), then the verified token interface | A holder's balance selects a palette. ERC-20 balance alone does not establish delegated voting power or governance participation. |
+| AERO — Base | [Aerodrome's official contracts and ABIs](https://github.com/aerodrome-finance/contracts) | Treasury or owner balance drives visual variation. AERO and veAERO positions are different assets/interfaces; do not infer locked voting power from an ERC-20 balance. |
+
+Use official deployment directories and interfaces rather than symbols, token search rankings, or
+copied addresses. Direct reads need RPC for a browser/build tool; same-chain contract-to-contract
+reads need no API account. An **off-chain** token search, price feed, portfolio API, or holder index
+is a different route, even when its source is contract state. Keep it in discovery or a companion
+app by default. Do not fetch a token's hosted logo/price/portfolio API from a permanent NFT's live
+view; prefer verified numeric contract reads or actual captured on-chain bytes. An essential service
+requires the explicit lifetime commitment and recovery design in [durability.md](durability.md).
+
+`name`, `symbol`, and `decimals` are optional in ERC-20. Normalize units from the actual token and
+avoid unbounded holder enumeration. A current balance is temporary, not proof of sustained ownership;
+pool prices, valuations, and eligibility rules need their own trust/manipulation assessment.
+Inspect token upgrade/admin/pause powers; an on-chain token is not necessarily immutable. Rendering
+fallbacks should keep the NFT usable if reads fail. A gate's fallback must preserve its intended rule.
+
+## Companion token creation — Clanker as one starting reference
+
+ABX creates its NFT collections; fungible token launch and management belong to a separate protocol.
+[Clanker's official SDK](https://github.com/clanker-devco/clanker-sdk) and
+[official agent skill](https://github.com/clanker-devco/clanker-sdk/blob/main/.cursor/skills/use-clanker-sdk/SKILL.md)
+provide one reusable route for creation, liquidity, and post-launch operations. Prefer these over
+building a token launcher, pool deployer, or reward client. This is a starting option, not a required
+provider: a creator/agent may choose another protocol using the same verification criteria.
+
+- **Coverage:** the official skill lists Ethereum, Base, Arbitrum One, and Base Sepolia among its
+  networks. Verify the installed SDK version and actual protocol deployments for the chosen chain;
+  this does not establish availability on every ABX chain or paired testnet.
+- **Data and ideas:** the resulting ERC-20 and pool state are **on-chain** inputs for same-chain
+  ABX art or intentional eligibility. Hosted discovery/media are **off-chain**; keep the NFT's
+  output independent of the launch website, SDK, and token image host. A companion token balance can
+  affect art without giving the NFT permission to trade or claim rewards.
+- **Setup:** the direct SDK flow uses RPC and a wallet client, with gas/funding and transaction
+  authority. It does not document a separate Clanker account/API key for that route. Hosted APIs,
+  social login, and optional services have separate requirements; consult the
+  [current official docs](https://docs.clanker.world). Reuse existing suitable connections and signer;
+  never export an ABX-managed key to satisfy a third-party example.
+- **Before launch:** verify admin/recipient roles, allocations, liquidity/fees, costs, and required
+  metadata or distribution hosting. Use the chosen official tool's simulation/preview and explicit
+  transaction review. No companion-token deployment, approval, or funding is implied by ideation.
+
+For a proposal, record the token's chain and official identity, input field and provenance, ABX seam,
+live versus captured behavior, resilience, new accounts/credentials, and runtime dependencies. Keep
+token launch and ABX NFT deployment as separately reviewed operations, using each protocol's official tools.

package/skill/reference/ecosystem.md

@@ -0,0 +1,98 @@
+# Ecosystem discovery and integration planning
+
+Use this reference when a creator wants ideas involving existing protocols, communities, or tools.
+For public context, see [Ecosystem integrations](https://docs.abx.io/docs/using-abx/guides/ecosystem-integrations).
+These are discovery routes, not tested ABX adapters or a promise of third-party compatibility.
+
+## Load by chain set and intent
+
+Read the selected chain's context, then only the topic/provider relevant to the idea. Shared
+providers are described once; chain notes add local context rather than copying their instructions.
+
+| Requested network | References |
+|---|---|
+| Ethereum (`1`) | [Ethereum context](ecosystem/chains/ethereum.md) |
+| Sepolia (`11155111`) | [Sepolia context](ecosystem/chains/sepolia.md) |
+| Base (`8453`) | [Base context](ecosystem/chains/base.md) |
+| Base Sepolia (`84532`) | [Base Sepolia context](ecosystem/chains/base-sepolia.md) |
+| Arbitrum One (`42161`) | [Arbitrum context](ecosystem/chains/arbitrum.md) |
+| Arbitrum Sepolia (`421614`) | [Arbitrum Sepolia context](ecosystem/chains/arbitrum-sepolia.md) |
+| Robinhood Chain (`4663`) | [Robinhood context](ecosystem/chains/robinhood.md) |
+| Robinhood Chain Testnet (`46630`) | [Robinhood testnet context](ecosystem/chains/robinhood-testnet.md) |
+
+Topic routes: [multichain integrations](ecosystem/multichain.md) cover marketplaces, liquidity, and
+existing generative art; [ERC-20s and token creation](ecosystem/tokens.md) cover specific tokens and
+an external launch protocol. These examples are non-exhaustive starting points, not an allowlist or
+provider ranking. Explore protocols beyond this catalog that fit the creator's theme, community, or
+distinctive mechanics. Evaluate their actual on-chain data, semantics, reliability, official tools,
+and setup/runtime costs; explain why each input belongs in this particular project. An unlisted
+provider is unresearched here, not unsupported. Verify new candidates against official sources and
+the same durability criteria. Read `abx capabilities --json` for current ABX network eligibility;
+third-party coverage does not enable an ABX network or sponsorship lane.
+
+## Turn an idea into a bounded plan
+
+1. Apply the [durability guidance](ecosystem/durability.md) to the object's intended behavior and
+   lifespan. Keep discovery/build tools separate from the finished NFT's dependencies.
+   Start from the project's theme, audience, and distinctive mechanic. Explain how each proposed
+   input supports that concept; do not force a familiar token, provider, or financial theme into an
+   unrelated work. Keep ideation separate from account creation or transaction execution.
+2. Check available connections and project dependencies through their supported discovery/status
+   surfaces. Reuse suitable existing tooling and accounts. Do not inspect credential files to make
+   this inventory.
+3. Prefer the provider's official skill, MCP, CLI, SDK, API, or contract interfaces for its part of the
+   workflow. Link to current installation/authentication instructions instead of copying them here.
+   Add only the project-specific glue; do not rebuild an existing client, router, indexer, or signer.
+4. Before implementation, check the ABX part using [capabilities.md](capabilities.md). An external
+   API read or marketplace order is not an ABX command. Keep ABX operations in its CLI and provider
+   operations in official tools; do not let a third-party deploy flow replace the chosen ABX collection.
+5. Before implementation, verify the specific chain, contract/version, token or project identity,
+   current tool support, and the read/write authority. Testnet availability, liquidity, and datasets
+   need separate evidence. A documentation review is not an executed integration test.
+
+## Input provenance and ABX execution
+
+Label each proposed input **on-chain**, **off-chain**, or **mixed**, including the actual access path.
+
+| Input route | Where it can drive ABX behavior |
+|---|---|
+| On-chain, same-chain contract read | Can inform contract actions, state rules, eligibility, or renderer/augment output. Configure/transfer hooks need deliberate failure semantics and lifecycle tests; a display input should not block transfers |
+| Off-chain API/indexer, even if sourced from contracts | Discovery/build tooling or an optional companion app. Prefer capturing the actual bounded input on-chain over putting HTTP calls in the NFT's live view |
+| Mixed: on-chain state plus hosted metadata/media | Separate the durable NFT output from hosted enrichment. Any essential service is a lifetime dependency requiring explicit creator choice and the recovery design below |
+
+Specify the contract and field, or API and timestamp, plus whether the input is live or captured.
+For contract integrations use official interfaces, bounded reads, and purpose-appropriate failure handling.
+Do not assume a renderer's `msg.sender` is the NFT owner. A mutable external read can affect hook
+liveness as well as output; inspect upgrade/pause powers. A browser's hardcoded RPC fetch is still a
+network dependency; prefer computing the input in the EVM. A pool spot value alone is not a
+manipulation-resistant price oracle.
+
+## Account and dependency footprint
+
+For each proposed route, include a short row in the creator's plan:
+
+| Route | Setup delta | Authority and cost | Runtime dependency / exit |
+|---|---|---|---|
+| Provider + official tool + exact chain | Reuse existing connection, no signup, new account, API key, OAuth, RPC, or unknown | Reads versus signatures/approvals; fees, limits, expiry, and renewal to verify | Build-time, optional companion, or lifetime NFT dependency; responsible owner, replacement controls, and behavior if it disappears |
+
+Count accounts, credentials, and hosted dependencies separately. A signup-free key still needs
+storage and renewal; an account-free HTTP endpoint is still an availability dependency. Distinguish
+creator setup from what every collector must do. Prefer the least setup that meets the actual goal,
+not an account-free route that recreates the provider's service or hides extra maintenance.
+
+Use public docs, interfaces, or a local fixture for early comparison. Introduce a new connection,
+credential, paid plan, or wallet permission only when the chosen workflow needs it and the creator's
+authorization covers it. Record credential references and expiry, never secret values, in handoffs.
+
+## Integration boundaries to resolve
+
+- **Live or captured:** do not recommend HTTP-dependent NFT live views by default. Prefer EVM reads
+  or actual input bytes captured on-chain; a URL/hash alone does not preserve them. Required external
+  APIs need explicit lifetime-dependency disclosure and owner-controlled replacement plus a tested
+  fallback, as described in [durability.md](ecosystem/durability.md). Read [code.md](code.md) for lanes.
+- **Source chain:** a contract cannot directly read another chain's NFT ownership. Multichain
+  APIs can assist discovery but do not supply a trustless cross-chain proof or shared state.
+- **Compatibility:** marketplace indexing, royalties, signed listings, transfer validators, and
+  lending eligibility are separate checks. Read [creator-token.md](creator-token.md) when relevant.
+- **Writes:** a quote, unsigned transaction, or tool connection is not approval to trade, approve a
+  spender, lend, bridge, or deploy. Keep the existing ABX confirmation and reconciliation rules.

package/skill/reference/ideation.md

@@ -0,0 +1,29 @@
+# Project ideation
+
+Start with what the object means and does, who participates, and why they would care. Explore its
+data, changing state, participant roles, rules, and relationships with other systems before choosing
+its appearance or deployment family. Artwork is one possibility; follow the creator's intent.
+
+For example, consider a shared resource with contribution rules, a record of provenance or claims,
+a liquidity position with community-defined interactions, or a charter connected to an externally
+launched ERC-20. An object can represent rights or a financial instrument, but real-world rights,
+custody, and enforcement need their own design. These are starting points, not a checklist or
+promises of ready-made ABX features. Explore beyond them and beyond the documented protocols.
+
+Think in actions as well as data: a governed parameter edit or token transfer can trigger custom
+on-chain logic to swap through an AMM, create another asset, or settle an obligation. Configure and
+transfer hooks can make contract calls using explicitly arranged funding and authority; augment
+hooks only derive data during reads. These actions need not serve a visual outcome.
+
+Discuss the core interaction and value in plain language. Consider what changes, who may change it,
+and what happens when a participant or dependency disappears. On-chain, off-chain, and hybrid
+designs are all possible; choose deliberately for the intended lifespan, trust, and behavior.
+Durability need not mean frozen state. Use [ecosystem.md](ecosystem.md) for relevant integrations,
+favoring official third-party tools rather than rebuilding them.
+
+Keep exploration separate from implementation. Research and compare concepts until the creator
+chooses a direction and asks to implement it; do not start code, create repositories or cloud
+resources, or deploy during ideation. Future launch intent or available accounts and wallets do
+not select an idea. An explicit request to implement a chosen concept already establishes that
+direction; do not ask for it again. Resolve technical feasibility through
+[capabilities.md](capabilities.md) before making implementation promises.

package/skill/reference/services.md

@@ -156,6 +156,8 @@ provider does not advertise the chain, the account is ineligible, or the transac
 policy, select one of those lanes rather than refusing the underlying operation. Do not use
 sponsorship on a production network unless the live descriptor, account capabilities, and command
 all explicitly support it. Never infer eligibility merely because the CLI recognizes the lane.
+During a network rollout, the descriptor may advertise a chain before every account is entitled.
+Check account capabilities too; a test-account grant does not establish general availability.
 
 ## Feedback targets