Protocol

ABX is a protocol for storing general data on EVM chains as digital assets. A token is the anchor for a set of named, typed pieces of data. Each piece is stored on-chain or off-chain.

The protocol is two things: an event spine and a set of read interfaces. Concrete contracts implement them, and services such as indexers and resolvers read them to track and serve a project. The protocol defines the events and interfaces, not the services or any single implementation. The canonical factory for each chain is the trust anchor: a contract is a canonical ABX contract when that factory deployed it.

How a token resolves

Every field is stored on-chain, computed on-chain, or points off-chain — see Metadata — and a project picks one of two shapes for serving tokenURI (or, on an edition, ERC-1155's uri) itself.

Fully on-chain. No server in the path: an on-chain renderer assembles the JSON from the contract's own fields, so tokenURI is one eth_call away.

Off-chain resolver. A resolver re-indexes the event log and assembles the JSON itself — reading on-chain fields directly from the contract, the same bytes an on-chain renderer would use, and dereferencing off-chain fields from storage. On-chain storage and an off-chain resolver aren't alternatives to each other: a resolver-served project can still keep some or all of its content on-chain.

The effects runner watches the same events, renders derived output such as a still image, and publishes it to both the resolver and storage. See Self-hosting for running these services yourself, and Effects for the protocol model behind the runner.

The extensions

The event spine and interfaces drive the rest of the protocol:

• Metadata: a field-and-representation model. Each field is stored on-chain, points off-chain, or is committed on-chain by hash. tokenURI resolves from a stored pointer or an on-chain renderer. On-chain storage opens up the reader: SSTORE2, chunking, and compression.
• Field renderers: a field whose value is computed on-chain by a contract — the zero-infrastructure lane for generative art (an SVG and traits from the seed + parameters).
• Code projects: a program stored on-chain as content, with declared dependencies and mint-time seeds.
• Parameters: named values at token or contract scope, optionally governed by an on-chain schema and hooks that fold in live chain state.
• Data plane: the full set of named, typed data a token anchors. The ERC-721/1155 metadata JSON is but a projection of this broader spec.
• Effects: off-chain processes that read the spine and produce derived output at a deterministic address.
• Minting: the events a minter emits during a sale.

Core and extensions

The required core is an ERC-165-discoverable ERC-721 or ERC-1155 contract that emits one event, AbxDeployed, used for identity and discovery. A Series is many unique tokens (ERC-721); an Edition is many copies of a token (ERC-1155). Everything else is an opt-in extension: royalties, a primary payee, an external minter, a supply cap (per project on ERC-721, per id on ERC-1155), a pause gate, on-chain script, dependencies, and params. A contract enables the extensions its project uses.

Standard events

ABX emits the standard ERC events with their canonical signatures: ERC-721 or ERC-1155 ownership, ERC-4906 metadata updates (ERC-721 only — an edition uses ERC-1155's native URI event instead), ERC-7572 contract metadata, and ERC-2981 royalties. Existing indexers and marketplaces read ABX contracts through these events without modification. The native ABX events are emitted alongside them, and are described in the event spine.