Objects
Object Token is a novel token standard introduced by Every Protocol — often referred to simply as an object.
It is designed to be structured, composable, and interactive, enabling tokens that can evolve, relate, and co-create across creators and chains.
Storage
The OpenZeppelin documentation clearly distinguishes between tokens and token contracts:
Token contracts are smart contracts that manage token balances and operations, while tokens themselves are the digital assets represented by those balances.
In contrast to existing standards like ERC-721 or ERC-1155, Object Tokens store structured and extensible data directly within token contracts. Beyond local state, properties related to interactions across objects and across contracts are maintained in a shared coordination layer called the Omni Registry.
| Standard | Token Contract Storage | Omni Registry Storage |
|---|---|---|
| ERC20 | map(owner => balance) | — |
| ERC721 | map(id => owner)map(id => uri) | — |
| ERC1155 | map(owner => id => balance)map(id => uri) | — |
| Objects | map(id => owner)map(id => metadata)map(id => elements) | map(id => position) |
Properties
The table below outlines the key properties tracked by various token types. Object tokens extend this list with composable content, structured metadata, and spatial logic.
| Property | Description |
|---|---|
| id | A unique identifier within a set (non-fungible only) |
| owner | The address that currently owns the token |
| balance | Amount held by an address (for fungible or semi-fungible tokens) |
| uri | A metadata URI (used in ERC721 and ERC1155 only) |
| metadata | Structured metadata stored onchain (unique to object tokens) |
| elements | Modular components such as matter, values, uniques, and info |
| position | Logical or spatial location, used for linking and layout |
todo: add further explanation for metadata, elements, and position
Operations
We’re already familiar with standard operations like mint, transfer, and burn.
Object tokens introduce additional operations that support mutation, evolution, and interoperation — all native to the protocol.
| Operation | Description | Implemented In | Affected Properties |
|---|---|---|---|
| mint | Create a new object from a set | Token Contract | owner, metadata, elements |
| transfer | Change the ownership of an object | Token Contract | owner |
| burn | Permanently remove an object | Token Contract | owner, metadata |
| update | Modify an object’s metadata or elements | Token Contract | metadata, elements |
| upgrade | Apply kind-defined upgrades to the object | Token Contract | metadata |
| relate | Establish a relation between objects | Omni Registry | position |
| unrelate | Remove a relation between objects | Omni Registry | position |
| move | Change an object’s spatial or logical position | Omni Registry | position |
Assets
For traditional non-fungible tokens (NFTs), the associated assets are referenced via a uri. These URIs may point to IPFS, Arweave, or even centralized servers — but the assets themselves are not guaranteed to be verifiable or secure.
Object Tokens take a fundamentally different approach.
Instead of pointing to static external files, assets in Every Protocol are dynamically generated using the object’s metadata.rev, kind, set, and an associated Kind Contract. This makes assets not only programmable, but also publicly verifiable.
An object’s assets can be seen as projections of the object from different perspectives, each one computed via a facet function in the kind contract. These computed views are called facet images.