@artblocks/abx-cli 0.7.1 → 0.7.2

package/CHANGELOG.md

@@ -1,5 +1,15 @@
 # @artblocks/abx-cli
 
+## 0.7.2
+
+### Patch Changes
+
+- d86143f: Add selectively loaded ecosystem discovery references for every selectable ABX network, with shared
+  official tooling, ERC-20 and external token-launch ideas, and input provenance. Favor resilient
+  same-chain EVM reads and self-contained output; disclose lifetime service dependencies, owner-controlled
+  replacement, fallback behavior, and account/credential requirements for service-dependent designs.
+- 6fe1f7c: Broaden skill ideation to programmable digital objects, clarify state-changing hook capabilities, and keep concept exploration separate from implementation.
+
 ## 0.7.1
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@artblocks/abx-cli",
-  "version": "0.7.1",
+  "version": "0.7.2",
   "license": "MIT",
   "description": "Command-line interface for deploying, operating, indexing, and serving ABX projects.",
   "type": "module",
@@ -43,9 +43,9 @@
     "@napi-rs/keyring": "2.0.0",
     "@privy-io/node": "0.34.0",
     "viem": "^2.56.5",
-    "@artblocks/abx-sdk": "0.7.0",
     "@artblocks/abx-indexer": "0.1.8",
     "@artblocks/abx-storage": "0.1.8",
+    "@artblocks/abx-sdk": "0.7.0",
     "@artblocks/abx-token-api": "0.2.7"
   },
   "optionalDependencies": {

package/skill/SKILL.md

@@ -1,15 +1,16 @@
 ---
 name: abx
 description: >-
-  Use the ABX CLI (`abx`) to plan, launch, host, inspect, and operate ABX NFT projects on supported
-  networks: static 1/1s, image series, editions, JavaScript/code drops, and Solidity-rendered projects.
+  Use the ABX CLI (`abx`) to explore, plan, launch, host, inspect, and operate programmable NFT
+  projects on supported networks, from artwork to shared resources and stateful digital objects.
   Covers on-chain and off-chain content, managed or self-hosted resolvers, storage, minting and sales,
   PostParams, hooks, custom minters, migrations, feedback, locks, and capability questions. Use for
   requests to create, deploy, mint, host, serve, verify, repair, migrate, report ABX feedback, or
-  change an ABX collection, or to determine whether ABX supports a mechanic.
+  change an ABX collection, develop project ideas or ecosystem integrations, or determine whether
+  ABX supports a mechanic.
 compatibility: Drives @artblocks/abx-cli on Node 22.13+. Co-versioned with the CLI; install or refresh with `abx skill install`.
 metadata:
-  version: "0.7.1"
+  version: "0.7.2"
 ---
 
 # ABX
@@ -17,6 +18,11 @@ metadata:
 Use `abx` as the execution and truth surface. Help, capability output, dry runs, on-chain reads, and
 typed errors outrank remembered prose.
 
+Think of ABX NFTs as programmable, durable digital objects that use blockchain technology. Their
+data, state, permissions, and behavior can matter as much as their appearance. Configure and transfer
+hooks can execute contract actions, including creating assets or interacting with financial protocols.
+For project ideation, read [ideation.md](reference/ideation.md) before choosing an implementation path.
+
 ## Non-negotiable rules
 
 - Never read or print `.env`, private keys, RPC URLs, provider tokens, storage credentials, wallet
@@ -62,7 +68,7 @@ typed errors outrank remembered prose.
 
 ## Use the lifecycle
 
-Follow this state machine instead of accumulating retries:
+For implementation and operations, follow this state machine instead of accumulating retries:
 
 1. **Discover** — identify the working directory, CLI provenance/version, active chain, artifacts,
    existing contract addresses, configured remote, and signer preference. Run `abx doctor` for a
@@ -73,6 +79,8 @@ Follow this state machine instead of accumulating retries:
    replace an explicit signer choice.
 2. **Classify surfaces** — decide collection shape, runtime, required public surfaces, custody,
    resolution, authority, mutability, and mint/sale timing. Use the model below.
+   For ecosystem integrations, load [ecosystem.md](reference/ecosystem.md); choose inputs that fit
+   the object's behavior and explain ongoing dependencies before choosing third-party tools.
 3. **Inspect** — run `abx capabilities --json`; for code run `abx inspect` and `abx preview`. For an
    existing collection run `abx state`, `abx tokens`, `abx tokenuri`, and `abx verify` as relevant.
 4. **Plan** — use the selected deploy command with `--dry-run --json`. Read its normalized shape,
@@ -191,7 +199,7 @@ Before any real deploy, say these choices explicitly when relevant:
 
 ## Use capability classification, not optimism or refusal
 
-Classify an unusual request as exactly one of:
+When assessing implementation feasibility, classify an unusual request as exactly one of:
 
 1. **Native** — a documented CLI lane performs it.
 2. **Extension** — a custom minter, configure/transfer/augment hook, field renderer, or seed source
@@ -216,6 +224,7 @@ lane. Read [capabilities.md](reference/capabilities.md) before designing a custo
 - Failure classification, resume, RPC/storage/rendering faults, and retry discipline → [diagnose.md](reference/diagnose.md)
 - Capability questions, extension seams, mechanics, and hard boundaries → [capabilities.md](reference/capabilities.md)
 - ERC-721C/ERC-1155C enrollment and validator operations → [creator-token.md](reference/creator-token.md)
+- Ecosystem ideation, official third-party tools, chain coverage, and setup footprint → [ecosystem.md](reference/ecosystem.md)
 
 Read every reference applicable to the requested workflow before sending a real transaction. Do not
 load unrelated references merely because they exist.

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.