# The event spine

The event spine is the set of events an ABX contract emits. With the [read interfaces](interfaces.md),
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](#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](metadata.md) and [Parameters](params.md).
- **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](../reference/sdk.md#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.

## Related

[Interfaces](interfaces.md), [Metadata](metadata.md), [Code projects](code-projects.md), [Data plane](data-plane.md), [Effects](effects.md)