Accounts

Every distributed network needs a standard way to represent the entities that participate in it. These entities own state, execute logic, hold assets, and interact with the protocol. In MOI, this abstraction is the Account: the unit the network uses to identify participants, manage their state, and cryptographically verify every state transition they make.

State Models

A protocol can anchor state to the application, to the object, or to the participant. That choice shapes everything downstream: how transactions parallelize, how fast global state grows, and who actually owns and controls a user's data.

Application-Centric State

State lives with the application (the model popularized by Ethereum). A token is a single contract holding a global mapping of user addresses to balances; a user's balance is an entry in someone else's storage.

• Surrendered ownership. The user does not control their state; the application does. Their holdings are scattered across every contract they have touched, and a single vulnerability in a shared contract compromises every user at once.
• Sequential execution. Transactions touching the same application must be ordered one after another, and popular applications are exactly where traffic concentrates.

The root problem: applications accumulate the state of all their users.

Object-Centric State

State lives with the resource (the approach taken by networks like Sui). Every asset and application resource is an independent object that records its own owner, so transactions touching unrelated objects run in parallel.

• State bloat. Every asset, position, and resource is a separate object with its own metadata; global state grows with every use of every application.
• Fragmented ownership. The user owns each object directly, but their state is scattered across countless of them, with no single place where it is held or controlled together.

The root problem: ownership is direct, but it comes in fragments.

Participant-Centric State

MOI anchors state at the participant. The account is the single source of truth for everything a participant owns, not just their assets. When a logic executes on behalf of a participant, the state it produces is written back to that participant's account. Logics define behavior; participants own the outcomes.

This resolves both root problems:

• Ownership and control. A participant's entire state, from assets to logic storage, lives under their own account and is modified only under the authority of their own keys. No application holds custody of user state, so no third party sits between a participant and what they own, and no shared contract exists whose compromise drains every user at once.
• Parallel by construction. Independent participants touch disjoint state, so their interactions execute concurrently without a global lock. Because applications do not accumulate user state, a popular logic never becomes a network-wide bottleneck. Where an application genuinely needs shared state, that cost stays scoped to the application itself.

To represent this, MOI models a participant's state as a multidimensional structure called the Context-Superstate.

The Context-Superstate

Every entity on the MOI network maintains a Context-Superstate. It separates the participant's state into functional dimensions that evolve independently while remaining cryptographically linked under a single account.

At a high level, the Superstate has six dimensions:

1. Assets: the assets the participant owns, with cryptographic proof of ownership.
2. Logic: the logics (executable applications) the participant controls.
3. Storage: the persistent data produced by the participant's logic execution.
4. Keys: the cryptographic credentials authorized to modify this account's state.
5. Trust: relational configuration such as consensus witness nodes, sub-accounts, and inheritance links.
6. Preferences: execution parameters such as compute and storage contexts and the default consensus threshold.

Anatomy of an Account

An account entry is deliberately compact. For each dimension of the Superstate it holds a cryptographic commitment, a hash or the root of a Sparse Merkle Tree (SMT), rather than the data itself. Each commitment plays two roles at once: it is the key under which a node fetches the underlying data from its database, and it authenticates what was fetched, since the data can be rehashed and checked against the commitment. To read an account's assets, for example, a node takes the AssetRoot and resolves the asset tree stored under it.

type Account struct {
    AccType        AccountType
    AssetRoot      Hash
    LogicRoot      Hash
    StorageRoot    Hash
    TrustHash      Hash
    PreferenceHash Hash
    KeysHash       Hash
    AssetDeeds     Hash
    FileRoot       Hash
}

1. Identifier: every account lives in global state under a 32-byte identifier, which is how interactions reference and target it. The identifier is the key to the account entry rather than a field inside it; its structure is covered in Account ID below.

2. AccType: the role this account plays on the network, such as a regular participant, an asset, or a logic. See Account Types.

3. AssetRoot: the root of the account's Asset SMT, indexing all owned assets, balances, and descriptors. This commits the Assets dimension.

4. LogicRoot: the root of the Logic SMT, indexing all executable bytecode associated with the account. This commits the Logic dimension.

5. StorageRoot: the root of the Meta-Storage SMT, which maps each Logic ID to the root of that logic's own storage tree. Each piece of logic keeps an isolated storage space, yet the account carries a single commitment for all of it. This commits the Storage dimension.

6. TrustHash: a commitment to the Trust Object, which defines the account's consensus and relational context. This commits the Trust dimension.

7. PreferenceHash: a commitment to the Preference Object, which defines execution and infrastructure parameters. This commits the Preferences dimension.

8. KeysHash: the hash of the account's key collection. This commits the Keys dimension.

9. AssetDeeds: a commitment to the Deeds Object, the record of the assets and logics this account has created.

10. FileRoot: a commitment reserved for file-system support on MOI down the line. It is not active in the first version of the protocol.

Account ID

Every account is addressed by a structured 32-byte identifier. It is not an opaque hash: the ID packs several fields that make an account self-describing.

Field	Size	Purpose
Tag	1 byte	The type of the account (see Account Types)
Flag	1 byte	Additional specifications of the account
Meta-data	2 bytes	Additional specifications of the account
Fingerprint	24 bytes	The component that is unique for every account
Variant	4 bytes	Distinguishes a primary account (0) from its sub-accounts (> 0)

Because the type and variant are embedded in the identifier itself, anyone holding an Account ID can tell what kind of account it refers to, and whether it is primary or derived, without fetching any state.

Account Types

All accounts share the same structure and expose the same Context-Superstate, but they play different roles depending on the entity they represent.

Core Accounts

• Regular Account: a human participant or an autonomous agent. It is the primary entry point for initiating interactions, deploying logic, and holding assets.

• Asset Account: a digital asset class. It is the definitive source of truth for the asset's metadata, supply parameters, and transfer semantics.

• Logic Account: a deployed logic. It owns the persistent state and execution environment of a specific application, allowing the application to operate independently of the users invoking it.

Protocol Accounts

Protocol accounts are deterministic, network-level accounts that maintain global protocol state. Their data is identical across all honest nodes.

• Sarga Account: the network's decentralized registry. It holds the genesis information of every account on the network; when a new account is created, its genesis data is appended to the Sarga logic's storage.

• System Account: hosts global protocol metadata, including the active validator set, the total number of network validators, and the genesis timestamp.

Inherited Accounts

An Inherited Account is an application-specific extension of a user's primary account.

Rather than making the base account carry the heavy execution context of every application the user touches, MOI provisions an inherited account per application. It fuses the authorization credentials (account keys) of the user's primary account with the execution context of the application's logic account.

info

Inherited accounts are covered in detail in a dedicated document, coming soon.

Account Key

Ownership and authorization of an account are managed through a collection of keys. Each key acts as an authorization credential for state-transition operations.

type AccountKey struct {
    PublicKey []byte
    Algorithm SignatureAlgorithm
    Weight    uint8
    Sequence  uint64
}

• PublicKey: the cryptographic key used to verify signatures.
• Algorithm: the signature scheme in use (e.g., Schnorr, BLS).
• Weight: the voting power this key contributes. In multi-signature configurations, an operation is valid only when the cumulative weight of the provided signatures meets the account's defined threshold.
• Sequence: a monotonically increasing nonce that enforces execution ordering and prevents replay attacks.

The global state does not store the key list itself. The account holds a single KeysHash, derived from the cryptographic hash of the serialized key list. When an interaction is submitted, the network resolves the account's key collection, validates it against the KeysHash, and verifies the provided signatures with the corresponding public keys and algorithms. If the cumulative weight of the valid signatures meets the execution threshold, the state transition is authorized and the sequence of each key used is incremented.

Trust Object

The account's TrustHash resolves to the Trust Object, which captures the participant's security assumptions and relational links.

type TrustObject struct {
    WitnessNodes     []KramaID
    SubAccounts      map[Identifier]Identifier
    InheritedAccount Identifier
    WitnessNodesHash Hash
}

• WitnessNodes: the set of nodes this account trusts to participate in consensus for its interactions.
• SubAccounts: derived accounts authorized to act on behalf of this account in specific logic contexts.
• InheritedAccount: the upstream account from which this account derives its trust context.
• WitnessNodesHash: a checksum of the witness configuration, letting the network verify the consensus setup without traversing the full node list.

Preference Object

The account's PreferenceHash resolves to the Preference Object, which defines operational parameters for state transitions.

type PreferenceObject struct {
    StorageContext Hash
    ComputeContext Hash
    DefaultMTQ     int32
}

• StorageContext and ComputeContext: network routing preferences that determine where this account's data is physically stored and where its interactions are processed.
• DefaultMTQ: the default Modulated Trust Quotient, the number of nodes beyond the trusted witness set that must join the consensus cluster before an interaction finalizes. Raising it grows the cluster for that account's interactions, adding an extra layer of security.

Deeds Object

The account's AssetDeeds commitment resolves to the Deeds Object: the record of what this account has created. It lists the assets and logics that originated from this account, establishing a permanent, verifiable link between a creator and their creations.

Where Next

• Interactions: how accounts initiate and authorize state transitions.
• Assets: how MOI represents ownership natively at the account level.
• Logics: how executable applications are built and deployed on MOI.