The event spine

The event spine is the set of events an ABX contract emits. With the read interfaces, it forms the ABX protocol. Concrete contracts emit these events, and services such as indexers, resolvers, and render nodes read them to track a project's state.

The spine has two registers: the standard ERC events, and a native ABX layer.

Structure

One project per contract. A project is identified by its contract address. There is no projectId.
A required core with opt-in extensions. The core is an ERC-165-discoverable ERC-721 contract that emits one required event, AbxDeployed. All other events belong to opt-in extensions.
An open set. New extensions can be defined. The ones documented here are the current canonical set.

Two registers

Every state change is announced in both registers.

Register	Read by	Purpose
Standard ERC and OpenSea events	existing indexers and marketplaces	compatibility with tools that have no ABX awareness
Native ABX events	ABX-aware resolvers and render nodes	re-indexing a project's state from the logs

Where a standard already defines a signal, ABX emits it verbatim alongside the native event.

Register 1: the standards ABX speaks

These are emitted with their canonical signatures, so existing indexers read ABX contracts without special-casing.

ERC-721: ownership (Transfer, Approval, ApprovalForAll). A mint is a transfer from 0x0, so no ABX-specific mint event is needed.
ERC-2309 (optional): a batch mint as a single event.
ERC-4906: MetadataUpdate and BatchMetadataUpdate, the metadata-update signal marketplaces read.
ERC-7572: ContractURIUpdated, for contract-level metadata.
ERC-2981: royalty resolution, via the royaltyInfo view.
ERC-7496, ERC-5192, OpenSea PermanentURI, ERC-721-C (optional): on-chain traits, soulbound tokens, frozen metadata, and royalty enforcement.

The current ABX contracts implement a subset of these standards. The others are listed because the protocol is designed to speak them, and future implementations may add them as needed.

Register 2: the native ABX layer

These are opt-in extensions, advertised through ERC-165. Each defines its events and, where it has a read surface, its interface.

AbxDeployed: the one required event, emitted once at deploy. It is an open discovery signal: a resolver finds ABX contracts by watching this event, and any implementation may emit it, including custom ones. It signals discovery, not authenticity. See Authenticity.
Royalty, Primary Payee, External Minter, Max Invocations, Paused: sale and ownership configuration.
On-Chain Script, Dependencies, Seed Source: code as content. A chunked on-chain program, its ordered libraries, and mint-time randomness stored as configuration.
On-Chain Metadata, Params, Configurable Params: the field-and-representation store and typed parameters. See Metadata and Parameters.
Artist Metadata, License: authorship fields and the content license identifier.

Re-indexing from the logs

A contract's AbxDeployed event, its per-extension version events, and its ERC-165 responses tell a resolver which contracts are ABX, which events to follow, at which version, and which addresses to watch. A project's configuration is expressed by which extensions it enables. A resolver, such as the self-hosted reference implementation, re-indexes a project's state from these events and reads its content bytes from content-addressed data.

Authenticity

AbxDeployed finds contracts; it does not vouch for them. Because any contract can emit it, discovery and trust are separate steps. The source of truth is the canonical factory for each chain: a contract is a canonical ABX contract when that factory deployed it, which a consumer verifies against the factory. The SDK reports this as isCanonical, and the canonical addresses per chain are in the SDK deployments.

The protocol is the spine and the interfaces, not one implementation. The canonical factory marks the reference implementation ABX publishes, but anyone can build a conforming implementation and emit AbxDeployed.

Versioning

Versioning is per-extension, through AbxExtensionVersionSet and extensionVersion(id). No event carries a version field, and older projects remain readable when new versions are added. Standard events are pinned to their canonical signatures.

Interfaces, Metadata, Code projects, Data plane, Effects