Object

Objects are a new class of non-fungible tokens (NFTs) that form the foundation of this protocol.

Unlike traditional NFTs, which primarily track id and owner, objects introduce two additional properties: state and position. These additions make objects dynamic, allowing them to evolve and interact with other objects. While traditional NFTs are mainly used for applications like PFPs, music, and digital art, objects expand possibilities by standardizing state and position, enabling deeper interactivity and connectivity.

The id, owner, and state properties are managed by set contracts, created by set developers. An object’s state can be minimal (or even empty) to conserve storage, making it function similarly to traditional tokens. For more complex objects, the state tracks revisions and updates over time.

The position property is handled by the OOPS contract (a core protocol component). If an object lacks a specific position, it resides in the void—a default state for objects that are minted but not yet moved or linked. Otherwise, its position is recorded and managed by the OOPS contract.

Id

The id of an object is assigned at the time of creation by the set contract that mints the object. This id remains fixed throughout the object’s lifecycle and cannot be changed.

Owner

The owner of an object is maintained by the set contract. Ownership is updated whenever the object is transferred, sometimes when an object interacts with other objects, or when it is moved.

State

An object's state tracks its versions over time. Each version of an object's state can be represented by the following structure:

#![allow(unused)]
fn main() {
pub struct State {
    meta: Meta,
    elems: Vec<Bytes32>,
}
}

Meta

The meta field records metadata related to the object’s state, including revision details and references to its kind and set objects. It is structured as follows:

#![allow(unused)]
fn main() {
pub struct Meta {
    flags: u32,
    rev: u32,
    kind_rev: u32,
    set_rev: u32,
    kind_id: u64,
    set_id: u64,
}
}

Field Descriptions

Encoding

The Meta structure can be compactly encoded into a u256:

#![allow(unused)]
fn main() {
let encoded  = (u256(meta.flags)    << 224)
             | (u256(meta.rev)      << 192)
             | (u256(meta.kind_rev) << 160)
             | (u256(meta.set_rev)  << 128)
             | (u256(meta.kind_id)  << 64)
             | u256(meta.set_id);
}

Elements

The elems field is an array that stores the elements comprising the current version of the object. The schema (count and type) of the elements is defined by the kind object specified in the meta field. Each element can be encoded as Bytes32, allowing the array to be efficiently represented as a multiple of 32 bytes.

Position

The position (or pos) of an object tracks where it is located. By default, newly minted objects start at position 0, meaning they exist in the void. As objects interact with others or move, their position is recorded and updated in the OOPS contract.

Operations

Objects can undergo various operations that alter their state, ownership, or position. Below is a table of possible operations:

Some operations may be restricted depending on the object type. These details will be outlined in later sections.

Compatibility

Objects represent a next-generation NFT standard.

By implementing interfaces required by previous NFT standards (e.g., ERC-721 or ERC-1155), object tokens can seamlessly integrate with existing wallets, marketplaces, and block explorers. This allows them to be displayed, traded, and managed alongside traditional NFTs with minimal modifications, ensuring compatibility within the broader NFT ecosystem.