Execution

1. The Execution Paradigm Shift

Traditional smart contract platforms introduced the ability to deploy programmable financial primitives, but their underlying execution and storage architectures have created systemic bottlenecks. Symptoms of these bottlenecks include: complex upgrade-proxy patterns, duplicated audit efforts, inconsistent token behaviors across implementations, and an ever-expanding attack surface from repeatedly reimplementing core primitives.

By shifting away from a monolithic, contract-centric model, we can introduce a native, domain-specific execution environment that eliminates these structural flaws.

1.1 Limitations of Contract-Centric Models

In mainstream execution models like the EVM, the blockchain operates as a shared global database where all logic and state are tightly coupled within isolated contract addresses. The protocol functions merely as a blind execution engine for arbitrary bytecode.

Because the network only sees raw execution and storage writes—rather than the semantic intent of an action like an asset transfer or permission grant—it cannot natively enforce domain invariants for standardized primitives. This means the protocol itself cannot guarantee that token balances are conserved during a transfer, or that access control rules are strictly enforced. Consequently, the entire burden of security and state integrity is shifted to the application layer, creating a fragmented safety model where every individual contract must perfectly secure itself against exploits.

1.2 The Replication Trap

Because core network primitives are absent from legacy protocols, developers are forced to repeatedly reimplement them as individual smart contracts. The ERC-20 standard exemplifies this: every new token deployment recreates identical conceptual behavior (balances, transfers, approvals) in a brand-new contract instance.

Today, there are nearly 2 million ERC-20 token contracts deployed on the Ethereum mainnet alone. Even when utilizing established libraries or factory clones, each deployment remains a distinct application-layer instance with its own isolated state, upgrade surface, and integration assumptions. With millions of such contracts deployed across the network, the ecosystem suffers from massive logic duplication. This pattern wastes auditing resources and drastically expands the system-wide attack surface, as every single redeployment introduces a new vector for vulnerabilities.

1.3 Typed Domain Interactions

To resolve protocol blindness, MOI elevates domain logic out of the application layer and into the protocol layer as first-class primitives. This is achieved through Typed Domain Interactions—protocol-recognized operation declarations with known semantics and built-in invariant checks.

Instead of relying on unstructured bytecode, an action is declared as a specific Operation Type (e.g., ASSET_TRANSFER or CAPABILITY_DELEGATE). The protocol natively understands this intent and enforces strict, domain-specific invariants before any custom logic is evaluated. This neutralizes the replication trap by providing standardized, high-security operations at the base layer, while still supporting general-purpose programmable logic within strictly bounded execution environments.

---

2. Execution on MOI

The Typed Domain Interactions introduced in Section 1.3 are not just a conceptual shift — they are the concrete execution primitive in MOI. Every operation on the network, whether it is an asset transfer, an account update, or a logic invocation, is expressed as an Interaction — a structured, protocol-recognized operation that declares both its intent and the parameters required to execute it.

Unlike transactions in contract-centric models, interactions are not opaque calls to arbitrary bytecode. The protocol understands what each interaction is requesting before execution begins.

2.1 Interaction Anatomy

Each interaction consists of two components:

• Interaction Type (Ix Type): Identifies the protocol-recognized operation being performed. Examples include ASSET_CREATE, ASSET_ACTION, and LOGIC_INVOKE.

• Payload: Defines the parameters required to execute the interaction type.

2.2 Practical Contrast: Ethereum vs MOI

To understand how this differs from traditional smart contract execution, consider a simple example.

Ethereum Approach

On Ethereum, transferring tokens involves calling a function within a smart contract.

A transaction might look like this:

tx → ERC20 contract
function: transfer(to, amount)

The contract then executes logic such as:

balances[msg.sender] -= amount;
balances[to] += amount;

This logic is compiled into arbitrary bytecode, and the protocol itself does not understand the semantic intent of the transaction. It simply executes the program.

MOI Approach

On MOI, instead of invoking contract functions through transactions, operations are expressed as structured interactions.

IxType: ASSET_ACTION

Payload:
  action: TRANSFER
  sender: Alice
  receiver: Bob
  amount: 100

In this case, the protocol explicitly understands that the requested operation is an asset transfer between Alice and Bob.

2.3 What This Enables

Because the protocol understands the semantic intent of the interaction, it can enforce domain-specific invariants directly at the protocol layer, such as:

• verifying that the transfer amount is valid
• ensuring the sender has sufficient balance
• restricting state access to the relevant asset and account contexts

Because these primitives are implemented directly by the protocol rather than reimplemented in application-layer smart contracts, this approach eliminates an entire class of contract-level attack surfaces.

---

3. Interaction State Machine (ISM)

The Interaction State Machine (ISM) is the computational model that defines how state transitions occur in MOI.

Before diving into how these transitions work, it is important to understand how state is structured in MOI.

3.1 Context Objects

Unlike traditional blockchains, where state is often treated as a single global database, MOI organizes state around Context Objects. In MOI, the primary context object is participant-scoped: it acts as the base state container for a given participant.

Within a participant context, state is partitioned into multiple domains depending on the use case. These may include:

• Assets — balances and asset-related state associated with the participant
• Logics — logic-linked state, including references to logic objects and storage trees addressed by logic ID, since a participant may interact with many different logics
• Trust — validator or consensus assignments associated with that participant's context
• Preferences — participant-specific metadata or contextual preferences relevant to applications

The key idea is that MOI does not treat state as one shared global bucket. Instead, each participant has a scoped context object, and different state domains are maintained within that container according to the participant's interactions and relationships on the network.

This is what allows the protocol to enforce strict state boundaries during execution. An interaction can access or modify only the domains relevant to its declared intent, rather than arbitrarily reading or mutating unrelated protocol state.

3.2 State Transitions in the ISM

At a high level, the Interaction State Machine describes how the protocol updates state when an interaction is executed.

Formally, execution follows the model:

(C_0, C_1, C_2, ..., C_n) + interaction → (C_0', C_1', C_2', ..., C_n')

Since state in MOI is represented through context objects, the state machine can be thought of as operating on these containers directly.

An interaction specifies the operation being requested, and the protocol applies the corresponding transition rules to update the relevant context objects.

3.3 Interaction Execution Rules

Each interaction type defines the rules that govern how this transition occurs. Specifically, it defines four key aspects of execution:

Aspect	Description
Payload Schema	the structure and parameters required for the interaction
Allowed State Domains	the specific context objects the interaction is permitted to access
Invariant Checks	validation rules that must pass before execution
Transition Semantics	the deterministic state update applied if validation succeeds

In essence, the ISM dictates how interactions produce deterministic state transitions over context objects while enforcing strict domain boundaries.

While the Interaction State Machine defines the rules governing how interactions produce deterministic state transitions, the protocol still requires an execution environment that applies these rules in practice.

This responsibility is handled by the MOI Runtime, which processes interactions and executes the corresponding state transitions defined by the ISM.

---

4. MOI Runtime Architecture

The MOI Runtime is the execution layer that implements the ISM. It receives incoming interactions, dispatches them to the appropriate execution engine, enforces state-domain boundaries, applies deterministic state transitions, and produces canonical execution receipts.

4.1 Core Tasks

At a high level, the runtime performs four core tasks:

1. identifies the interaction type being requested
2. resolves the relevant context objects involved in that interaction
3. applies the validation rules defined for that interaction type
4. executes the transition semantics to produce the updated state

For example, in an asset transfer interaction, the runtime identifies the transfer operation, resolves the relevant asset and account contexts, verifies that the sender has sufficient balance, and then applies the corresponding balance updates.

This is how interactions are translated into deterministic state transitions over context objects.

4.2 Execution Components

To support both protocol-defined primitives and programmable logic, the runtime is divided into two primary execution components:

Component	Purpose
Interaction Execution Engine (IEE)	executes protocol-defined typed interactions
Logic Execution Engine (LEE)	executes programmable logic through VM backends

Depending on the interaction type, the runtime routes execution to the appropriate engine.

Both the IEE and the LEE interact with state through the State Access Controller. This component acts as a guarded interface between the execution engines and protocol state.

Rather than exposing unrestricted access to all state, the State Access Controller provides only the state domains and operations permitted for the current interaction. This ensures that each interaction can read or mutate only the context objects relevant to its declared intent.

---

5. Interaction Execution Engine (IEE)

The Interaction Execution Engine (IEE) is the runtime component responsible for executing protocol-defined typed interactions in MOI. Unlike traditional smart contract platforms that execute opaque application bytecode, the IEE processes interactions whose type and payload are explicitly defined at the protocol layer.

This allows the protocol to understand the semantic intent of an interaction before execution and apply the correct validation and transition rules.

5.1 Purpose of the IEE

The purpose of the IEE is to execute native MOI interactions in a deterministic and protocol-aware manner. Rather than treating every request as arbitrary code execution, the IEE handles interactions that correspond to recognized protocol primitives such as:

• participant creation
• account configuration
• asset creation
• asset interactions such as transfers, approvals, and revocations
• asset supply updates such as minting and burning

Because these interactions are protocol-defined, the IEE can enforce domain-specific invariants directly during execution.

5.2 Execution Flow

At a high level, the IEE performs the following steps:

1. parses the incoming interaction and its typed interactions
2. identifies the protocol-defined interaction type
3. resolves the relevant state domains or context objects
4. validates the payload and checks protocol invariants
5. applies the deterministic state transition
6. returns an execution receipt

This execution model ensures that protocol-native interactions are processed in a standardized and verifiable way.

5.3 Execution Backends

Typed interactions may execute using different backends depending on the complexity of the operation.

Native Execution For simple protocol-defined transitions — such as account creation or basic configuration updates — the IEE uses deterministic handlers implemented directly in Go.

VM-Backed Execution For more complex protocol-defined transitions — such as asset transfers, minting, and supply updates — the IEE delegates execution to a VM backend, currently PISA. These are not developer-written routines. They are protocol-authored routines that ship with the runtime and execute through PISA because the transition logic is complex enough to benefit from deterministic, metered VM execution.

This means PISA serves two roles in the runtime: it executes developer-written logic through the LEE (Section 6), and it executes protocol-defined routines through the IEE.

5.4 Relationship to the Asset Engine

A key example of the IEE in practice is the Asset Engine Interface. In MOI, asset logic may define custom rules and sequencing, but it does not directly mutate balances, mandates, lockups, or supply. Instead, such changes are requested through the protocol's canonical asset engine interface, and the asset engine applies the actual state mutations after validating the request.

This means the IEE is responsible not only for routing asset-related interactions, but also for ensuring that asset state transitions are applied according to protocol rules and permission checks.

As a result, core invariants such as valid transfers, proper supply accounting, and atomic state application can be enforced at the protocol layer.

5.5 Execution Output

After execution, the IEE produces an interaction receipt. This receipt records the outcome of the processed interaction, including:

• interaction status
• fuel used
• participants involved
• per-interaction execution results

Receipts provide a standardized record of execution and allow clients to inspect the result of each interaction processed by the runtime.

---

6. Logic Execution Engine (LEE)

The Interaction Execution Engine handles protocol-defined primitives like asset transfers and account creation. But not everything can be reduced to a fixed set of operations. Developers need the ability to define custom rules, policies, and application-specific behavior that go beyond what protocol primitives offer.

This is the role of the Logic Execution Engine (LEE) — the runtime component that executes programmable logic through virtual machine backends.

6.1 Manifests and VM Extensibility

To understand how the LEE works, it helps to first understand how logic is packaged in MOI.

When a developer compiles a logic module, the output is a manifest — a single artifact that contains everything the runtime needs to execute that logic. A manifest has three parts:

• Schema — describes the interface of the logic module: function names, parameter types, and return types. This follows a standard format regardless of the target VM.
• Bytecode — the compiled instructions that a VM backend will execute. This is specific to whichever VM the logic was compiled for.
• Metadata — declares which VM backend the bytecode targets.

The key design decision here is that the manifest structure is bytecode-agnostic. The schema and metadata follow the same format no matter what VM the bytecode is compiled for. Only the bytecode section changes between VMs.

This means the runtime does not assume a fixed execution backend. When it receives a logic module, it reads the manifest metadata, identifies the target VM, and routes execution to the appropriate backend within the LEE. The runtime itself does not need to understand the bytecode — it simply hands it off to the correct backend.

6.2 PISA Virtual Machine

The current VM backend supported by the LEE is PISA.

PISA executes logic modules written in CoCo, a language designed for MOI's execution model. When a developer writes CoCo and compiles it, the resulting manifest contains PISA bytecode and metadata indicating PISA as the target VM.

Because the manifest is bytecode-agnostic, PISA is not hardwired into the runtime. It is one backend that the LEE routes to based on manifest metadata. Introducing additional backends in the future (such as WASM or EVM-compatible runtimes) becomes an extension of the LEE rather than a restructuring of the runtime.

6.3 CoCo

CoCo (Cocolang) is a statically typed, indentation-based programming language designed for writing logics on MOI. It compiles to PISA bytecode and produces manifests that can be deployed to the network.

Unlike general-purpose smart contract languages, CoCo's constructs map directly to MOI's execution model. Concepts like participants, state scoping, context-aware access, and the distinction between logic state and actor state are expressed at the language level rather than being handled through libraries or conventions.

For detailed language documentation, examples, and compiler usage, visit cocolang.dev.

6.4 Execution Flow

When the runtime receives a LOGIC_INVOKE interaction, it routes execution to the LEE instead of the IEE. The LEE then:

1. loads the referenced logic module — reads the manifest to identify the logic being invoked, including its schema, bytecode, and target VM
2. resolves the required runtime state — identifies and retrieves the context objects that the logic module needs to operate on
3. controls state access — ensures the logic can only read or write to the state domains it is permitted to access
4. executes the bytecode — routes the bytecode to the appropriate VM backend (currently PISA), which runs the instructions deterministically
5. integrates the result with protocol engines — if the logic triggers protocol-level operations (such as asset actions), those are routed to the relevant protocol engines for execution
6. returns the execution result — produces an output that the runtime uses to finalize the state transition and generate a Tesseract containing the interaction receipt and updated state commitments

---

Note: This document covers the execution architecture and concepts behind MOI's runtime. For a hands-on guide to writing, compiling, deploying, and interacting with logics, refer to the Logic Development documentation.

---

Glossary

Term	Definition
Interaction	A structured, protocol-recognized operation that declares both its intent and execution parameters. The atomic unit of execution in MOI.
ISM	Interaction State Machine — the computational model that defines how interactions produce deterministic state transitions over context objects.
Context Object	A scoped container of protocol state (e.g., Asset Context, Account Context, Logic Context) that interactions read from and write to.
IEE	Interaction Execution Engine — the runtime component that executes protocol-defined typed interactions.
LEE	Logic Execution Engine — the runtime component that executes developer-written programmable logic through VM backends.
Manifest	A single deployable artifact containing the schema, bytecode, and VM metadata for a logic module. Bytecode-agnostic by design.
PISA	The register-based virtual machine that serves as the current execution backend for both the LEE (programmable logic) and the IEE (canonical routines).
CoCo	A statically typed, indentation-based programming language for writing logics on MOI. Compiles to PISA bytecode.
POLO	Prefix Ordered Lookup Offsets — the binary serialization format used for all data exchange in MOI.
Tesseract	A cryptographic proof block containing interaction receipts, state commitments, and context hashes.
Logic State	Persistent data stored on the logic itself. Requires write locks, preventing parallel execution.
Actor State	Persistent data stored on each actor's context. Isolated per actor, enabling parallel execution.