Tesseracts

Every distributed network needs a durable unit for recording state change - an object that says what changed, who agreed to it, and what came before it. In MOI, that unit is the Tesseract.

A tesseract sits in the logical slot a block occupies in other networks, but records something fundamentally different:

• A block records the state of the entire network at a point in global time.
• A tesseract records the state of the specific accounts it names, each at a point in its own individual history.

Why the Ledger Is Not a Chain

The shape of a ledger is decided by one thing: where the protocol anchors state.

The bottleneck of a single global state

When a network keeps one global state object (for example, Ethereum's Merkle Patricia trie), every account lives inside it. Because any two state transitions might touch the same object, the protocol cannot know in advance which pairs conflict. The only safe resolution is to order everything: all transitions are forced into a single linear sequence of blocks.

The consequences are structural, not incidental:

• Unrelated operations compete for the same slot.
• Throughput is capped by the speed of one sequence.
• There is exactly one "latest" state, for the entire network.

The MOI approach

Parallel execution requires parallel consensus, and parallel consensus requires parallel state. You cannot funnel concurrent execution results into a single global structure - doing so only moves the bottleneck from execution to storage.

So MOI anchors state at the participant level. State is partitioned into independent objects, one per account, and an interaction can only modify the accounts it explicitly names.

That partitioning narrows the ordering requirement to a single rule:

Two state transitions must be ordered against each other only if they share an account. Transitions over disjoint accounts need no ordering at all.

A tesseract is the manifestation of this rule. It is the record of one set of participants moving together, validated by a committee drawn from those participants' own consensus node sets. Two tesseracts over disjoint accounts are proposed, validated, and finalized concurrently - neither precedes the other, and neither waits on the other.

Feature	Block	Tesseract
Scope	The whole network	Only the accounts it names
Ordering	Total - one global sequence	Partial - only among accounts that share a tesseract
Validated by	The network's validator set	A committee drawn from the participating accounts
Concurrency	One block at a time	Disjoint tesseracts finalize in parallel
"Latest"	One global tip	One tip per account
Height	A global counter	A per-account counter

Multi-Link Composite DAG

Because ordering is partial, the ledger is a directed acyclic graph rather than a chain. Formally this is a Multi-Link Composite DAG (MDAG), and both halves of that name describe a specific departure from a chain:

• Composite - a vertex holds many participants. A tesseract is not one transaction and not one account's state; it is the joint state record of every participant that moved together in that round.

• Multi-Link - a chain vertex has exactly one parent pointer. A tesseract carries one back-link per participant, each pointing at that account's own previous tesseract.

Two tesseracts are connected only if they share at least one account.

Anatomy of the MDAG

• Tesseracts (Circles): These represent individual state transitions branching outward from the Genesis root. Because consensus occurs in parallel, there is no global numbering or strict chronological order across the entire network.

• State Links (Arrows): Labels (p1, p2) represent the participant accounts, but the actual value stored for these links is the hash (ts-hash) of the previous tesseract that mutated their state.

• Direction: While state progresses forward in time (left to right), the arrows point backward to explicitly represent the cryptographic hash links. Network traversal follows these back-links directly into the past to resolve account history.

Two ways to traverse

1. Account History (Linear): Following a single participant's links (e.g., tracing only the arrows labeled p3) isolates that specific account's history as a strict, non-branching chain. Account height is tracked locally along this specific, independent path.

2. Global MDAG (Interconnected): Following all links simultaneously reveals the complete DAG. Tesseracts involving multiple participants (like the central node merging p1, p2, and p3) act as sync points, weaving independent account histories together. If accounts never share an interaction, their chains simply run parallel and never intersect.

DAG in Flight vs. DAG at Rest

Networks like Sui use a DAG temporarily - "in flight" - to quickly share and organize transactions. Once validators agree on a batch of transactions, they apply a deterministic topological sort to flatten the DAG into a strict total order. The network then processes and permanently stores this linear chain as a traditional blockchain, discarding the temporary graph structure.

MOI, on the other hand, never flattens its data. The interconnected graph structure itself is stored permanently as a "DAG at rest." Because MOI preserves the graph instead of forcing all transactions into a single line, it avoids typical storage bottlenecks. This allows every account to track and verify its own independent history without waiting in a single, global queue.

Genesis: The Sarga Account

The Sarga account is instantiated into the network in the genesis tesseract, from where the entire graph grows. Sarga governs account creation by serving two roles:

• Bootstrapping proxy: New accounts lack their own consensus context, so Sarga's context acts as a proxy to validate the tesseract that creates them.

• Account registry: Sarga is the single source of truth for all network registrations. Routing all initializations through it prevents account creation from forking into competing versions.

Because of this, every account-creation tesseract must reference Sarga. While the new account's back-link is NilHash (having no prior history), the tesseract itself remains anchored to the MDAG via Sarga's link back to genesis. Nothing floats freely.

This single-root architecture enforces two properties:

• End-to-end verifiability: Every tesseract's hash links can be traced backward to genesis.

• Fork resistance: Rewriting history requires recreating the dependent links of every participant intersecting that region and achieving a network majority, an attack rendered economically prohibitive by link density.

Anatomy of a Tesseract

type Tesseract struct {
    participants     ParticipantsState
    interactionsHash Hash
    receiptsHash     Hash
    epoch            BigInt
    timestamp        Uint64
    fuelUsed         Uint64
    fuelLimit        Uint64
    consensusInfo    PoXtData

    seal    Bytes
    sealBy  KramaID

    hash     Hash
    ixns     Interactions
    receipts Receipts

    commitInfo CommitInfo
}

The struct has three tiers, and the blank lines above are meaningful:

1. Signed content (participants … consensusInfo) - the eight fields that are encoded and hashed. These are the tesseract.
2. Seal (seal, sealBy) - added after the hash is computed, so they are deliberately outside it.
3. Derived and hydrated (hash, ixns, receipts, commitInfo) - not part of the encoded object. hash is computed from tier 1; the rest are loaded from the database on request, keyed by that hash. See Commit Info.

This keeps the encoded object small. It carries commitments to the bulk data rather than the bulk data itself.

Field	Description
participants	One entry per touched account, mapping it to its new state. The heart of the object - see Participant State.
interactionsHash	Commitment to the ordered list of executed interactions, so the separately stored blob is tamper-evident.
receiptsHash	Commitment to the ordered list of execution receipts, on the same basis.
epoch	The protocol epoch this tesseract belongs to. Reserved for future use; currently always 0.
timestamp	Start time of the consensus view, in Unix nanoseconds. Derived from the view, not from the proposer's wall clock.
fuelUsed	Total fuel consumed by the interactions in this tesseract.
fuelLimit	The fuel ceiling the tesseract was formed under.
consensusInfo	Proof-of-context evidence: proposer, ICS committee derivation, and per-account locks. See PoXtData.
seal	Signature over the tesseract hash by the sealing node.
sealBy	Identity of the sealing node.

Identity: The Tesseract Hash

The hash is the BLAKE2b-256 digest of the tesseract's sign bytes - the eight encoded content fields, explicitly excluding seal and sealBy.

The exclusion is not an optimization; it is what makes the identity stable. If the seal were inside the digest, the same content sealed by a different node would produce a different hash, and back-links would depend on who signed rather than what happened.

That single hash serves three roles at once:

• the vertex ID in the MDAG,
• the value stored in every back-link pointing at this tesseract,
• the database key for the tesseract and all its associated blobs.

Participant State

type State struct {
    Height         Uint64
    TransitiveLink Hash
    LockedContext  Hash
    ContextDelta   Map
    StateHash      Hash
}

There is exactly one entry per account the tesseract touched. Each entry answers two questions: where did this account come from, and where did it land?

Field	Description
Height	The account's local height, counting from 0. Increments only upon mutation.
TransitiveLink	Hash of the previous tesseract that moved this account. NilHash indicates genesis.
LockedContext	Hash of the account's consensus node set pinned for this round so the committee cannot shift mid-consensus.
ContextDelta	Changes applied to the account's consensus node set in this tesseract. (nil if unchanged).
StateHash	Root hash of the account's state after this tesseract was applied.

Two consequences worth stating explicitly:

• Because Height counts per account, "height 40" is a position in that account's history and says nothing about how much has happened elsewhere on the network.
• Because TransitiveLink is per participant, the same tesseract is the "previous tesseract" for every account it moved - which is exactly how independent account histories converge and diverge again inside one graph.

Consensus Evidence

This attribute stores evidence collected against validators that exhibited Byzantine behavior during the previous Tesseract.

PoXtData

It proves the tesseract was produced by the correct committee, over the correct accounts, in the correct view.

info

The "view" is simply the specific, numbered round of voting where a designated operator is given its turn to propose the batch of changes.

type PoXtData struct {
    Proposer     KramaID
    BinaryHash   Hash
    IdentityHash Hash
    View         Uint64
    LastCommit   map[identifier]Hash
    EvidenceHash map[identifier]Hash
    AccountLocks map[identifier]LockType
    ICSSeed      Bytes
    ICSProof     Bytes
}

Field	Description
Proposer	Identity of the node that proposed this tesseract.
BinaryHash / IdentityHash	Pins the node software build and the node identity that produced the proposal.
View	The consensus view the proposal was made in. Required to derive the verifiable timestamp.
LastCommit	Per account: the commit that account was at before this round - the baseline agreed in the prepared phase.
EvidenceHash	Per account: hash of the evidence collected against validators that exhibited Byzantine behavior during the previous tesseract.
AccountLocks	Per account: the lock held during the round - Mutate, Read, or NoLock.
ICSSeed / ICSProof	Auditable proof of the committee draw. Anyone can re-derive the ICS from the seed and check it against the proof.

CommitInfo

CommitInfo records the consensus evidence that finalized a tesseract, proving how the Interaction Consensus Set (ICS) committee agreed.

type CommitInfo struct {
    QC                        Qc
    Operator                  KramaID
    ClusterID                 ClusterID
    View                      uint64
    RandomSet                 []ValidatorIndex
}

Field	Description
QC	The certificate that finalized the tesseract. See Quorum Certificate
Operator	Identity of the node that ran the round.
ClusterID	The ICS cluster the round ran over.
View	The view in which the consensus round happened.
RandomSet	Validators randomly drawn into the committee beyond the accounts' own witness nodes.

Quorum Certificate

A quorum certificate is an aggregated committee signature: it proves a quorum voted, without carrying every individual signature.

type Qc struct {
    Type          ConsensusMsgType   // PROPOSAL | PREVOTE | PRECOMMIT
    View          uint64
    TSHash        Hash
    Signature     Bytes
}

Field	What it is
Type	Which consensus phase this certificate concluded.
View	The consensus view the votes were cast in.
TSHash	Hash of the tesseract being voted on.
Signature	The aggregated signature itself, of all the validators in the ICS commitee.

Persistence

A finalized tesseract is not stored as a single object. The encoded tesseract holds only commitments, so the bulk data lives beside it under the tesseract hash, and each account's own records are updated in the same write.

Keyed by tesseract hash:

Record	Contents
Tesseract	The encoded object - the eight signed fields
Interactions blob	The interactions committed by interactionsHash
Receipts blob	The receipts committed by receiptsHash
Commit info	The consensus evidence that finalized it

Per participant, for each account the tesseract mutated:

Record	Contents
State	The account's state as of this tesseract
Meta info	The account's tip - its latest height and tesseract hash

Indexes:

Index	Resolves
account + height → tesseract hash	Any point in an account's history
interaction hash → tesseract hash	An interaction to its containing tesseract

Reading the MDAG

Because the MDAG lacks a global tip, every state read must be anchored to a specific account and a precise point in its localized history. You define this point using either the account's local height (referred to in the API as tesseract_number) or a direct tesseract_hash.

Strict Query Rules:

• Supply exactly one parameter: tesseract_number or tesseract_hash.

• tesseract_number: -1 requests the latest state (the account's tip).

• Any tesseract_number below -1 is invalid and will be rejected.

Common read patterns

1. Read Account state

moi.AccountState { id, options: { tesseract_number: -1 } }
moi.AccountState { id, options: { tesseract_hash: "0x..." } }

• Latest (-1): The node answers instantly from the account's meta info, requiring no tesseract lookup.

• Specific Height: The node first resolves the local height to a tesseract_hash, loads the tesseract, and extracts the account's StateHash from the matching participant entry.

2. Fetch a tesseract

moi.Tesseract { id, options: { tesseract_number: -1 }, with_interactions: true }
moi.Tesseract { options: { tesseract_hash: "0x..." }, with_interactions: true }

Tesseracts can be queried via the account's history or directly by their hash (the primary database key). Because interactions live in a separate storage blob, they are omitted by default to optimize bandwidth. Explicitly set with_interactions: true to hydrate the response with them.

3. Look up an interaction

moi.InteractionByHash { hash: "0x..." }

This executes a fast, two-hop lookup using the persistence indexes: the interaction hash → tesseract hash index locates the container, and the interaction is then extracted directly from tesseract hash -> interaction set.

Tesseract Lifecycle

Everything above describes the tesseract as a finished object. This is the round that produces one.

A tesseract is assembled by an operator and validated by a committee drawn strictly from the participating accounts' consensus node sets.

1. Batching - the operator groups pending interactions whose participants can move together.

2. Cluster formation - an Interaction Consensus Set (ICS) is formed for that participant set, the accounts are locked, and a prepare message goes out to the committee.

3. Prepared phase - The committee checks the accounts and agrees on where everything currently stands before making any changes. They save a record of this agreement as proof.

4. Proposal - the operator executes the batch against the agreed state and builds the proposal tesseract.

5. Consensus - the round runs propose → prevote → precommit → commit. Each phase collects committee signatures, and the aggregate that concludes a phase is a quorum certificate.

6. Persistence - the finalized tesseract enters the MDAG.

Where Next

• Interactions - the state transitions that tesseracts batch, order, and record.
• Logics - how executable applications produce the state changes that land in a tesseract.
• Multi-Sig - how MOI distributes authority using Account-key weights and Interaction Notary participants.