Preface

"The universe encompasses all of space and time, along with everything within them. It includes all forms of existence, from the smallest sub-atomic particles to vast galactic structures. The universe is shaped by fundamental forces, physical processes, and constants, forming the intricate web of matter and energy that constitutes everything from the tiniest elements to the largest cosmic filaments."

Universe, Wikipedia

Introduction

Everything Theory is a protocol and a blockchain specification centered around a novel class of non-fungible tokens (NFTs).

Protocol of Everything

These new tokens, called object tokens or simply objects, are dynamic in nature: they can be modified, evolve over time, and interact with other tokens, offering significantly more functionality than traditional NFTs.

Each object is built from elements, created within a set, and assigned a specific kind. Creators can build sets using elements and kinds from different authors, enabling efficient and collaborative on-chain creation.

The protocol introduces the concept of space. Beyond ownership, tokens now also have a position, meaning they can not only be held by accounts but also exist in specific locations within the protocol.

Each blockchain supported by the protocol is treated as a universe, referred to as a universe chain. Since the protocol explains how time and space expand, how objects are created from elements, and how they interact, it is often called the Protocol of Everything (PRE).

Previous Network

While decentralized storage solutions like IPFS and Arweave address the centralization issues of static NFTs, challenges remain for dynamic NFTs. For instance:

1. A gift card NFT that updates its balance in real-time.
2. A PFP NFT that can be accessorized with NFTs from other issuers (e.g., hats, T-shirts).

These cases require decentralized, secure solutions for NFT mutability and interoperability, which are key to broader NFT adoption.

The Previous Network addresses these challenges in a fully decentralized manner. It consists of three primary types of nodes:

• Probes: Detect activities on universe chains and relay them to telescopes, functioning like bridges.
• Telescopes: Validator nodes responsible for validating and processing transactions.
• Satellites: Nodes that serve digital assets related to tokens and elements, allowing users and applications to access this data.

The Previous Network, also referred to as the Previous Chain or simply Previous, features the Object Virtual Machine (OVM)—a specialized virtual machine designed to process the digital assets of tokens. The OVM ensures deterministic and verifiable computations, providing a secure foundation for expanding NFT use cases.

Previous differs from universe chains by focusing on imaging, or the computation of underlying assets of objects. While Ethereum is often called a "world computer," Previous acts like a "world camera," and is sometimes referred to as the observer chain.

Unlike Layer 2 solutions focused on scaling, Previous adds programmability and data availability to token assets—areas that neither Layer 1 nor Layer 2 chains typically prioritize. This capability enables tokens to be applied in a wider range of engaging use cases across both blockchain layers.

Primitives

The fundamental types used in the protocol are essential for understanding its structure and functionality. These types, primarily described in Rust syntax, form the backbone of the protocol’s data handling and operation.

Common Types

Basic types that appear frequently throughout the protocol:

• u8: Unsigned 8-bit integer.
• u32: Unsigned 32-bit integer.
• u64: Unsigned 64-bit integer.
• u128: Unsigned 128-bit integer.
• u256: Unsigned 256-bit integer.
• Bytes32: A fixed-length array of 32 bytes ([u8; 32]).
• Bytes: A variable-length vector of bytes (Vec<u8>).

Protocol Specific Types

Key types defined by the protocol include:

• ID: Unique identifier for objects within a set.
• Oid: Fullly qualified identifier for objects across universes.
• PartialOid: Identifier for objects within a universe.
• Revision: Version number of an object's state.
• Selector: Identifier of a specific underlying asset of an object token.
• Meta: Metadata containing key information about an object.
• Time: Represents a specific moment within a universe.
• Position: Represents Location within a universe.
• Adjacency: Specifies how many objects of a certain kind can be accepted in a relation, serving as a core unit within the adjacency specification.

ID

ID is the unique identifier for an object within a set. It is represented by a 64-bit unsigned integer (u64).

The valid range for an ID is [1, 2^64 - 2].

Two special values are reserved for specific purposes:

• u64::MIN (0): Serves as a wildcard, indicating any valid ID.
• u64::MAX (2^64 - 1): Represents infinity or total.

Oid

Oid is the fully qualified identifier of an object across all universes, uniquely identifying the object within the protocol.

Representation

An Oid can be represented using the following structure:

#![allow(unused)]
fn main() {
pub struct Oid {
    universe: u64,
    set: u64,
    id: u64,
}
}

The table below outlines the fields of the Oid structure:

Encoding

The Oid structure is often encoded as a u256:

#![allow(unused)]
fn main() {
(u256(oid.universe) << 128) | (u256(oid.set) << 64) | u256(oid.id)
}

PartialOid

PartialOid is the unique identifier of an object within the context of a universe. The term "partial" indicates that the universe ID is not included.

Representation

A PartialOid can be represented using the following structure:

#![allow(unused)]
fn main() {
pub struct PartialOid {
    set: u64,
    id: u64,
}
}

The table below outlines the fields of the PartialOid structure:

Encoding

The PartialOid structure is often encoded as a u128:

#![allow(unused)]
fn main() {
(u128(oid.set) << 64) | u128(oid.id)
}

Revision

Revision is an index that indicates the version of an object’s state. It is represented by a 32-bit unsigned integer (u32).

The valid range for a revision is [1, 2^32 - 2].

Two special u32 values are reserved for specific purposes:

• u32::MIN (0): Indicates that the object does not exist or refers to the latest revision of the object.
• u32::MAX (2^32 - 1): Indicates that the object has been destroyed.

When an object is created, it starts with a revision of 1. As the object evolves or undergoes changes, its revision is incremented to reflect each state change.

Selector

A Selector is a 32-bit unsigned integer (u32) that identifies an underlying asset of an object. It is calculated from the function signatures of asset functions within a kind contract.

u32::MIN (0) and u32::MAX (2^32 - 1) are not considered valid selectors.

Calculation

The calculation process follows the same method used in Ethereum:

#![allow(unused)]
fn main() {
sel = bytes4(keccak256(sig))
}

In this context, the function signatures (sig) are determined differently: since asset functions do not have arguments, the signature is simply the function name without parentheses.

For example, given the following kind contract:

@kind
class Hat {
    // ...

    meta(): Json {
        // ...
    }

    picture(): Image {
        // ...
    }
}

The selectors are calculated as follows:

#![allow(unused)]
fn main() {
sel_meta    = bytes4(keccak256("meta"))    = 0x0144b03a
sel_picture = bytes4(keccak256("picture")) = 0xeb0568a6
}

Time

Time is a structure used to mark the precise moment an event occurs on a universe chain.

In the blockchain context, events are logged within transactions, which are grouped into blocks. Each transaction can contain multiple log entries, allowing for detailed tracking of when and where events occur.

The Time structure is conceptually similar to a tuple of (block_num, txn_index, log_index).

Representation

#![allow(unused)]
fn main() {
pub struct Time {
    block: u64,
    second: u32,
    third: u32,
}
}

Fields of Time

• block: The block number on the universe chain where the event occurred.
• second: The index of the transaction within that block where the event is logged.
• third: The index of the log entry within the transaction that records the event.

Encoding

The Time structure can be encoded into a u128 value for compact representation:

#![allow(unused)]
fn main() {
let encoded = (u128(time.block) << 64)
            | (u128(time.second) << 32)
            | u128(time.third);
}

Written Format

Time is commonly written in the format block:second:third. For example:

• 0:0:0 - The singularity, representing the start of the universe.
• 123456:0:0 - An event that occurred at block 123456, transaction 0, log entry 0.
• 122456:7:8 - An event that occurred at block 122456, transaction 7, log entry 8.

Position

Position represents the location of an object within a universe.

An object can reside in one of the following categories:

• Void: The object exists in void space.
• Space: The object is located within a specified space.
• Object: The object is in relation to another object.
• World: The object has entered a world.
• Outer-verse: The object has jumped outside the current universe.

These categories are called domains, and further specific locations within a domain are referred to as coordinates.

Representation

The Position structure is defined as follows:

#![allow(unused)]
fn main() {
pub struct Position {
    domain: u64,
    coord: u64,
}
}

Field Descriptions

• domain: A 64-bit identifier representing a domain. It is constructed from a category (u8) and an index (u56), where domain_id = u64(domain_cat) << 56 | u64(domain_idx).
• coord: A 64-bit value representing the specific coordinates within the domain.

Encoding

The Position structure can be encoded into a u128:

#![allow(unused)]
fn main() {
(u128(position.domain) << 64) | u128(position.coord)
}

Written Format

A Position is typically written as ([domain_cat]domain_idx, coord). If the coord is zero, it can be omitted.

• domain_cat: A lowercase letter representing the domain category:
  • 'b' for space or void,
  • 's' for object,
  • 'w' for world,
  • 'u' for outer-verse.
  • The letter 'b' can be omitted.
• domain_idx: The decimal value of the domain index.
• coord: Can be represented in decimal, hexadecimal, or as colon-separated values.

Examples:

• (0,): The object is in the void.
• (100, x:y): The object is in space 100, at coordinates (x,y).
• (s17, 1): The object is related to object 17 at coordinate 1.
• (w17,): The object is in world 17.
• (u8453,): The object is in universe 8453, the Base universe.

Adjacency

Adjacency is a structure used to specify how many objects of a particular kind can be accepted within a relation. It is a fundamental unit within the adjacency specification.

Representation

The Adjacency structure is defined as follows:

#![allow(unused)]
fn main() {
pub struct Adjacency {
    kind: u64,
    deg_min: u32,
    deg_max: u32,
}
}

Field Descriptions

Encoding

A single Adjacency structure can be encoded into a u128 for compact representation:

#![allow(unused)]
fn main() {
let encoded = (u128(adjacency.kind) << 64)
            | (u128(adjacency.deg_min) << 32)
            | u128(adjacency.deg_max);
}

Adjacency Specification

An adjacency specification defines the set of adjacencies that a relation supports.

Ascending Order

Adjacencies must be listed in ascending order based on the kind field.

Special Kind Values

Two special kind values have particular meanings:

• u64::MIN (0): Represents "any," meaning any kind not explicitly mentioned.
• u64::MAX (2^64 - 1): Represents "total," indicating the total number of objects that can be accepted in the relation.

The "any" kind must always be listed first, and the "total" kind must be last, if present.

Encoding

An adjacency specification can be encoded into a series of Bytes32 values.

Each Bytes32 can hold two Adjacency structures. If the number of adjacencies is odd, the remaining space in the final Bytes32 is padded with zeros.

Elements

Elements are the atomic building units of objects.

Several types of elements exist:

• Material: Immutable digital content such as images, audio files, or JSON data. Materials are stored on the Previous chain and referenced on universe chains via their hash.

• Information: A versatile data element that holds arbitrary information tied to an object, enabling dynamic behaviors and interactions within the protocol.

• Value: Represents fungible tokens on a universe chain. Values can be linked to predefined materials, allowing for programmability within sets and kinds.

• Artifact: Non-fungible tokens (NFTs) on a universe chain. Artifacts are linked to materials and define ownership, properties, and behavior within the protocol.

Values and Artifacts are often collectively referred to as Token Elements.

Material

A Material represents digital content such as images, audio files, JSON data, and more, stored on the Previous chain.

On universe chains, a material is typically represented by a material hash, which is of type Bytes32. This hash is used as an element of an object. The actual digital content, referred to as the preimage of the material hash (or simply the material data), can be loaded and processed during the execution of a kind contract.

Representation

The Material structure is defined as follows:

#![allow(unused)]
fn main() {
pub struct Material {
    hasher: u32,
    content_type: Bytes32,
    content: Bytes,
}
}

Field Descriptions

Hashing

The material hash is computed as follows:

#![allow(unused)]
fn main() {
material_hash = hash_func(material.content);
}

The hasher field determines the hash function used.

Currently supported options include:

• SHA256: hasher = 1, hash_func = sha256

Additional hashing algorithms may be introduced in the future.

Information

An Information is a piece of data used in the construction of an object. It is represented by a Bytes32 value and can contain arbitrary information.

Information elements can be read and interpreted by set contracts on a universe chain, as well as by kind contracts on the Previous chain. Unlike material elements or token elements, Information typically does not have associated digital content but serves as a flexible and adaptable data point that can be used in various ways within the protocol.

Value

Value represents an amount of fungible tokens on a universe chain and is associated with a predefined set of materials on the Previous chain. This allows fungible tokens to be programmable on both set contracts and kind contracts.

To understand how a Value element functions within the protocol, imagine a gift card as an object composed of two elements: a Value element representing the amount of a token, and a Material element representing the card's background image.

The set contract acts as a vault, holding the specified amount of tokens in the Value element and ensuring they are owned by the object (meaning whoever owns the object can withdraw or consume the tokens). The kind contract can read the amount of tokens, load materials such as the token symbol or icon images from the Value element, and generate a new version of the card's image whenever the Value element is updated.

For a fungible token to be used within the protocol, it must be registered in the token registry. When a token is registered, information such as the token standard, contract address, and associated hash of the materials must be provided.

Representation

A Value has the following structure:

#![allow(unused)]
fn main() {
pub struct Value {
  token_std: u8,
  token_index: u56,
  amount: u192,
}
}

Field Descriptions

Token Standards

At genesis, the supported token standards for value elements are:

Additional token standards can be registered to support more types of tokens.

Limitations

The protocol allocates 192 bits to the amount field, allowing a maximum amount of 2^192 - 1 to be represented. While this accommodates most use cases, tokens with higher decimals may face an upper bound limitation.

Artifact

An Artifact represents one or an amount of non-fungible token (NFT) on the universe chain and is associated with a predefined set of materials on the Previous chain. This allows NFTs to be programmable within both set contracts and kind contracts.

For an NFT to be used within the protocol, it must first be registered in the token registry. During registration, details such as the token standard, contract address, and associated material hashes must be provided.

Representation

The Artifact structure is defined as follows:

#![allow(unused)]
fn main() {
pub struct Artifact {
    token_std: u8,
    token_index: u56,
    id: u64,
    amount: u128,
}
}

Field Descriptions

Token Standards

At genesis, the supported token standards for Artifact elements are:

Additional token standards can be registered to support more types of tokens.

Limitations

The protocol encodes an Artifact element using 256 bits, which imposes certain limitations:

• ID: The id field is limited to 64 bits, which restricts the maximum ID value that can be assigned to a token. In the ERC-1155 and ERC-721 standards, the ID of a token is typically represented as a uint256.

• Amount: The amount field is limited to 128 bits, constraining the maximum amount of a token that can be represented. In the ERC-1155 and ERC-721 standards, the amount of a token is typically represented as a uint256.

Objects

Objects are central to the protocol, created from elements, within sets, and assigned a specific kind. Sets and kinds themselves are classified as objects, making them foundational to the protocol's structure.

Operations such as relations and transforms can be applied to or between objects, both of which are also considered objects.

Additionally, spaces, where objects exist, are treated as objects, allowing flexible interactions between entities.

Objects are categorized into two main types based on their role within the protocol:

• Meta Objects: These include sets, kinds, relations, transforms, and spaces, which define the structure, behavior, and activity scope of other objects.
• Plain Objects: Objects that are not meta objects, typically created by users.

Objects can also be classified based on their creation time:

• Original Objects: Objects created during the initial deployment of the protocol.
• Emergent Objects: Objects created after the protocol's deployment as the system evolves.

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.

Set

Sets are objects from which other objects are minted.

Each set is created from a special set called the Set of Sets, governed by the Set Registry, a core contract of the protocol. All sets adhere to the Kind of Set, which defines the required elements that a set object must contain.

Several sets are established during the protocol’s deployment. All other objects—whether set objects or non-set objects—are created directly or indirectly from these original sets.

ID

The IDs of original sets are predefined by the protocol.

#![allow(unused)]
fn main() {
ID_SET_OF_SPACE = 0;
ID_SET_OF_SET = 1;
ID_SET_OF_KIND = 2;
ID_SET_OF_RELATION = 3;
ID_SET_OF_TRANSFORM = 4;
}

The Ids of emergent sets are allocated by the Set Registry upon registration.

#![allow(unused)]
fn main() {
ID_EMERGENT_SETS_BEGIN = 17;
}

State Meta

When a set is registered in the set registry, its initial metadata is defined as follows:

#![allow(unused)]
fn main() {
meta.flags = 0;
meta.rev = 1;
meta.kind_rev = latest_kind_rev();
meta.set_rev = latest_set_rev();
meta.kind_id = ID_KIND_OF_SET;
meta.set_id = ID_SET_OF_SET;
}

State Elements

According to the Kind of Set, a set object consists of two key elements: impl and data.

The impl element cannot be changed once it is set.

impl

The impl element refers to the set contract on the universe chain. For Ethereum-based chains, it is encoded as a bytes32 from an Ethereum address:

#![allow(unused)]
fn main() {
elems[0] = bytes32(uint160(address))
}

data

The data element is a hash of a JSON material that includes fields such as:

• name: The name of the set.
• description: A brief description of the set.
• image (optional): A URL or reference to an image representing the set.
• ... (optional): Other fields defined by the set.

This material can be accessed and read by the kind contract on the Previous chain.

Operations

Set objects primarily serve as collections of other objects. Operations involving positioning or object-to-object relationships are not supported for sets.

Kind

Kinds are objects that act as the types or blueprints for other objects in the protocol.

Each kind is created from a special set known as the Set of Kinds, governed by the Kind Registry, a core contract of the protocol. All kinds adhere to the Kind of Kind, which defines the essential elements that a kind object must contain.

Several kinds are established during the protocol's deployment, while others emerge as users register new kinds.

ID

The IDs of original kinds are predefined by the protocol:

#![allow(unused)]
fn main() {
ID_KIND_OF_SPACE = 0;
ID_KIND_OF_SET = 1;
ID_KIND_OF_KIND = 2;
ID_KIND_OF_RELATION = 3;
ID_KIND_OF_TRANSFORM = 4;
}

The IDs of emergent kinds are allocated by the Kind Registry upon registration:

#![allow(unused)]
fn main() {
ID_EMERGENT_KINDS_BEGIN = 17;
}

State Meta

When a kind is registered in the Kind Registry, its initial metadata is defined as follows:

#![allow(unused)]
fn main() {
meta.flags = 0;
meta.rev = 1;
meta.kind_rev = latest_kind_rev();
meta.set_rev = latest_set_rev();
meta.kind_id = ID_KIND_OF_KIND;
meta.set_id = ID_SET_OF_KIND;
}

State Elements

According to the Kind of Kind, a kind object consists of the following elements:

The state_spec element cannot be changed once it is set.

state_spec

The state_spec element defines the structure of objects created from this kind. It consists of an array of uint8 values, where each item represents an element type for objects of this kind. The array is concatenated and right-padded to 32 bytes.

code

The code element contains the hash of a WASM-based kind contract. This code, written in AssemblyScript using kind-as or in Rust using kind-rs, is responsible for the behavior of objects derived from this kind. The code material must be added to the Previous chain before its hash can be used.

data

The data element is a hash of a JSON object, which includes fields like:

• name: The name of the kind.
• description: A description of the kind.
• image (optional): A URL or reference to an image representing the kind.

These fields are used by the kind contract to generate metadata for the kind object.

rel_spec

The rel_spec defines the relationships that this kind of object can have with other objects. It includes arrays of relation IDs registered in the Relation Registry, which are big-endian encoded and padded to 32 bytes.

Operations

Operations involving positioning or object-to-object relationships are not supported for kinds.

Relation

A relation is an object that defines adjacencies between different kinds of objects and specifies operations that apply when objects are connected (related) or disconnected (unrelated). Relations set the rules governing how objects interact within the universe.

Relations are created from a special set called the Set of Relations, managed by the OOPS contract, which is a key component of the protocol. All relations follow the Kind of Relation, which outlines the essential elements a relation object must include.

While it's unclear if original relations existed at the protocol's inception, new relations emerge when users register them.

Relations are typically included in the rel_spec field of kind objects. By listing a relation in its rel_spec, a kind declares that the relation’s rules apply to all objects of that kind.

ID

Emergent relations are assigned IDs by the OOPS contract upon registration:

#![allow(unused)]
fn main() {
ID_EMERGENT_RELS_BEGIN = 17;
}

State Meta

When a relation is registered with the OOPS contract, its metadata is initialized as follows:

#![allow(unused)]
fn main() {
meta.flags = 0;
meta.rev = 1;
meta.kind_rev = latest_kind_rev();
meta.set_rev = latest_set_rev();
meta.kind_id = ID_KIND_OF_RELATION;
meta.set_id = ID_SET_OF_RELATION;
}

State Elements

A relation object, as defined by the Kind of Relation, consists of the following elements:

The rule and adj_spec_i elements cannot be changed after they are set.

rule

The rule field encodes a mini-contract that defines preconditions and postconditions for relate and unrelate operations. This contract specifies ownership, position, and other properties when objects are connected or disconnected.

#![allow(unused)]
fn main() {
pub struct MiniRelationContract {
    relate_precond_operator: is_dep_owner,
    relate_precond_owner: is_dest_owner,
    relate_precond_pos: is_void,
    relate_precond_time: is_any,
    owner_on_form: dest_owner | dep_owner | nobody | vault_under_nobody | vault_under_dest_owner | vault_under_dep_owner,
    pos_on_form: dest_pos | dep_pos | void,
    owner_on_term: dest_owner | dep_owner | nobody,
    pos_on_term: dest_pos | dep_pos | void,
}
}

Each field of the MiniRelationContract is encoded into a Bytes32, ensuring compactness.

desc

The desc field is a material hash, where the preimage is stored on the Previous Chain. This description material is not directly referenced on universe chains but is often used for generating assets for the relation object.

adj_spec_i

The adj_spec_i fields define the adjacency rules for the relation, specifying the kinds of objects that can be connected and the limitations of these connections. Each adjacency specification is encoded in compact form for storage efficiency.

Operations

Operations available for relation objects are as follows:

Law

Set Contract

Kind Contract

Evolution

This chapter explores the development and progression of the protocol's universe, from its initial Singularity to the ongoing growth and transformation of objects and spaces. It covers key concepts such as the expansion of time and space, the creation of original constructs, and the interactions that lead to the emergence of new forms and structures within the universe.

Singularity

The Singularity marks the inception of a universe within the protocol, typically represented by the genesis block on the universe chain. A universe's Singularity always occurs at the local time of 0:0:0 for that universe. In contexts where multiple universes are discussed, Coordinated Universal Time (UTC) is used as the standard reference.

As we know so far:

• Universe 1 (Ethereum): The Ethereum universe began on July 30, 2015, at 03:26:13 PM UTC.
• Universe 8453 (Base): The Base universe started on June 15, 2023, at 12:35:47 AM UTC.

Before the Singularity, there was no concept of time, space, elements, objects, or laws. It represents the moment when the expansion of time and space began, and the only existing element at that point was the universe's native token.

Expansion

The time and space of a universe begin to expand simultaneously after the Singularity.

The Void

At time 0:0:0, a special space is created, permeating throughout the universe. The distance from this space to any other space is defined as equal and zero. If an object has no specific position assigned, it is said to belong to this space, known as the Void Space, or simply the Void.

The Space

After time 0:0:0, with each block interval, a part of space is created. Each segment is referred to as a space block, contributing to what is collectively known as Block Space, or simply the Space. The distance between these space blocks remains unknown.

The shape of the Block Space defines the shape of the universe. According to Growing Block Theory, it is theorized that the Block Space takes on a spiral shape, symbolizing the universe's continuous outward expansion with each newly created block. Despite this belief, the precise distance between blocks and the full structure of the universe are still unclear.

Following the formation of the Void Space, each block contributes to the expansion of the Block Space. Unlike the empty Void Space, Block Space is dynamic and growing. Each new block is treated as a domain, which can be claimed by users or players, allowing them to become the rulers of their respective domains.

As rulers, they hold the power to establish laws that govern their domain. Objects and assets can only be moved into a block with the ruler’s permission, introducing a layer of governance and control within the universe. This continuous expansion of the Block Space creates new opportunities for utility and ownership among the universe's inhabitants.

Original Constructs

Long after the Singularity, during a brief yet pivotal period, several earlier existences emerged, including elements, sets, kinds and laws, theese earlier existences are collectively called original constrcuts.

Elements

Key elements that came into existence include:

• Native Token: Represents the native token on the universe chain.
• OG NFT: Represents the protocol's OG NFT.
• Initial Materials: Elements used to construct primal objects, such as code in kind objects and data in kind and set objects.
• Witness Root: The root of a Merkle tree of accounts that witnessed the development and deployment of the protocol.

Sets

Foundational sets from which other objects are created:

• The Set of Spaces: Manages the various spaces within the universe.
• The Set of Sets: The foundational registry for all sets.
• The Set of Kinds: Contains blueprints for all object types.
• The Set of Relations: Defines the possible connections between objects.
• The Set of Transforms: Governs the rules for object transformations.

Kinds

Fundamental kind objects that define object types:

• The Kind of Space: Describes the characteristics and properties of spaces within the universe.
• The Kind of Set: Defines the properties and behaviors of all sets.
• The Kind of Kind: Serves as the blueprint for all kinds, setting standards for object types.
• The Kind of Relation: Specifies the nature and scope of relationships between objects.
• The Kind of Transform: Outlines how objects change, evolve, or interact.

Laws

Laws in the protocol define the creation, mutation, evolution, and interaction of objects:

• Element Registry: Manages the registration of elements such as values, artifacts, and materials.
• Set Registry: Governs the registration of all sets.
• Kind Registry: Maintains the registration of all kinds.
• Object Operating and Positioning System (OOPS): Oversees the registration, interaction, and positioning of objects.

Emergent Constructs

New Elements

new value elements and artifact elements are discovered, and used in the contruction of later objects.

the token registy is responsible for this.

register_value

desc

register_artifact

desc

New Kinds

register

update

New Sets

register

update

Object Interactions

Objects can be interact with others to form a complex structure.

this is governed by the nexus registry contract.

contract Nexus {
    function register_value(std, address, desc) external returns (uint64 token_id);

    // this.name, decimal, descritpion, symbol
    // this.picture
    // this.amount
    // this.address

    function register_artifact(std, address, idBegin, idEnd, desc) external returns (uint64 token_id);
    // this.symbol, decimal, descritpion
    // this.icon
    // this.id
    // this.amount
    // this.address

    function register_relation(rule, adjSpecs, ) external returns (uint64 rel);

    function relate(uint128 dep, uint128 dest, uint64 rel, uint64 data) external;
    function unrelate(uint128 dep, uint128 dest, uint64 rel) external;

    function claim_space(uint64 space) external;
    function transfer_space(uint64 space, address to) external;
    function move(uint128 object, uint64 space, uint64 d1, uint64 d2, uint64 d3);
    function enter(uint128 object, uint64 world, uint64 d1, uint64 d2, uint64 d3);
    function leave(uint128 object, uint64 world);

    function config_domain(uint64 set, uint64 id, rel, cond);

    // mint, burn, (un)relate, transform
    // kind contrat: developer
    // set contract: creator
    // relation contract: developer
    // relation rules/law
    // transform rules/law
    // object/set/space ruleset|law
    // tranform 0
    // set, rel, allow (kind, set), owner address, holder of (set), position from (all), time
    // set, rel, disallow
    //
    // space, enter, allow (kind, set), space owner, white listed address,
    //
    // object,
    // set, object, rel, allow,...

}

New Relations

register_relation()

New Transforms

register_transform()

Interactions

Relate

relate()

Unrelate

unrelate()

Space Exploration

Radiation

In the vast expanse of the universe chain, numerous activities continuously unfold, generating a form of energy we refer to as “Radiation.” This radiation, produced by various events in the blockchain, serves as the fundamental force driving the evolution of objects within the protocol. The protocol’s advanced observatory devices are responsible for detecting and filtering this radiation, separating crucial signals from noise. These signals, once identified, trigger the process of object imaging, where new objects are born or evolve.

Source

In a universe chain, several types of activities generate radiation, each playing a key role in shaping the blockchain's landscape:

• New Blocks: With each newly created block, the universe expands. These blocks form the backbone of the chain, serving as markers of the passage of time and anchoring all activities within the chain.

• Reorganizations (Reorgs): Occasionally, the universe shifts, causing the chain to reorient itself. These reorgs ripple through the blockchain like cosmic disturbances, temporarily altering the chain’s structure and trajectory.

• Transactions: The most frequent type of activity, transactions represent interactions within the universe. Every exchange of tokens, execution of contracts, or invocation of functions results in a release of energy—radiation from these activities propagates across the chain.

• Log Emits in Transactions: Within transactions, logs are emitted to capture specific events. These logs, akin to bursts of energy, represent pivotal moments that are tracked and stored, contributing to the formation and state of objects in the universe.

All these activities produce varying levels of radiation that observatory devices must detect and interpret.

Detection

To harness the radiation generated by activities within the universe chain, the protocol employs a series of observatory devices, each designed to detect and filter specific events:

• Probes: These are the primary devices that monitor the universe chain’s activity. Probes scan the blockchain for radiation, capturing events like new blocks, reorgs, and log emits. Probes are designed to handle the sheer volume of radiation, filtering out noise and focusing on key data that contributes to object imaging.

• Telescopes: Once the relevant signals are filtered, cameras translate these signals into visual representations. The cameras are responsible for capturing the "images" of objects—determining how activities in the universe chain manifest as changes in objects. This imaging process allows for the visualization and tracking of object evolution and interaction.

• Satellites: After probes detect radiation, filters process the data, discarding irrelevant events and retaining only those that may carry signals. Filters can be fine-tuned based on the specific type of radiation they are meant to capture, ensuring precision in data collection.

These observatory devices work in tandem to ensure that the protocol remains attuned to the complex and dynamic environment of the universe chain.

Signals

Among the multitude of activities that generate radiation, only a select few are identified as signals. Signals are the critical events that directly impact the evolution and state of objects within the protocol:

• Block Signals: Certain blocks, due to their specific characteristics or the transactions they contain, are identified as signals. These blocks may trigger significant shifts in the universe, such as creating new objects or altering existing ones.

• Transaction Signals: Not every transaction emits a signal, but when one does, it marks a crucial event. These signals could represent the transfer of significant value, the activation of a major contract, or the conclusion of an important operation.

• Log Signals: Logs emitted within transactions often carry essential information about object states. When these logs are identified as signals, they initiate changes in the object's structure, properties, or relationships, prompting further imaging.

• Reorganization Signals: While reorgs are relatively rare, when they do occur, they can reset or restructure entire portions of the universe. These signals are carefully tracked to ensure the universe remains stable and coherent, even in the face of disruption.

Signals are what drive object imaging, as they provide the necessary data to create new objects, update existing ones, or adjust their relationships. Through the precise detection and interpretation of signals, the protocol ensures that its universe chain remains responsive, adaptive, and constantly evolving.

• Created
• Updated
• Upgraded
• Touched
• Transferred
• Connected
• Disconnected
• Destroyed

Object Imaging

Object imaging is the process through which objects are updated and evolved based on signals received from universe chains. When events occur in these chains, signals are transmitted to the Previous chain, where related objects are updated, and new versions of their underlying assets are computed. This process ensures that the state of objects remains current and reflects the interactions and events occurring across the ecosystem.

Input

The input for the object imaging process includes the oid and the revision of the object. These two pieces of information uniquely determine the corresponding kind contract, the object's elements, and the data related to its set and kind on the Previous chain.

• oid: Identifies the object.
• revision: Specifies the revision of the object state.

Output

The output of the object imaging process is a vector consisting of several items. Each item contains a selector and a corresponding material, which serves as one of the underlying assets of the object for the specified revision in the input.

The number of materials in the output matches the number of asset functions defined within the kind contract.

• Output: Vec<(Selector, Material)>

Processing

The object imaging process involves executing the kind contracts of objects, which are compiled into WebAssembly (Wasm) bytecode from kind contract source code. These contracts are loaded and executed by the Object Virtual Machine (OVM) on the Previous chain. The code, along with other necessary runtime data, is provided by blockchain storage.

Retrieve Kind Contract

The first step in the processing involves retrieving the kind contract, which is necessary to compute the new version of the object's assets. The code hash of the kind contract is resolved from the object’s metadata, and the content of the contract is then loaded from the blockchain storage.

Here’s a pseudocode example to illustrate the loading process:

#![allow(unused)]
fn main() {
let kind_oid: Oid = oid.kind_oid(); // Get the kind OID associated with the object
let meta: Meta = storage.get_meta(oid, rev); // Get the metadata of the object
let kind_elems: Vec<Bytes32> = storage.get_object_data(kind_oid, meta.kind_rev); // Retrieve kind data
let kind_code: Bytes32 = kind_elems[1]; // Extract the code identifier from the kind data
let code_material: Material = storage.get_material(kind_code); // Load the material for the code
let code: Bytes = code_material.content; // Extract the actual bytecode
}

In this process:

• The oid.kind_oid() function retrieves the identifier for the object’s kind.
• Metadata about the object, including its revision, is fetched from storage.
• The relevant kind data, including the contract bytecode, is retrieved and used to load the executable code into the OVM.

Initialize Memory

Once the kind contract is loaded, the elements of the object are retrieved from blockchain storage and used to initialize the memory of the Wasm instance. These elements represent the object’s state and attributes, which are necessary for executing the kind contract.

Here’s the pseudocode for retrieving the object’s elements:

#![allow(unused)]
fn main() {
let elems: Vec<Bytes32> = storage.get_object_data(oid, rev); // Get the object data based on OID and revision
}

The elements are loaded into a specific memory location of the Wasm instance, allowing the contract to access and process them during execution.

Runtime Data

During the execution of the kind contract, several data components are accessed and processed. These include:

• Meta: Metadata for the object, including the object's version and related properties.
• Elements: The individual components that make up the object, such as its attributes and state.
• Connections: Links between objects that define their relationships and interactions.
• Object Set: The grouping of objects to which the current object belongs.
• Object Kind: The type of object, which determines its behavior and rules defined by the kind contract.

These runtime data points are provided by the Previous chain's storage and used by the Wasm instance to execute the contract and generate new versions of the object’s assets.

Host Functions

During execution, the Wasm instance can invoke host functions, which are provided by the OVM and allow the contract to interact with the blockchain state. These functions enable access to blockchain storage, retrieval of materials, and other operations necessary for contract execution. These host functions are critical for ensuring that kind contracts can read and write to the blockchain, enabling updates to object state.

World State Updating

After the kind contract executes, the object’s new state, including any changes to its underlying assets, is updated in the world state on the Previous chain. The results of the contract execution are deterministic and verifiable, ensuring that object evolution remains transparent and secure.

The updated data includes:

• New revisions of the object’s elements and assets.
• Changes to connections and relationships between objects.
• Updates to the object’s metadata and kind information.

This ensures that the object’s state remains consistent and can be used in subsequent interactions and imaging processes.

Accessing

Object assets in Everything Theory can be accessed through satellites, which act as preimage gateways. These gateways provide a way to retrieve the underlying assets of an object at a specific revision. The assets can be accessed using predefined URI schemes or through an online link.

Accessing Assets via URI

Assets can be accessed by specifying the object ID, revision, and a selector in the following format:

pre://{oid}/{rev}/{sel}

• oid: The unique identifier for the object.
• rev: The revision number of the object, indicating its version.
• sel: The selector used to reference a specific material or asset within the object.

Alternatively, assets can also be retrieved by specifying a universe and the hash of the object in hexadecimal:

pre://{universe}/{hash_in_hex}

• universe: The blockchain (or universe chain) in which the object exists.
• hash_in_hex: The hashed identifier of the object or asset.

Accessing Assets via Web Link

Object assets can also be accessed using a web link. The format for this link is as follows:

https://preimage.link/{oid}/{rev}/{sel}

This provides a convenient way for users to view or download object assets directly from a browser by specifying the object ID, revision, and selector.

By leveraging satellites and preimage gateways, the protocol ensures that object assets are easily accessible, transparent, and verifiable, whether through command-line interfaces or web-based platforms.

Set Registry

Kind Registry

Element Registry

Object Operating and Positioning System

Kind Contracts in AssemblyScript

Kind Contracts in Rust

Profile Objects

Blog 3.0

Wearables

Generative Art

AI-Powered Living Objects

Music Collaboration and Distribution

Permadeath Game

Game

Roadmap

1. Everything: OG the debut of the project, calling on pioneers to explore the universes that the theory seeks to explain.

2. Everything: Preface The protocol reaches a stable Version 1, marking the first official release.

3. Everything: Preview Early objects created using the protocol showcase practical applications, providing a glimpse of what's possible.

4. Everything: Previous The decentralized network is deployed, realizing the protocol's full potential and enabling wider adoption.

5. Everything: Predawn Spaces become visible, and living objects emerge, introducing dynamic, evolving entities within the protocol.

6. Everything: Prevailing Portals within spaces are built, allowing objects to traverse new worlds. Wormholes open up, enabling objects to jump between universes.

7. Everything: Prehistory Theories emerge to explain activities before the original constructs, laying a foundation for understanding past and future events within the protocol's universe.

8. Everything: OMG Amazing things unfold as the universe evolves, driven by the participation and creativity of all souls.

Contributing

Everything Theory is in its early stages, there are many ways to get involved.

Read & Share

The simplest way to contribute is by reading this document and sharing it with friends, colleagues, or communities who might be interested in the theory.

If these ideas excite you, consider contributing directly to help build the protocol.

Imagine

If you're familiar with concepts from Greg Egan’s novels, knowledgeable about universe theories, or have ideas about the future of NFTs, you can contribute by:

• Designing the Protocol: Help refine the protocol design, particularly in areas such as relations, transforms, and space-related operations, which are the current focus.
• Documenting the Protocol: Expand and improve the documentation to make the protocol more accessible to others.

Build

Developers can contribute to several technical areas:

• Core Contracts: Participate in the implementation of the protocol on universe chains, currently focusing on Ethereum chains, using Solidity.
• Reference Chain: Contribute to the Previous chain development based on Substrate. The probe (bridge) is being developed using reth’s ExEx, and both are implemented in Rust.
• Compilers: Help develop or improve compilers for kind contracts to WASM. A basic but functional compiler, kind-as, is available based on AssemblyScript, written in TypeScript. A Rust-based compiler, kind-rs, is planned for future development.
• Tools: Enhance developer tools like pre-cli, a command-line interface for the protocol that interacts with the Previous chain and core contracts, written in TypeScript.

Create

Whether you're an artist, musician, app developer, game developer, or any kind of creative professional, consider how mutable, evolvable, and interactive NFTs can open up new possibilities for your projects.

Feel free to share and discuss your ideas with us. Let's create, innovate, and bring new things, species, and worlds into existence!