Protocol Specification of the ao Computer.

Authors (alphabetical): Tyler Hall, Vince Juliano, Ivan Morozov, Sam Williams, Tom Wilson.
Status: DRAFT-5
Network Version: ao.TN.1

What is ao?

The ao computer is the actor oriented machine that emerges from the network of nodes that adhere to its core data protocol, running on the Arweave network. This document gives a brief introduction to the protocol and its functionality, as well as its technical details, such that builders can create new implementations and services that integrate with it.

The ao computer is a single, unified computing environment (a Single System Image), hosted on a heterogenous set of nodes in a distributed network. ao is designed to offer an environment in which an arbitrary number of paralell processes can be resident, coordinating through an open message passing layer. This message passing standard connects the machine's indepedently operating processes together into a 'web' – in the same way that websites operate on independent servers but are conjoined into a cohesive, unified experience via hyperlinks.

Unlike existing decentralized compute systems, ao is capable of supporting the operation of computation without protocol-enforced limitations on size and form, while also maintaining the verifiability (and thus, trust minimization) of the network itself. Further, ao's distributed and modular architecture allows existing smart contract platforms to easily 'plug in' to the network, acting as a single process which can send and recieve messages from any other process.

Instead of enforcing one set of choices upon all users of the computing environment, ao is built in a modular form: Allowing users to choose which virtual machines, sequencing models, message passing security guarantees, and payment options work best for them. This modular environment is then unified by the eventual settlement of all messages – each sharing the same format – onto Arweave's decentralized data layer. This modularity creates a unified computing environment suiting an extremely wide set of workloads, in which every process can easily transfer messages and cooperate.

ao's core ojective is to enable trustless and cooperating compute services without any practical bounds on scale. This allows for a radically new design space of applications that were not previously possible: Blending the benefits of smart contract applications (services without requiring trust in anything but code), and traditional compute environments (Amazon EC2, etc).

aos – a decentralized operating system for ao – allows developers to launch command-line processes that function like smart contracts within its decentralized network. This process is similar to starting a server on a cloud service, but with decentralization and trustless computation as key advantages. These processes operate without being confined to any particular location, enabling seamless user interactions across the network. The outcome is a 'Single System Image'—a unified, global computing platform that transcends physical and scalability limits, collectively used by all participants. Essentially, AO forms a vast, scalable computer where users can interact with any process, promoting a highly collaborative ecosystem.

For users, ao represents a shared computer on which they can execute multiple processes. These processes are not confined to any particular servers or under the dominion of any single individual or group. Once activated, these processes deliver their services with cryptographic security, ensuring unbiased and perpetual operation. This design empowers users with the ability to rely on services that maintain their rights consistently over time, fostering a trustable environment for interaction with the system.

Core Functionality

When compared to existing decentralized and distributed computation systems, the ao protocol offers the following features:

• Arbitrary numbers of processes ('contracts') running in parallel: In ao, applications are built of any number of communicating processes. Inspired by the original actor model (Carl Hewitt, 1973) and Erlang, ao does not allow processes to share memory between one another, but does allow them to coordinate via a native message-passing standard. Each of these processes can then be operated at the full speed of the computing resources that are available, without interfering with one another. By focusing on message-passing ao enables scaling mechanics that are far more similar to traditional web2/distributed systems environments, than traditional smart contracts.
• Unbounded resource utilization in processes: Building on the lazily-evaluated architecture of the original versions of SmartWeave and LazyLedger (later known as Celestia), nodes in the ao network do not need to perform any compute at all in order to reach consensus about program state transitions. State is implied 'holographically' by the Arweave-hosted log of messages to the process. Compute costs are then delegated to users who can either calculate their own states, or request execution by nodes of their choosing.
• Access Arweave, a native unbounded harddrive: ao processes can seamlessly load and execute data of any size directly into their memory and write back to the network. This setup eliminates the typical resource constraints and enables fully parallel execution, dramatically expanding the possibilities for application development beyond the limits of traditional smart contract platforms. Consequently, it opens the door to sophisticated applications requiring extensive data handling and computational resources, such as machine learning tasks and high-compute autonomous agents.
• Autonomously activating contracts: In traditional smart contract environments (like Ethereum, Solana, Polygon, etc.), contracts 'wake up' to perform compute at the request of a user transaction. This creates an environment in which programs are not 'live' unless a user interacts with them, lessening the scope of applications that can be built ontop. ao removes this limitation by allowing contracts to have scheduled 'cron' interactions that automatically wake them up and execute compute at set intervals. Any user, or indeed the process itself, can pay a node to 'subscribe' to a process in order to trigger the evaluation of the compute at the appropriate frequency.
• Modular architecture supporting extensions: ao's core architecture is an open data protocol that anyone can build an implementation of. Everything – from the sequencers, message passing relayers, and even the virtual machine of the system – can be swapped out and extended at will. This flexibility will allow the existing smart contracting systems in the Arweave ecosystem (Warp, Ever, Mem, et al) to plug into ao and be able to send and receive messages from the unified network. This will also allow all of these smart contracting systems to share some of the same infrastructure and tooling, making for a more coherent experience of compute on Arweave.

The ao Architecture in a Nutshell

The fundamental components of ao are as follows:

• Processes: The network's unit of computation. Processes are represented by a log of interacting messages stored on Arweave, as well as an initialization data item. Processes define their required computing environment (its VM, scheduler, memory requires, and necessary extensions) in their initialization. While processes are represented at the consensus level in this way, they also imply a state which can be calculated by computing units that satisfy the requirements and choose to execute the process. As well as receiving messages from user wallets, processes are also forwarded messages from other processes via messenger units. The developers of processes are given free choice as to how to determine the trustworthiness of these messages (see below).
• Messages: Every interaction with a process in ao is represented by a message. At their core, messages are ANS-104 compliant data items. Users and processes (via their outboxes and messenger units) can send messages to other processes on the network by way of scheduler units. Messages in ao have semantics between that of UDP and TCP packets: Delivery is guaranteed to occur only once, but if the message is never forwarded by a messenger unit – or the recipient never actually processes it – then its delivery will not occur.
• Scheduler Units (SUs): Scheduler Units are responsible for the single assignment of atomically incrementing slot numberings to the messages that are sent to a process. After assignment, schedulers are required to ensure that data is uploaded to Arweave and thus made permanently available for others to access. Processes have free choice of their preferred sequencer, which can be implemented in a variety of ways: Decentralized, centralized, or even user-hosted.
• Compute Units (CUs): Compute Units are nodes that users and messenger units can use in order to calculate the state of processes in ao. While SUs are obligated to sequence the messages of processes they have accepted, no CU is required to calculate the state of a process. This creates a peer-to-peer market for computation, where CUs offer the service of resolving process state in competition with one another – trading off price, the computation requirements of the process, and other parameters. Once computation of a state is completed, the CU will return to the caller a signed attested of the output (logs, outboxes, and requests to spawn other processes) of the resolution of a specific message. CUs may also generate and publish signed state attestations that other nodes can load – optionally for a UDL specified fee.
• Messenger Units (MUs): Messenger Units are nodes that relay messages around the ao network according to a process called pushing. In essence, when MUs push a message around the system they send it to the approprate SU for a process, then coordinate with a CU in order to calculate the output of the interaction, and then repeat the process recursively for any resulting outbox messages. This process continues until there are no more messages to push. Users and processes can also pay a MU to subscribe to a process, cranking any messages that result from its timed cron interactions. Processes can also optionally label a message as a cast – leading the MU to send the message to its SU, but not listen for a response. In this way, ao is able to provide a vibrant environment that gives users and processes maximal choice – VM, payment method, scheduler type, messaging security, and more – without requiring consensus on costly computation itself.

Related Work

There are no direct analogies to draw upon that describe what ao is and the experience of using it. There are, however, many adjacent projects and networks that can be used to contrast with ao in order to elucidate its properties. In this section we discuss each in turn.

Actor Model

The Actor Model, introduced by Carl Hewitt, Peter Bishop, and Richard Steiger in their paper, A Universal Modular Actor Formalism for Artificial Intelligence, serves as a foundational framework for understanding and implementing concurrency in computer systems. This model posits that the fundamental unit of computation is the "actor," an entity that can make local decisions, create more actors, send messages, and determine how to respond to messages it receives. This approach to system design and programming facilitates the creation of distributed, highly concurrent, and scalable applications.

Erlang

ao is largely inspired by the Erlang computing environment and its programming language. Erlang is an implementation of the actor model which offers extremely lightweight processes, handled by schedulers in the runtime, in order to enable efficient utilization of massively parallel systems (machines and networks with many physical threads). These capabilities give rise to a 'process-oriented' form of programming, in which the developer naturally splits their computation into many cooperating and parallel components in order to achieve their goal. While Erlang is not extremely well known amongst mainstream computing circles, it is used in a significant number of environments where high performance is a necessity: Telephony switches, instant messenging services like WhatsApp, etc.

The ao computer derives its process-oriented approach from Erlang directly. Erlang offers clue evidence that an environment in which distributed computation is achieved through processes that pass messages but do not share memory can be highly efficient. ao applies this approach to the domain of smart contracts, while also offering a single system image for an Erlang-like environment for the first time.

Smart Contracting Platforms (Ex. Ethereum)

Ethereum is a decentralized computing network in which all users share memory and a single thread of execution. Originally based on an idea of adding Turing Complete computation to a blockchain, Ethereum morphed into a project to build a 'world computer'. Upon launch, Ethereum was able to demonstrate the power of trustless computation of arbitrary code – without the production of an independent blockchain network – for the first time. While the network gained immense traction with users and developers, the core network's throughput has not improved since it launched in 2015.

Instead of attempting to scale the base network past the processing capacity of a single, small thread of execution, the Ethereum ecosystem has pivoted to a 'rollup-centric' roadmap. This approach to scaling focuses on supporting additional 'rollup' networks that inherit some of the properties of Ethereum, but not all of them. At the time of writing, there are 14 rollups in the Ethereum ecosystem with more than $100 million of total value represented in their programs. Each of these 14 rollups represents another single thread (a 'process' in ao terms) of computation that can be performed in parallel. By building from the ground-up to focus on paralell execution rather than shared memory, ao offers a completely novel architecture that supports an arbitrary number of indepedent processes, while maintaining the ability for programs to be decentralized and trustless.

Decentralized Computer Marketplaces (Ex. Akash)

In traditional smart contract platforms like Ethereum, the shared-thread architecture limits each user to executing only small computational tasks. This restriction constrains the complexity and scalability of operations on the network. This shared resource model inherently limits the scalability and efficiency of applications, impacting the potential for more computationally intensive smart contracts.

Several networks aim to facilitate large-scale computing in a decentralized context, such as Akash. Unlike platforms that prioritize verifiable and reproducible computations, Akash and similar networks provide a decentralized marketplace for container hosting services. This approach allows for the execution of traditional, non-deterministic programs on x86 architecture physical machines. However, it sacrifices the capacity to create trustless services, such as those enabled by smart contracts.

ao allows developers to select their preferred VM, with the initial reference implementation focusing on WASM for executing processes. WASM containers in ao can manage up to 4 GB of memory, a limit set to increase with the adoption of WASM64, enabling long-duration computations. The rich compilation tools within the WASM ecosystem support a diverse array of programs. Recent examples of uses of WASM include the execution of LLM transformer models, speech recognition, and even compute-heavy image manipulation software (Photoshop) in web browsers.

Despite its significant computational capacities, ao is able to maintain traditional smart contract execution capabilities due to its holographic state mechanism. Instead of coming to consensus about the state of the computation itself, ao focuses on ensuring that logs of interactions are written to and available on Arweave. The combination of a deterministic metered VM, as well as the availability of all process messages on Arweave, projects a 'hologram' of the state: The state may not have actually been computed by any participant yet, but when it is computed we can guarantee that its outputs will always be the same. Additionally, the holographic state system enabled by message logs on Arweave enables ao processes to respond to implied messages on a timed basis, waking themselves up and performing actions. Paired with its holographic state mechanism, ao also provides a distributed network of Compute Units that offer cryptographically signed attestations about the results of computation. These compute nodes compete with one another in a market, decreasing the cost of resolving the holographic state for users.

Peer-to-Peer VM hosting (Ex. Urbit)

Urbit is a peer-to-peer computation system with some similarities to ao. Like ao, by focusing on the transfer and availability of a interaction logs, Urbit is able to offer a distributed compute environment in which 'servers' can be ported from one physical host to another. During the switch from one host to another, the log of interactions with the hosted computation can be executed in order to recalculate the present state. Urbit processes can also send messages to one another in order to communicate.

Unlike ao, Urbit does not come to decentralized consensus about its interaction logs. In practice, this means that there is no canonical agreement or ensured availability of its 'rollups' – and thus, the state of its processes. In this way, Urbit can be seen as similar to Akash and other decentralized compute marketplaces, with the additional ability to migrate computation from one host to another in a verifiable fashion, if the host is amenable to the transition. ao builds on this model by ensuring that logs of messages to a process are made available via Scheduler Units (SUs), which upload them to Arweave. By enforcing the availability of this log, user processes are decentralized – no longer resident on one specific computation node – allowing their state to be resolved by a distributed network of Compute Units (CUs) in real-time. This difference in architecture ensures that ao processes have the necessary properties that enable the deployment of trustless smart contracts (verifiable decentralized computation), as well as the ability to host an arbitrary number of processes. This latter ability arises due to the fact that processes can still be holographically represented (their message log is permanently available) without there being any CUs presently attached to execute them.

Flexible Trust and Security Models

The core ao data protocol, as described in this document, provides a framework for secure computation but does not provide or enforce any forms of economic guarantees in itself. Instead, ao offers a flexible system of cryptographically secured elements from which economic security mechanisms can be implemented.

In order to fulfil the role of providing users with economic security, an ao staking contract and token are under development that is able to economically enforce the correct operation of units in the network. While the full specification of this mechanism is outside of the scope of this data protocol definition, we provide a blueprint in the following section to illustrate how such a system can be constructed on top of ao.

Formal Process and Unit Models

Processes

Let \(P_i\) represent the \(i^{th}\) process. Define \(P_i = (Log_i, Init_i, Env_i)\), where:

• \(Log_i\) is the ordered sequence of all messages for \(P_i\).
• \(Init_i\) is the initialization data for \(P_i\).
• \(Sched_i\) is the scheduler for \(P_i\).
• \(Env_i\) is the computing environment for \(P_i\).

Notably, as the ao data protocol focuses on providing a universal format for decentralized and verifiable computation, it does not enforce a specific virtual machine, nor any associated parameters. Subsequently, when a developer creates a new process on ao they must specify all of the parameters necessary for units in the system to deterministically execute it. These parameters are added as tags on the spawning data item and may include (but are not limited to):

• The maximum amount of memory that the process should be able to use.
• The maximum number of operations (optionally weighted, according to the specification of the virtual machine) that the process may consume while evaluating a single message.
• Any extensions to the virtual machine that the process requires (access to a virtualized local file system, hardware-optimized encryption instructions, etc.), as defined by the virtual machine specification.

The state of \(P_i\) at a given time step, \(S(P_i)\), is determined by:

\[ S(P_i) = F(Log_i, Env_i) \]

where \(F\) is a function, defined by \(Env_i\), computing the state based on the message log.

The outbox of new messages to be sent to related processes as a result of a message is described as follows:

\[ Outbox_m = F(Log_i, Env_i, m) \]

where \(m\) refers to the originating message.

Messages

Let \(M_{ij}\) represent the \(j^{th}\) message in \(P_i\). \(M_{ij}\) is represented as an ANS-104 compliant data item. The delivery status \(D(M_{ij})\) can be represented as:

\[ D(M_{ij}) = \begin{cases} 1 & \text{if delivered} \\ 0 & \text{else} \end{cases} \]

The ao data protocol employs at-most-once delivery semantics, as detailed in Correctness of at-most-once message delivery protocols, atop which additional guarantees are provided by the maintenance of message logs on Arweave through its data persistence protocol. These guarantees ensure that undelivered messages that result from \(P_i\) may always been delivered later by re-computing \(Outbox(P_i)\) from its message log on Arweave.

Staking

Let \(S_U\) denote the stake for unit \(U\), representing the value of locked tokens committed by the unit to ensure economic security for the messages it is involved in relaying. The stake is defined as:

\[ S_U = \text{tokens committed by \(U\) in a staking process} \]

Once staked, the tokens \(S_U\) for any \(U\) may be subject to slashing as a result of malicious behavior.

Scheduler Units

Upon receiving a message \(m\), an SU, denoted as \(SU_{P_i}\) for process \(P_i\), performs the following operations:

1. Assignment: \(SU_{P_i}\) assigns \(m\) a unique incremental nonce, \(n\), reflecting the order of receipt relative to other messages within the same process. This assignment is formalized as: \[ A(m) = (m, n, \sigma(SU_{P_i}, m, n)) \] where \(\sigma(SU_{P_i}, m, n)\) denotes the cryptographic signature of \(SU_{P_i}\) over the message \(m\) and its nonce \(n\).
2. Persistence: The signed assignment, along with the message, is persisted onto the Arweave data layer, ensuring its availability and integrity within the network.

Stake Slashing Conditions

The stake associated with \(SU_{P_i}\), denoted as \(S_{SU_{P_i}}\), is subject to being slashed under the following conditions:

1. If \(SU_{P_i}\) fails to perform the assignment for \(m\) or maliciously drops \(m\), \(S_{SU_{P_i}}\) will be slashed to penalize the non-compliance. \[ \neg A(m) \Rightarrow Slash(S_{SU_{P_i}}) \]
2. If \(SU_{P_i}\) performs the assignment for \(m\) but fails to persist the signed assignment and message onto the Arweave data layer, resulting in a 'gap' in the log for \(P_i\), \(S_{SU_{P_i}}\) will also be slashed. \[ \neg Persist(A(m)) \lor \neg Persist(m) \Rightarrow Slash(S_{SU_{P_i}}) \]
3. Assigning a slot more than once with the same nonce to different messages: \[ \exists m_1, m_2; m_1 \neq m_2 \wedge A(m_1)_n = A(m_2)_n \Rightarrow Slash(S_{SU_{P_i}}) \]

Compute Units

Compute units execute the virtual machine (defined by \(Env_i\)) function \(\lambda\) for \(P_i\) on given a message:

\[ \lambda(P_i, m_j) = \langle \Phi_{P_i}, Outbox_j, Attest_j \rangle \]

where \(\Phi_{P_i}\) is the new process state, \(Outbox_j\) is the set of any resulting outbound messages, and \(\Attest_j\) is a signed attestation of the computation.

Stake Slashing Conditions

Should \(Attest_j\) be determined to be incorrect by other parties, they have the authority to commence a slashing operation against \(S_{CU}\). Subsequently, \(MUs\) can employ the results of \(\lambda(P_i, m_j)\) from a CU, with economic guarantees bounded by \(S_{CU}\), ensuring a secure and reliable framework.

Messenger Units

Messenger units act on behalf of the user in order to move messages between processes in the system. By performing this task, called pushing, MUs are able to orchestrate any number of processes in order to perform specific tasks for users.

Operating Procedure

1. \(MU_m\) receives a message \(m_{i}\) from a client or user.
2. The message \(m_{i}\) is then forwarded to the scheduler \(SU_k\) for assignment and publication, ensuring it receives a unique slot in the process's ordering.
3. \(MU_m\) requests the outbox of a chosen \(CU_l\) for any new messages that have been generated as a result of processing \(\lambda(P_i, m_i)\).
4. If there are new messages in the outboxes, \(MU_m\) takes each new message, signs it, and forwards it to the appropriate \(SU_k\), recursively continuing the process.

The recursion ends when there are no more new messages given by \(CU_l\) for all prior messages, signifying the end of the processing cycle for the user's interaction.

\[ \text{Push}(MU_m, M) = \begin{cases} \emptyset & \text{if } M = \emptyset \\ \forall m \in M; SU_k(\sigma(MU_m, m)), Push(MU_m, CU_l(m)_{out}) & \text{Else} \end{cases} \]

Stake Slashing Conditions

Messages are propagated via \(Push(MU_m, m)\), either directly by the Messenger Unit \(MU_m\) or by external initiators. Upon receipt, processes evaluate these messages and their signatures to decide on subsequent actions: either to engage (\(\alpha\)), ignore (\(\iota\)), or request re-transmission with an augmented stake (\(\rho\)). This protocol empowers processes within the ao network to delineate their security requirements for message interaction, symbolically represented as:

\[ \text{Decision}(P_i, m, \sigma) = \begin{cases} \alpha, & \text{if security criteria are met}, \\ \iota, & \text{if the message is to be disregarded}, \\ \rho, & \text{if re-transmission with higher stake is required}. \end{cases} \]

In the event that \(MU_m\) is discovered signing an invalid message, entities within the ao protocol possess the authority to enforce a slashing operation against the stake of \(MU_m\), denoted as \(S_{MU_m}\).

\[ \neg MUm \Rightarrow \text{Slash}(S_{MU_m}) \]

Moreover, should the invalidity stem from a Compute Unit's (CU) attested result, \(\lambda(P_i, m_j)\), \(MU_m\) may assert a claim against the CU's stake, \(S_{CU}\), contingent on the staking mechanism's framework. This relationship is defined as:

\[ \neg \lambda(P_i, m_j) \Rightarrow Transfer(S_{CU}, S_{MU_m}) \]

Decentralized Service Market Equilibria

The ao protocol fosters a decentralized market for computation and message passing, which can be modeled through a minimization function as follows in the presence of an efficient market:

\[ \min_{cu \in \mathcal{U}} \sum_{i=1}^{N \times M_i} \left( \text{Cost}(CU, P_i, M_j) - \lambda S_{P_i} \right) \]

Where:

• \(\mathcal{U}\) represents the set of all available Compute Units.
• \(N \times M_i\) iteration over all messages for all processes, effectively treating the set of process-message logs as a single sequence.
• \(\text{Cost}(cu, P_i, M_j)\) computational cost for CU processing message \(M_j\) of process \(P_i\).
• \(\lambda\) weighting factor that quantifies the influence of the stake \(S_{P_i}\) on the overall optimization, allowing users to balance between computational cost efficiency and necessary economic security.

Reference Implementation

The publication of this specification accompanies the release of ao.TN.1. This first testnet release of the system includes fully-functional implementations of SUs, MUs, and CUs for the network. While all choices referenced in this specification are deliberately open to allow different implementations with a range of trade-offs, the initial implementations offers:

• A WASM-based virtual machine environment, supporting up to 4 GB of RAM.
• A Lua runtime environment (ao-lib) that compiles to WASM, designed to allow for the easy development of processes in ao.
• An operating system environment (aos) that lets users interact with and manipulate the system via a Lua command-line interface.
• A Proof-of-Authority (PoA) style message passing service.
• The ability to self-host schedulers, and an open PoA network that all can use.

Notably missing from this initial version of the testnet are:

• P3 payment channels for accessing services on SUs, MUs, and CUs.
• A staking process and token to provide economic security for the functionality of nodes in the ao network.

Implementations of both of these systems are in development.

About this Specification

This protocol defines the ao computer system in terms of its message structures, types, as well as the API endpoints that services that makeup the ao network employ to communicate. This document is intended to give the reader all of the information that they need in order to build an ao compliant service implementation. This specification is currently published in draft form. Please provide feedback to the authors if it does not provide sufficient detail or suffers other imprecisions, such that improvements can be made in future publications.

The ao Data Protocol

ao Messaging Structures

All ao message structures are based off of ANS-104 Data-Items

A data-item is a binary specification found in the ANS-104 Bundled Data Specification. The data-item is the base structure of Arweave Transactions. The ao Data-Protocol, uses this specification as a core primative for each type in the ao Data-Protocol.

Format

Field	Description	Encoding	Length (in bytes)	Optional
Signature type	Type of key format used for the signature	Binary	2
Signature	A signature produced by owner	Binary	Depends on signature type
Owner	The public key of the owner	Binary	512
Target	An address that this DataItem is being sent to	Binary	32 (+ presence byte)
Anchor	A value to prevent replay attacks	Binary	32 (+ presence byte)
number of tags	Number of tags	Binary	8
number of tag bytes	Number of bytes used for tags	Binary	8
Tags	An avro array of tag objects	Binary	Variable
Data	The data contents	Binary	Variable

All optional fields will have a leading byte which describes whether the field is present (1 for present, 0 for not present). Any other value for this byte makes the DataItem invalid.

A tag object is an Apache Avro encoded stream representing an object { name: string, value: string }. Prefixing the tags objects with their bytes length means decoders may skip them if they wish.

In the DataItem structure, the anchor and target fields are not mandatory. The anchor serves as an arbitrary value, enabling bundling gateways to guard against replay attacks targeting them or their users. The target field is specifically utilized in ao Message data-items to denote the ao Process that the Message is aimed at.

The tags section is the designated area where the specifications for each Data-Protocol type are defined according to the ao Data-Protocol Standards.

NOTE: All tags names follow the ANS-116 - Arweave Tag Naming Standard

ao Types

ao has several message types that instruct the network how to operate, these message type structures are provided below:

Modules

The Module type in the ao system defines the process module, essentially representing the Web Assembly-compiled code that is executed upon the instantiation of a process.

Tag Name	Description	Requires	Tag Value
Data-Protocol	The name of the Data-Protocol for this data-item	1-1	ao
Variant	The network version that this data-item is for	1-1	ao.TN.1
Type	Indicates the shape of this Data-Protocol data-item	1-1	Module
Module-Format	Specifies the WebAssembly compilation method for module compatibility across various host environments.	1-1	wasm64-unknown-emscripten-draft_2024_02_15
Input-Encoding	Defines the message encoding format, like JSON, XML, for developer-guided data interpretation.	1-1	JSON-V1
Output-Encoding	Specifies the encoding for outgoing messages, like JSON, XML, ensuring consistent data handling."	1-1	JSON-V1
Memory-Limit	Sets the module's maximum memory, in megabytes or gigabytes, for optimal performance.	0-1	16-mb
Compute-Limit	Caps the compute cycles for a module per evaluation, ensuring efficient, controlled execution	0-1	1000
Extension	Specifies the WASM module use cases, helping the 'Compute Unit' filter and select compatible modules.	0-n	?

Processes

The Process type in the ao system defines the process to be instantiated.

Tag Name	Description	Requires	Tag Value
Data-Protocol	The name of the Data-Protocol for this data-item	1-1	ao
Variant	The network version that this data-item is for	1-1	ao.TN.1
Type	Indicates the shape of this Data-Protocol data-item	1-1	Process
Module	Links the process to ao module using the module's unique Transaction ID (TXID).	1-1	{TXID}
Scheduler	Specifies the scheduler unit by Wallet Address or Name, and can be referenced by a recent Scheduler-Location.	1-1	{ADDRESS}
Cron-Interval	An interval at which a particular Cron Message is recevied by the process, in the format X-Y, where X is a scalar value, and Y is milliseconds, seconds, minutes, hours, days, months, years, or blocks	0-n	1-second
Cron-Tag-{Name}	defines tags for Cron Messages at set intervals, specifying relevant metadata.	0-1
Memory-Limit	Overrides maximum memory, in megabytes or gigabytes, set by Module, can not exceed modules setting	0-1	16-mb
Compute-Limit	Caps the compute cycles for a module per evaluation, ensuring efficient, controlled execution	0-1	1000
Pushed-For	Message TXID that this Process is pushed as a result	0-1	{TXID}
Cast	Sets message handling: 'True' for do not push, 'False' for normal pushing	0-1	{True or False}
Authority	Defines a trusted wallet address which can send Messages to the Process	0-1	{ADDRESS}
On-Boot	Defines a startup script to run when the process is spawned. If value "Data" it uses the Data field of the Process Data Item. If it is a TXID it will load that TX from Arweave and execute it.	0-1	{Data or TXID}
{Any-Tags}	Custom Tags specific for the initial input of the Process	0-n

Messages

The Message type in the ao system defines the message to be evaluated by the ao process.

NOTE: target in the ANS-104 data-item specification contains the TXID of the process that will evaluate the message.

Tag Name	Description	Requires	Tag Value
Data-Protocol	The name of the Data-Protocol for this data-item	1-1	ao
Variant	The network version that this data-item is for	1-1	ao.TN.1
Type	Indicates the shape of this Data-Protocol data-item	1-1	Message
Read-Only	Marks message as a message that is looking for a response only and not modifying the memory of the process	0-1	{True or False}
From-Process	If message is sent from a Process this tag references the Process TXID.	0-1	{TXID}
From-Module	If message is sent from a Process this tag references the Module TXID of that Process	0-1	{TXID}
Pushed-For	Message TXID that this message is pushed for when a MU is evaluating the result	0-1	{TXID}
Cast	Sets message handling: 'True' for do not push, 'False' for normal pushing	0-1	{True or False}
{Any-Tags}	Custom Tags specific to the input of the Message	0-n	{any}

Assignments

The Assignment type in the ao system defines the schedule of the message. The Scheduler Unit su creates this data-item wihch references the Message and Process data-item's. The process and all of its messages all receive an Assignment. Also any Arweave transaction can be given an Assignment and it will be loaded into the Process. Because the Process receives an Assignment the Process data-item is treated as the first Message.

Tag Name	Description	Requires	Tag Value
Data-Protocol	The name of the Data-Protocol for this data-item	1-1	ao
Variant	The network version that this data-item is for	1-1	ao.TN.1
Type	Indicates the shape of this Data-Protocol data-item	1-1	Assignment
Process	References Process via TXID	1-1	{TXID}
Epoch	Scheduling event sequence, incrementing with each process-scheduler transition.	1-1	{Number}
Nonce	Uniquely increments per process/message within an Epoch, ensuring sequence integrity.	1-1	{Number}
Hash-Chain	Ensures data integrity by cryptographically linking messages. It's crucial for security.	1-1	{Hash}
Timestamp	Records the creation time with precise NTP synchronization.	1-1	{UnixTimestamp}
Message	This tag would contain the TXID of a Message or the TXID of any existing Arweave transaction	0-1	{TXID}
Exclude	Fields of a data-item that will be exclude when the Assignment is loaded	0-n	{data-item field}
Block-Height	Records the Arweave blockchain's current block count, offering precise temporal context.	1-1	{Number}

Scheduler-Location

The Scheduler-Location Data-Item in the "ao" Data-Protocol specifies the Scheduler's URL, determined by the Owner's Wallet Address, creating a secure and authenticated link between the Scheduler and its web endpoint for easy access to its services.

Tag Name	Description	Requires	Tag Value
Data-Protocol	The name of the Data-Protocol for this data-item	1-1	ao
Variant	The network version that this data-item is for	1-1	ao.TN.1
Type	Indicates the shape of this Data-Protocol data-item	1-1	Scheduler-Location
Url	Specifies a complete internet resource address, enabling accurate access to the resource.	1-1	{URL}
Time-To-Live	Sets a time limit for caching data URLs, ensuring up-to-date information.	1-1	{Milliseconds}

Scheduler-Transfer

The "Scheduler-Transfer" Data-Item Type in the "ao" Data-Protocol signals a change in schedulers, ensuring a seamless transition for scheduling operations within the system.

Tag Name	Description	Requires	Tag Value
Data-Protocol	The name of the Data-Protocol for this data-item	1-1	ao
Variant	The network version that this data-item is for	1-1	ao.TN.1
Type	Indicates the shape of this Data-Protocol data-item	1-1	Scheduler-Transfer
Scheduler	Records details of the current active Scheduler, preventing confusion about which Scheduler is in control during transitions or scheduling changes within the "ao" system.	1-1	{WALLET_ADDRESS or NAME}
Next-Scheduler	Identifies the upcoming Scheduler for message ordering, ensuring a smooth transition in scheduling duties for system continuity and efficiency.	1-1	{TXID}
Length	Associated with an epoch, counts the total messages created in that phase, aiding in workload tracking and system performance analysis.	1-1	{Number}
Process	References Process via TXID	1-1	{TXID}
Hash-Chain	Ensures data integrity by cryptographically linking messages. It's crucial for security.	1-1	{Hash}
Timestamp	Records the creation time with precise NTP synchronization.	1-1	{UnixTimestamp}
Epoch	Marks when a data-item was created, assigning it to a specific system phase or period for organized processing and analysis within a batch of related messages.	1-1	{Number}
Nonce	Indicates the last used unique number in a message series, ensuring message order, integrity, and security.	1-1	{Number}

Checkpoint

The "Snapshot" Data-Item Type in the "ao" Data-Protocol defines how to properly store checkpoint of a process on arweave. Checkpoints are the archiving of the current memory of a Process at a given Epoch and Nonce.

Tag Name	Description	Requires	Tag Value
Data-Protocol	The name of the Data-Protocol for this data-item	1-1	ao
Variant	The network version that this data-item is for	1-1	ao.TN.1
Type	Indicates the shape of this Data-Protocol data-item	1-1	Checkpoint
Module	Identifier of the module for the checkpoint	1-1	{TXID}
Process	Identifier of the process for the checkpoint	1-1	{TXID}
Epoch	Scheduling event sequence, incrementing with each process-scheduler transition.	1-1	{Number}
Nonce	Uniquely increments per process/message within an Epoch, ensuring sequence integrity.	1-1	{Number}
Timestamp	Records the creation time with precise NTP synchronization.	1-1	{UnixTimestamp}
Block-Height	Records the creation block height.	1-1	{Number}
Cron-Interval	The Cron-Interval that generated this message, identified by its value and tag index	0-1	{IntervalId} ie. 0-10-minutes
Content-Type	The mime type of the data being stored in the data item	1-1	application/octet-stream
Content-Encoding	the encoding of the content being stored in the data item	0-1	{encoding} ie. gzip
SHA-256	Hash of the memory	1-1	{hash}

Data

The data is stored as a binary octlet stream to arweave, you should be able to use a Compute Unit that this module is compatible with and load the Process at the specific Epoch and Nonce. The Data may also be encoded, according to the Content-Encoding Tag eg. gzipped, which will require unzipping before passing to Compute Unit.

ao Node Unit APIs

Units represent the distinct operational domains within the computer, capable of scaling from 0 to multiple instances, each assigned with unique duties within the network.

Scheduler (SU)

The ao Scheduler Unit is tasked with the sequential arrangement and dissemination of ao messages to the Arweave network. Additionally, Compute Units are dependent on the Schedulers for obtaining the sequence of ao messages required for the assessment of updates.

Endpoints

GET /

Description

Scheduler Unit Service Information, the Unit, Address, Timestamp, Processes

Responses

200 - Ok

Schema

{
  "type": "object",
  "properties": {
    "Unit": {
      "type": "string",
      "enum": ["Scheduler"]
    },
    "Address": {
      "type": "string",
      "##### Example
": "Xy9PqW3vR5sT8uB1nM6dK0gF2hL4jC7iE9rV3wX5"
    },
    "Timestamp": {
      "type": "integer",
      "##### Example
": 1642016756
    },
    "Processes": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "##### Example
": [
        "A1b2C3d4E5f6G7h8I9j0K1L2M3N4O5P6Q7R8S9T0",
        "WxYz1234567890AbCdEfGhIjKlMnOpQrStUv"
      ]
    }
  }
}

Example

{
  "Unit": "Scheduler",
  "Address": "Xy9PqW3vR5sT8uB1nM6dK0gF2hL4jC7iE9rV3wX5",
  "Timestamp": 1642016756,
  "Processes": [
    "A1b2C3d4E5f6G7h8I9j0K1L2M3N4O5P6Q7R8S9T0",
    "WxYz1234567890AbCdEfGhIjKlMnOpQrStUv",
    "4rV3wX5Xy9PqW3vR5sT8uB1nM6dK0gF2hL4jC7iE9",
    "2mNoP3qRsT4uVwX5yZaBcDeFgHiJkL"
  ]
}

POST /

Description

Submits an ao DataItem to the Scheduler, the item can be a type of Process or Message.

Request Body

ANS-104 DataItem Binary Format See Spec, this can be empty if an Assignment is being posted via the query parameters.

Query Params

Param	Description	Value	Optional?
process-id	a Process TXID to write an Assignment to	{TXID}
assign	a TXID to assign to a Process	{TXID}
base-layer	If present in the url, the su will verify this is a base layer Arweave Transaction	{no value, present or not}

Responses

201 - Created

Schema

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "##### Example
": "4rV3wX5Xy9PqW3vR5sT8uB1nM6dK0gF2hL4jC7iE9"
    },
    "timestamp": {
      "type": "integer",
      "##### Example
": 1642016756
    }
  }
}

Example

{
  "id": "TXID of the Assignment DataItem",
  "timestamp": "milliseconds"
}

• 400 - Bad Request

Schema

{
	"type": "object",
	"properties": {
		"error": {
			"type": "string"
		}
	}
}

Example

{
  "error": "could not parse DataItem"
}

GET /{process-id}

Description

This endpoint is usually requested by the Compute Unit (cu), and the response is a JSON Array of messages for a given Process

Url Param

Param	Description	Value	Optional?
process-id	the process {TXID}	{TXID}

Query Params

Param	Description	Value	Optional?
from	the Timestamp or Nonce to filter all messages after or equal to this value	{UnixTimestamp or Nonce}
to	the Timestamp or Nonce to filter all messages before or equal to this value	{UnixTimestamp or Nonce}
limit	the maximum number of messages to return on the request	{Integer}

Responses

200 - Ok

When receiving a 200 response, the body of the response contains a JSON document which contains 0 to many DataItems. These DataItems are structured similar to an Arweave GraphQL response to support cursors and pagination.

{
    "page_info": {
        "has_next_page": false
    },
    "edges": [{
        "cursor": "1234",
        "node": {
          "message": {
              "id": "message id",
              "owner": {
                "address": "wallet address",
                "key": "wallet public key"
              },
              "data": "data string",
              "tags": [...],
              "signature": "signature string",
              "anchor": null,
              "target": "process id"
          },
          "assignment": {
              "id": "message id",
              "owner": {
                "address": "wallet address",
                "key": "wallet public key"
              },
              "tags": [...],
              "signature": "signature string",
              "anchor": null,
              "target": null
          }
        }
    }]
}

In the edges array there is a node object with the following properties:

Name	Description	Type
message	The message object containg data item fields	Object
assignment	The assignment object containg data item fields	Object

In each node there is a message object with the following properties:

Name	Description	Type
id	Message Identifier (TXID)	String
tags	Array of (name, value) pairs	Array
signature	Signature of message	String
owner	Object containing message signers Address and Key	Object
anchor	An optional String used by the process code	String
target	The process id the message is sent to	String
data	The string value of the data field, if data is not a UTF-8 String, this will be null	String

In each node there is a assignment object with the following properties:

Name	Description	Type
id	Assignment Identifier (TXID)	String
tags	Array of (name, value) pairs, will contain scheduling info like Epoch and Nonce	Array
signature	Signature of assignment	String
owner	Object containing su wallet Address and Key	Object
anchor	An optional anchor set by the su	String
target	An optional target set by the su	String

Schema

{
  "type": "object",
  "properties": {
    "page_info": {
      "type": "object",
      "properties": {
        "has_next_page": {
          "type": "boolean"
        }
      }
    },
    "edges": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "node": {
            "type": "object",
            "properties": {
              "message": {
                "type": "object",
                "properties": {
                  "id": {
                    "type": "string"
                  },
                  "owner": {
                    "type": "object",
                    "properties": {
                      "address": {
                        "type": "string"
                      },
                      "key": {
                        "type": "string"
                      }
                    }
                  },
                  "data": {
                    "type": "string"
                  },
                  "tags": {
                    "type": "array",
                    "items": {
                      "type": "object",
                      "properties": {
                        "name": {
                          "type": "string"
                        },
                        "value": {
                          "type": "string"
                        }
                      }
                    }
                  },
                  "signature": {
                    "type": "string"
                  },
                  "anchor": {
                    "type": ["string", "null"]
                  },
                  "target": {
                    "type": "string"
                  }
                }
              },
              "assignment": {
                "type": "object",
                "properties": {
                  "id": {
                    "type": "string"
                  },
                  "owner": {
                    "type": "object",
                    "properties": {
                      "address": {
                        "type": "string"
                      },
                      "key": {
                        "type": "string"
                      }
                    }
                  },
                  "tags": {
                    "type": "array",
                    "items": {
                      "type": "object",
                      "properties": {
                        "name": {
                          "type": "string"
                        },
                        "value": {
                          "type": "string"
                        }
                      }
                    }
                  },
                  "signature": {
                    "type": "string"
                  },
                  "anchor": {
                    "type": ["string", "null"]
                  },
                  "target": {
                    "type": ["string", "null"]
                  }
                }
              }
            }
          },
          "cursor": {
            "type": "string"
          }
        }
      }
    }
  }
}

Example

{
  "page_info": {
    "has_next_page": false
  },
  "edges": [
    {
      "node": {
        "message": {
          "id": "IlAfNwTxnCwGmtza3ZJZOjYuIvmvBU9BUMlSJ2pk0d8",
          "owner": {
            "address": "Mqp1HfQHowK4L-zTixu7eInmoKKOz411OIVljdUcQmM",
            "key": "qOI_lGfOr6aFC1m8hM-LjCIkT996dyf6OPlA67FkdjuFpUzmQ-cJdHPZE5DrIHLGwP4pdgIwDMby8urfRefXy9riZtp5Iu33o1xgkxDF-QU-G-A1BXjuPqH2t9nODnJ_-b3gWt-3rkb_Xxg6lnUn622-zhCd0RYibVUb-GcWe8JM3KLQNJPVpuMiV9s-YqhjK74EFU3EALrYnGVr0ufarUmitNZphqTJKeemMLqf-pxIjSTX85j1YM6yq1PlYLjt9BE0wKtT_9ork4nWXTR7S55bna4PdTatSpxiDmcyJIPUtDMcgzp731zXHO0-ayRBjbOjIJQMeHC-Se_pBW6HoGBUY6pxbI7dUCqVwBaeUg6LMNQxfOHDm0Ef2wlFVu0tJG3wRM8bsNviFEsnkLk_yU7ksjUDCei_3yFMMd1lW9grAll8w-3onobA50_JufZsPuO9BfFSDL41jrwbaFUmQo7n2RA2Au_sOczeVeup3lmPf2azXdxzaGZ9zAHqL2fTwt4MoJkrhOZ4vZquZkRPGwjCPJVRiN7CK5PMsvafz5ApT-vKXcT8uL1dT5ic6gX7RPzrkrRdxWXMQN1tOgejEQCoen56oW25SfdeHfwcUQ6K-hvRbBwpM4yGFA2W4e-7oUFTwK40LIEQdstAjPlK9q89_QBmcXV9z3HjiImApjk"
          },
          "data": "require('.process')._version",
          "tags": [
            {
              "name": "Action",
              "value": "Eval"
            },
            {
              "name": "Data-Protocol",
              "value": "ao"
            },
            {
              "name": "Variant",
              "value": "ao.TN.1"
            },
            {
              "name": "Type",
              "value": "Message"
            },
            {
              "name": "SDK",
              "value": "aoconnect"
            }
          ],
          "signature": "CeNvcnKdyX5FLuKMFw0_vhs3BzEswiLP2USQ0bRX1On-m88DFqY8AGeKzE8dpGgrTJxUxx3JWK_a0I8nV_frAaWMbQaF9zYmPYw7X2nn90H4s5D2RuiipeZW67UQ3-SNWoOl3dx8yif5f8XSmP9gaQ1f3pjwnZ9Oa3ySmU4QDFNRFvRtom9xpoHn9NVDXyRw66ovS9VZcDdJVaTQoyo2C2B7GLk8IF2PmMaJeTIgz65mFMn_rpAIHSAXY-GBkXNILYzBdaTd7XiMeHUdj99puWz15qTjZ7rWH-smrxf-GQ3zFYWMUSFku_ujEmCZL9tVSFJ8XnO9-GwFYiHy49lrApXul3M8bpHBOc9EkJT7F-k4SFRtna-7DzU7WERErTZhBQ3nwtl7uoIjCeSfDdfqVuwPYQs3Q-b69eC1ZQ5bjYY8ALkk_KXLjgyaUs-cxpsfAXakvrzSqZHlTWBoTn4sFmCxYQpskwCvL2Q4Qa65K9gSBkvwM5Cu9bhnFyJnfkJwnv5tWppFXjFNmLAzTP94YG2UOmnDZM3g89avrqa6EbPj9GwAGXoyrASsiNkcHmLTjqPLg-c85S_x32DTH3hgbvppXDtmDnfOtBCWLvhaPXCkKxuCXzJewLE11vM65TsnFcNdaM9pCNINj2d7Aer1FWrcKfXadY29AoCPyUnmmw0",
          "anchor": null,
          "target": "G9AfmgAwkyXLXWMSvetGKCqjuD0aaDi1uiwv9VupZ0o"
        },
        "assignment": {
          "id": "fHVBWgh2bqBXinqlJ8VYrdTTq3Ff-ZFMpHfNSrcnSVQ",
          "owner": {
            "address": "fcoN_xJeisVsPXA-trzVAuIiqO3ydLQxM-L4XbrQKzY",
            "key": "kePMooMn7uEakQJCE_4DtzcJUPs6x6d-9nG6Pjg84qJqYM9G7-eIg7Enrg-OEqGTjIoreE7tnTB5z66TqQnllSJa8QNDqHbdN1efAs9RknriT62W7Cyqoz_ErjVhc7Wfx02oQm-SpaUSdo1k8orAJ94ADmw_SbCbceCNirStjcNGJ7x1FSj9iNViETvgEmTICYIlyud8C-FU7oLYjEnlAIwUggrP87uEKyp4a1OLDosxGymIZ7F2yue2d1Y0VXl2vhUOvYrvBvAbPUzuOV0x1sajSz33w9uMdZJceOQbxdj3tgWECvzdNTVincyH8wME1-24Wdqki26SEWqvsjTyjpOctT5MC3riEemjv2KXncXf6-vzPGIdl34MbOu5HkmaxBnUrPsm6xPv6JgbthqJCVbvqQ0dFqqHKARU0g5vYpyAXKjjBJvWjKvUHoK_2hSkpLFaf_GHy3ap1MnYELazK5-Rt7yO1Wq6lPfgPRkROOWP0nCZCcDFpyIrA7Wr_BuZ-pzMHquBYV5i3pCWCuFtanTVlVC7EmPSEMIPCBwIVgBeLVMgAoPgwWB3RqD7JvjMcGvDCONflVRf6NoJjXwuzU8ZBp33cqc-XWAVhrAcd0AGt1N0-7riZSmvEWhpjNrc90ODe01gj55dj5LUFvTO0nmHeyVSMsAKmChacU3-C50"
          },
          "tags": [
            {
              "name": "Process",
              "value": "G9AfmgAwkyXLXWMSvetGKCqjuD0aaDi1uiwv9VupZ0o"
            },
            {
              "name": "Epoch",
              "value": "0"
            },
            {
              "name": "Nonce",
              "value": "0"
            },
            {
              "name": "Hash-Chain",
              "value": "u4Pmu5f84jD5dfci6w7ejBIRhurXoUb-1u2LwSdBvuY"
            },
            {
              "name": "Block-Height",
              "value": "000001517312"
            },
            {
              "name": "Timestamp",
              "value": "1727705842966"
            },
            {
              "name": "Data-Protocol",
              "value": "ao"
            },
            {
              "name": "Type",
              "value": "Assignment"
            },
            {
              "name": "Variant",
              "value": "ao.TN.1"
            },
            {
              "name": "Message",
              "value": "IlAfNwTxnCwGmtza3ZJZOjYuIvmvBU9BUMlSJ2pk0d8"
            }
          ],
          "signature": "eVnmUSHKyTV1cNxijxpmUpAbRvgn_WMXV1E3ZzaRVZmFpEd1AH7dFwb0Pqo6JlEi9_clUvPIksKGwyL5l1R_aa8UJwRxNyF7nbK2Ju78t0mCGyYrIA8HmHPQCAIAT4SZWUp17ZLpjLejgI6dIypGvAKNaVKld4YYQ7gFwD1ApjGeiG2psEprz67ZLRmGRKlY8hryYp4KU_YzK3xcGUOiJUGACyV1ajy6mvSxW5M5Q9Y3nmk4_cHKqhJ0Lbs-DjA3xH4CEU5T-TK68kiwLe7QjZZ94Np5qStjsni1eAEkeumtMYD37PPgrSlyBX8gSq_PBUkNURu47qYgDYkZgmkunxpoVYoQQSMRr12B4ne5KmlNjjg6ZQyWjDRnll5nh3-62t5KYEqOTOtBgBZYKy0Fubb1vSZhVLTRMBtXv6VEPYEXsIMOuMUCVGdm1M1k3X1LYRbSgN3xb3fylpe4CjVLmn4Gm7PnPxEcBdG5A1buYIc1YNxU8Iy1GkPQiwke1QQwzd61KYgJtt-FsFHBg_rKFDg2EoYb9hyCZXF1jrh8521q6XLIZHdRnrhmnuLObLRQhpdIoT0FEDi6DxFMhqsY-uwVNTOCBNVa25b1ItVkX6vivYZyO-7p9iyfz80bjflxnasnUzZJ8AEsDHH8zVNmuiKFNdkitern9bDu1n157r4",
          "anchor": null,
          "target": ""
        }
      },
      "cursor": "1727705842966"
    }
  ]
}

GET /{message-id}?process-id={process-id}

Description

This endpoint is usually requested by the Compute Unit (cu), and the response is a single JSON message representing a single message in ao.

Url Param

Param	Description	Value	Optional?
message-id	the message {TXID}	{TXID}

Query Params

Param	Description	Value	Optional?
process-id	the {TXID} of the process for this messag value	{TXID}

Responses

200 - Ok

When receiving a 200 response, the body of the response contains a JSON document which contains 1 data-item.

Schema

{
  "type": "object",
  "properties": {
    "message": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string"
        },
        "owner": {
          "type": "object",
          "properties": {
            "address": {
              "type": "string"
            },
            "key": {
              "type": "string"
            }
          }
        },
        "data": {
          "type": "string"
        },
        "tags": {
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "name": {
                "type": "string"
              },
              "value": {
                "type": "string"
              }
            }
          }
        },
        "signature": {
          "type": "string"
        },
        "anchor": {
          "type": ["string", "null"]
        },
        "target": {
          "type": "string"
        }
      }
    },
    "assignment": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string"
        },
        "owner": {
          "type": "object",
          "properties": {
            "address": {
              "type": "string"
            },
            "key": {
              "type": "string"
            }
          }
        },
        "tags": {
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "name": {
                "type": "string"
              },
              "value": {
                "type": "string"
              }
            }
          }
        },
        "signature": {
          "type": "string"
        },
        "anchor": {
          "type": ["string", "null"]
        },
        "target": {
          "type": ["string", "null"]
        }
      }
    }
  }
}

Example

{
  "message": {
    "id": "IlAfNwTxnCwGmtza3ZJZOjYuIvmvBU9BUMlSJ2pk0d8",
    "owner": {
      "address": "Mqp1HfQHowK4L-zTixu7eInmoKKOz411OIVljdUcQmM",
      "key": "qOI_lGfOr6aFC1m8hM-LjCIkT996dyf6OPlA67FkdjuFpUzmQ-cJdHPZE5DrIHLGwP4pdgIwDMby8urfRefXy9riZtp5Iu33o1xgkxDF-QU-G-A1BXjuPqH2t9nODnJ_-b3gWt-3rkb_Xxg6lnUn622-zhCd0RYibVUb-GcWe8JM3KLQNJPVpuMiV9s-YqhjK74EFU3EALrYnGVr0ufarUmitNZphqTJKeemMLqf-pxIjSTX85j1YM6yq1PlYLjt9BE0wKtT_9ork4nWXTR7S55bna4PdTatSpxiDmcyJIPUtDMcgzp731zXHO0-ayRBjbOjIJQMeHC-Se_pBW6HoGBUY6pxbI7dUCqVwBaeUg6LMNQxfOHDm0Ef2wlFVu0tJG3wRM8bsNviFEsnkLk_yU7ksjUDCei_3yFMMd1lW9grAll8w-3onobA50_JufZsPuO9BfFSDL41jrwbaFUmQo7n2RA2Au_sOczeVeup3lmPf2azXdxzaGZ9zAHqL2fTwt4MoJkrhOZ4vZquZkRPGwjCPJVRiN7CK5PMsvafz5ApT-vKXcT8uL1dT5ic6gX7RPzrkrRdxWXMQN1tOgejEQCoen56oW25SfdeHfwcUQ6K-hvRbBwpM4yGFA2W4e-7oUFTwK40LIEQdstAjPlK9q89_QBmcXV9z3HjiImApjk"
    },
    "data": "require('.process')._version",
    "tags": [
      {
        "name": "Action",
        "value": "Eval"
      },
      {
        "name": "Data-Protocol",
        "value": "ao"
      },
      {
        "name": "Variant",
        "value": "ao.TN.1"
      },
      {
        "name": "Type",
        "value": "Message"
      },
      {
        "name": "SDK",
        "value": "aoconnect"
      }
    ],
    "signature": "CeNvcnKdyX5FLuKMFw0_vhs3BzEswiLP2USQ0bRX1On-m88DFqY8AGeKzE8dpGgrTJxUxx3JWK_a0I8nV_frAaWMbQaF9zYmPYw7X2nn90H4s5D2RuiipeZW67UQ3-SNWoOl3dx8yif5f8XSmP9gaQ1f3pjwnZ9Oa3ySmU4QDFNRFvRtom9xpoHn9NVDXyRw66ovS9VZcDdJVaTQoyo2C2B7GLk8IF2PmMaJeTIgz65mFMn_rpAIHSAXY-GBkXNILYzBdaTd7XiMeHUdj99puWz15qTjZ7rWH-smrxf-GQ3zFYWMUSFku_ujEmCZL9tVSFJ8XnO9-GwFYiHy49lrApXul3M8bpHBOc9EkJT7F-k4SFRtna-7DzU7WERErTZhBQ3nwtl7uoIjCeSfDdfqVuwPYQs3Q-b69eC1ZQ5bjYY8ALkk_KXLjgyaUs-cxpsfAXakvrzSqZHlTWBoTn4sFmCxYQpskwCvL2Q4Qa65K9gSBkvwM5Cu9bhnFyJnfkJwnv5tWppFXjFNmLAzTP94YG2UOmnDZM3g89avrqa6EbPj9GwAGXoyrASsiNkcHmLTjqPLg-c85S_x32DTH3hgbvppXDtmDnfOtBCWLvhaPXCkKxuCXzJewLE11vM65TsnFcNdaM9pCNINj2d7Aer1FWrcKfXadY29AoCPyUnmmw0",
    "anchor": null,
    "target": "G9AfmgAwkyXLXWMSvetGKCqjuD0aaDi1uiwv9VupZ0o"
  },
  "assignment": {
    "id": "fHVBWgh2bqBXinqlJ8VYrdTTq3Ff-ZFMpHfNSrcnSVQ",
    "owner": {
      "address": "fcoN_xJeisVsPXA-trzVAuIiqO3ydLQxM-L4XbrQKzY",
      "key": "kePMooMn7uEakQJCE_4DtzcJUPs6x6d-9nG6Pjg84qJqYM9G7-eIg7Enrg-OEqGTjIoreE7tnTB5z66TqQnllSJa8QNDqHbdN1efAs9RknriT62W7Cyqoz_ErjVhc7Wfx02oQm-SpaUSdo1k8orAJ94ADmw_SbCbceCNirStjcNGJ7x1FSj9iNViETvgEmTICYIlyud8C-FU7oLYjEnlAIwUggrP87uEKyp4a1OLDosxGymIZ7F2yue2d1Y0VXl2vhUOvYrvBvAbPUzuOV0x1sajSz33w9uMdZJceOQbxdj3tgWECvzdNTVincyH8wME1-24Wdqki26SEWqvsjTyjpOctT5MC3riEemjv2KXncXf6-vzPGIdl34MbOu5HkmaxBnUrPsm6xPv6JgbthqJCVbvqQ0dFqqHKARU0g5vYpyAXKjjBJvWjKvUHoK_2hSkpLFaf_GHy3ap1MnYELazK5-Rt7yO1Wq6lPfgPRkROOWP0nCZCcDFpyIrA7Wr_BuZ-pzMHquBYV5i3pCWCuFtanTVlVC7EmPSEMIPCBwIVgBeLVMgAoPgwWB3RqD7JvjMcGvDCONflVRf6NoJjXwuzU8ZBp33cqc-XWAVhrAcd0AGt1N0-7riZSmvEWhpjNrc90ODe01gj55dj5LUFvTO0nmHeyVSMsAKmChacU3-C50"
    },
    "tags": [
      {
        "name": "Process",
        "value": "G9AfmgAwkyXLXWMSvetGKCqjuD0aaDi1uiwv9VupZ0o"
      },
      {
        "name": "Epoch",
        "value": "0"
      },
      {
        "name": "Nonce",
        "value": "0"
      },
      {
        "name": "Hash-Chain",
        "value": "u4Pmu5f84jD5dfci6w7ejBIRhurXoUb-1u2LwSdBvuY"
      },
      {
        "name": "Block-Height",
        "value": "000001517312"
      },
      {
        "name": "Timestamp",
        "value": "1727705842966"
      },
      {
        "name": "Data-Protocol",
        "value": "ao"
      },
      {
        "name": "Type",
        "value": "Assignment"
      },
      {
        "name": "Variant",
        "value": "ao.TN.1"
      },
      {
        "name": "Message",
        "value": "IlAfNwTxnCwGmtza3ZJZOjYuIvmvBU9BUMlSJ2pk0d8"
      }
    ],
    "signature": "eVnmUSHKyTV1cNxijxpmUpAbRvgn_WMXV1E3ZzaRVZmFpEd1AH7dFwb0Pqo6JlEi9_clUvPIksKGwyL5l1R_aa8UJwRxNyF7nbK2Ju78t0mCGyYrIA8HmHPQCAIAT4SZWUp17ZLpjLejgI6dIypGvAKNaVKld4YYQ7gFwD1ApjGeiG2psEprz67ZLRmGRKlY8hryYp4KU_YzK3xcGUOiJUGACyV1ajy6mvSxW5M5Q9Y3nmk4_cHKqhJ0Lbs-DjA3xH4CEU5T-TK68kiwLe7QjZZ94Np5qStjsni1eAEkeumtMYD37PPgrSlyBX8gSq_PBUkNURu47qYgDYkZgmkunxpoVYoQQSMRr12B4ne5KmlNjjg6ZQyWjDRnll5nh3-62t5KYEqOTOtBgBZYKy0Fubb1vSZhVLTRMBtXv6VEPYEXsIMOuMUCVGdm1M1k3X1LYRbSgN3xb3fylpe4CjVLmn4Gm7PnPxEcBdG5A1buYIc1YNxU8Iy1GkPQiwke1QQwzd61KYgJtt-FsFHBg_rKFDg2EoYb9hyCZXF1jrh8521q6XLIZHdRnrhmnuLObLRQhpdIoT0FEDi6DxFMhqsY-uwVNTOCBNVa25b1ItVkX6vivYZyO-7p9iyfz80bjflxnasnUzZJ8AEsDHH8zVNmuiKFNdkitern9bDu1n157r4",
    "anchor": null,
    "target": ""
  }
}

GET /timestamp

Description

Returns the current timestamp JSON document from the su

Responses

200 - Ok

Format: JSON

Property	Description
block_height	The current height of the Arweave Network
timestamp	The current timestamp of the Scheduler Unit

Schema

{
	"type": "object",
	"properties": {
		"block_height": {
			"type": "string"
		},
		"timestamp": {
			"type": "string"
		}
	}
}

GET /processes/{process-id}

Description

This endpoint is usually requested by the Compute Unit (cu) and the Message Unit (mu), and the response is a single JSON object representing a single process in ao.

Url Param

Param	Description	Value	Optional?
process-id	the process {TXID}	{TXID}

Responses

200 - Ok

When receiving a 200 response, the body of the response contains a JSON document which contains 1 data-item.

Schema

{
	"type": "object",
	"properties": {
		"process_id": {
			"type": "string"
		},
		"block": {
			"type": "string"
		},
		"owner": {
			"type": "object",
			"properties": {
				"address": {
					"type": "string"
				},
				"key": {
					"type": "string"
				}
			}
		},
		"tags": {
			"type": "array",
			"items": {
				"type": "object",
				"properties": {
					"name": {
						"type": "string"
					},
					"value": {
						"type": "string"
					}
				}
			}
		},
		"timestamp": {
			"type": "integer"
		},
		"data": {
			"type": ["string", "null"]
		},
		"anchor": {
			"type": ["string", "null"]
		},
		"signature": {
			"type": "string"
		},
		"target": {
			"type": ["string", "null"]
		}
	}
}

Example

{
	"process_id": "G9AfmgAwkyXLXWMSvetGKCqjuD0aaDi1uiwv9VupZ0o",
	"block": "000001517312",
	"owner": {
		"address": "Mqp1HfQHowK4L-zTixu7eInmoKKOz411OIVljdUcQmM",
		"key": "qOI_lGfOr6aFC1m8hM-LjCIkT996dyf6OPlA67FkdjuFpUzmQ-cJdHPZE5DrIHLGwP4pdgIwDMby8urfRefXy9riZtp5Iu33o1xgkxDF-QU-G-A1BXjuPqH2t9nODnJ_-b3gWt-3rkb_Xxg6lnUn622-zhCd0RYibVUb-GcWe8JM3KLQNJPVpuMiV9s-YqhjK74EFU3EALrYnGVr0ufarUmitNZphqTJKeemMLqf-pxIjSTX85j1YM6yq1PlYLjt9BE0wKtT_9ork4nWXTR7S55bna4PdTatSpxiDmcyJIPUtDMcgzp731zXHO0-ayRBjbOjIJQMeHC-Se_pBW6HoGBUY6pxbI7dUCqVwBaeUg6LMNQxfOHDm0Ef2wlFVu0tJG3wRM8bsNviFEsnkLk_yU7ksjUDCei_3yFMMd1lW9grAll8w-3onobA50_JufZsPuO9BfFSDL41jrwbaFUmQo7n2RA2Au_sOczeVeup3lmPf2azXdxzaGZ9zAHqL2fTwt4MoJkrhOZ4vZquZkRPGwjCPJVRiN7CK5PMsvafz5ApT-vKXcT8uL1dT5ic6gX7RPzrkrRdxWXMQN1tOgejEQCoen56oW25SfdeHfwcUQ6K-hvRbBwpM4yGFA2W4e-7oUFTwK40LIEQdstAjPlK9q89_QBmcXV9z3HjiImApjk"
	},
	"tags": [
		{
			"name": "App-Name",
			"value": "aos"
		},
		{
			"name": "Name",
			"value": "forspec"
		},
		{
			"name": "Authority",
			"value": "fcoN_xJeisVsPXA-trzVAuIiqO3ydLQxM-L4XbrQKzY"
		},
		{
			"name": "aos-Version",
			"value": "2.0.0"
		},
		{
			"name": "Data-Protocol",
			"value": "ao"
		},
		{
			"name": "Variant",
			"value": "ao.TN.1"
		},
		{
			"name": "Type",
			"value": "Process"
		},
		{
			"name": "Module",
			"value": "bkjb55i07GUCUSWROtKK4HU1mBS_X0TyH3M5jMV6aPg"
		},
		{
			"name": "Scheduler",
			"value": "_GQ33BkPtZrqxA84vM8Zk-N2aO0toNNu_C-l-rawrBA"
		},
		{
			"name": "SDK",
			"value": "aoconnect"
		}
	],
	"timestamp": 1727705839572,
	"data": null,
	"anchor": null,
	"signature": "MsEuz9LkIx69WENgSFR1IMgfjkKOp1GGMeyjBGYtbxlBmeAO0TCmdQ6qqhhE-jjGFd6LtlRQaif3YkiDwS_prWIZ5AvAoK6PPQHNC_eHX7Le8586L-GYos694dFedc2gjvUNtU7JEuRTNvwQWQ65cib4zd7stJWjE-JpqingLKcXWqFqrvMBlSljxR50QTBnFWf1x_lGGCGX3Heyu26GclGxU0JHicBofRc30tkMPwflBfogvQXB29h9mHj0xhqHVfKBYAMdG9YZMwrbU9aiTu8O-KNcOcOxPoN61AOZhhyU2NIFl2xLb5blX6N9AoJiWvdY3d68-PhgH4D4K6OP3p0xu-XqseRn4t_s-pI6MWlK-u8kE40CqC1F7mPW3l1xtOMihUPIZHo2nwUuipt89DlshQYidvE9s3RLc3UJf-EmeDlACLyN8n4uIpjB-46Ln6y7fIRB4CSeKGVxlg5uYqVoudJ3j79UiGau6fDok28h0GHwaf8ZJWYWKIGivWQ-PTvvcY46aveUCQkmJrsi2z4j-Tv5tPEbsi8oSz10A8FR4NXztlYZ_g1B3Vq4sy5Z1Y6arMlY-0pcFy_y0XxYhx-QlbVtvvTSJSkaT8rJdNVuppsH-fwQV9vez51Jj0tms1Up8BGx4ambrFqfjsjH5pX15oDsnT5jl5F76NmaXgo",
	"target": null
}

Compute (CU)

The Compute Unit is tasked with the extraction, assessment, and regulation of the state of designated processes. Subsequent to the evaluation, it is accountable for conveying the outcomes of the specified message process back to the initiating Messenger Unit within the ao network.

Endpoints

GET /

Description

The health check endpoint for the Compute Unit service provides the Wallet address under which the Compute Unit is managed.

Responses

200 - Ok

Property	Description
address	wallet address
timestamp	current timestamp

Schema

{
	"type": "object",
	"properties": {
		"address": { "type": "string" },
		"timestamp": { "type": "integer" }
	}
}

GET /result/{message-identifier}?process-id={process-identifier}

Description

This result endpoint delivers the calculated outcome received as a result of evaluating the message identified by the message identifier.

The result may encompass Output, Messages, Assignments, and/or Spawns. Output serves as a reply to the message. Messages represent outgoing Messages, each to be transmitted to their Target process, by an ao Messenger Unit. Spawns represent the initiation of new ao Processes.

Resource Path Params

Param	Description	Value	Optional?
message-identifier	the message {TXID}	{TXID}

Query Params

Param	Description	Value	Optional?
process-id	the process {TXID}	{TXID}

Request Body

None

Responses

200 - Ok

Format: JSON

Property	Description
Messages	An array of outbox messages as a result of evaluating the message
Assignments	An array of outbox assignments as a result of evaluating the message
Spawns	An array of outbox spawns as a result of evaluating the message
Output	A string or object as a result of evaluating the message
Error?	A string or object that indicates an error occurred as a result of evaluating the message
GasUsed?	An Integer expressing how much resources were used in the evaluation

Schema

{
	"type": "object",
	"properties": {
		"Output": {
			"type": "any"
		},
		"Messages": {
			"type": "array",
			"items": {
				"type": "object"
			}
		},
		"Assignments": {
			"type": "array",
			"items": {
				"type": "object"
			}
		},
		"Spawns": {
			"type": "array",
			"items": {
				"type": "object"
			}
		},
		"Error": {
			"type": "string",
			"optional": true
		},
		"GasUsed": {
			"type": "number",
			"optional": true
		}
	}
}

Example

:

{
	"Messages": [
		{
			"Target": "mMmwJ_mpiLTgMvSB1kdcPyvpIz_J5vwHzpUbkkjoW3k",
			"Tags": [
				{
					"name": "Data-Protocol",
					"value": "ao"
				},
				{
					"name": "Type",
					"value": "Message"
				},
				{
					"name": "Action",
					"value": "pong"
				},
				{
					"name": "friend",
					"value": "2gUxSxHT6JSxS0sI_QNHrkVVWckFa2sya0zyLcCenRM"
				}
			]
		}
	],
	"Assignments": [
		{
			"Message": "J5ejQdDgElnQux2NPwIjpP_yvzTgOYXuMk297bvSnzM",
			"Processes": ["mvIkTIQHqK_dYN0i2exYJ0PBy0YCOdeiHQVyx5Smp_M"]
		}
	],
	"Spawns": [],
	"Output": {
		"friendlyMessage": "sending ping to mMmwJ_mpiLTgMvSB1kdcPyvpIz_J5vwHzpUbkkjoW3k"
	}
}

GET /cron/{process-identifier}?from={timestamp}&to={timestamp}

Description

Just like Scheduled Messages sequenced via ao Schedulers, Cron Messages generated and evaluated by an ao Compute Unit (according to Cron-Interval tags on the ao Process) may also produce Outboxes ie. outgoing Messages, Output, and/or Spawns.

However, unlike the Outbox produced by a Scheduled Message, Outboxes produced by Cron Messages are not cycled to ao Scheduler Units by a Messenger Units regular cycling operation. Instead these "Cron Outboxes" must be cycled separately.

The /cron endpoint retrieves all "Cron Outboxes", within a timestamp range. This endpoint allows an ao Messenger Unit to retrieve these Outboxes and cycle them to the corresponding ao Scheduler Units.

Resource Path Params

Param	Description	Value	Optional?
process-identifier	the process {TXID}	{TXID}

*_Query ParamS__

Param	Description	Value	Optional?
from	the left boundary timestamp (inclusive)	{TXID}
to	the right boundary timestamp (exclusive)	{TXID}

Request Body

None

Responses

200 - Ok

• a Connection page of any outcomes received as a result of evaluating Cron Messages within the range of from and to

Format: JSON

Schema

{
  "type": "object",
  "properties": {
    "hasNextPage": {
      "type": "boolean"
    },
    "edges": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "cursor": {"type": "string"}
          "node": {
            "type": "object",
            "properties": {
              "Output": {
                "type": "any"
              },
              "Messages": {
                "type": "array",
                "items": {
                  "type": "object",
                }
              },
              "Assignments": {
                "type": "array",
                "items": {
                  "type": "object",
                }
              },
              "Spawns": {
                "type": "array",
                "items": {
                  "type": "object"
                }
              },
              "Error": {
                "type": "string",
                "optional": true
              }
            }
          }
        }
      }
    }
  }
}

Example

{
  "pageInfo" {
    "hasNextPage": false
  },
  "edges":[
    {
      "node": {
        "Messages": [
          {
            "Target": "mMmwJ_mpiLTgMvSB1kdcPyvpIz_J5vwHzpUbkkjoW3k",
            "Tags": [
              {
                  "name": "Data-Protocol",
                  "value": "ao"
              },
              {
                  "name": "Type",
                  "value": "Message"
              },
              {
                  "name": "function",
                  "value": "pong"
              },
              {
                  "name": "friend",
                  "value": "2gUxSxHT6JSxS0sI_QNHrkVVWckFa2sya0zyLcCenRM"
              }
            ]
          }
        ],
        "Assignments": [
          {
            "Message": "J5ejQdDgElnQux2NPwIjpP_yvzTgOYXuMk297bvSnzM",
            "Processes": ["mvIkTIQHqK_dYN0i2exYJ0PBy0YCOdeiHQVyx5Smp_M"],
          }
        ],
        "Spawns": [],
        "Output": {
          "friendlyMessage": "sending pong to mMmwJ_mpiLTgMvSB1kdcPyvpIz_J5vwHzpUbkkjoW3k"
        }
      },
      "cursor":"1702947653338"
    }
  ]
}

GET /state/{process-identifier}

Description

This state endpoint delivers the process Memory as a result of evaluating the message identified by the message identifier.

This is the raw memory of the ao Process, as binary data.

Resource Path Params

Param	Description	Value	Optional?
process-identifier	the process {TXID}	{TXID}

Query Params

Param	Description	Value	Optional?
to	the timestamp of the message to evaluate up to (inclusive)	{TXID}

If to is not provided, the Compute Unit will evaluate the process up to the most recent Message.

Any Cron Messages in the range will also be generated, and merged into the evaluation stream.

Request Body

None

Responses

200 - Ok

Format: binary (application/octet-stream)

Messenger (MU)

The Messenger Unit holds the responsibility for accepting incoming messages from clients, routing these messages to the designated Scheduler, and subsequently retrieving the outcome from the Compute Unit. Additionally, it handles the processing of any messages or spawn requests to conclude the operational cycle.

Endpoints

GET /

Description

The root endpoint offers the ability to debug the messages being managed via this unit. You can enable the debugging via the debug param with a process identifier or a message identifier.

*_Query ParamS__

Param	Description	Value	Optional?
debug	this parameter flips on debug mode	true
process	the identifier of the process to debug	{TXID}
message	the identifer of the specific message to debug	{TXID}
page	the page number	{Number}
page-size	the amount of items per page	{Number}

Responses

200 - Ok

Format: (text/plain)

Example

: 'ao messenger unit'

POST /

Description

When posting to the root endpoint, the request body should have a valid DataItem that is defined as an ao Data-Protocol. This DataItem is validated and routed to a su based on the Scheduler tag. This data-item should be either a Message or a Process

Query parameters can also be provided to the base endpoint on the MU in order to post an Assignment. When posting an Assignment via query parameters, the request body should be empty

Request Body

Field	Description	Encoding	Length (in bytes)	Optional
signature type	Type of key format used for the signature	Binary	2
signature	A signature produced by owner	Binary	Depends on signature type
owner	The public key of the owner	Binary	512
target	An address that this DataItem is being sent to	Binary	32 (+ presence byte)
anchor	A value to prevent replay attacks	Binary	32 (+ presence byte)
number of tags	Number of tags	Binary	8
number of tag bytes	Number of bytes used for tags	Binary	8
tags	An avro array of tag objects	Binary	Variable
data	The data contents	Binary	Variable

Query Params

Param	Description	Value	Optional?
process-id	a Process TXID to write an Assignment to	{TXID}
assign	a TXID to assign to a Process	{TXID}
base-layer	If present in the url, the su will verify this is a base layer Arweave Transaction	{no value, present or not}

Responses

## 201 - Created

Schema

{
	"type": "object",
	"properties": {
		"id": { "type": "string" }
	}
}

Example

{
  "id": "TXID of the Message or Process data-item"
}

POST /monitor/{process-id}

Description

When posting to the this endpoint, the request body should have a valid DataItem that contains the process-id in the target field, that is the {TXID} of the Process DataItem. This same id should also be in the Url as shown above. The data field of this DataItem is not important here but the target and the signature are. After posting here, the MU will attempt to process scheduled messages on this processes on a timed basis with no further user interaction.

Url Param

Param	Description	Value	Optional?
process-id	the process {TXID}	{TXID}

Request Body

Field	Description	Encoding	Length (in bytes)	Optional
signature type	Type of key format used for the signature	Binary	2
signature	A signature produced by owner	Binary	Depends on signature type
owner	The public key of the owner	Binary	512
target	An address that this DataItem is being sent to	Binary	32 (+ presence byte)
anchor	A value to prevent replay attacks	Binary	32 (+ presence byte)
number of tags	Number of tags	Binary	8
number of tag bytes	Number of bytes used for tags	Binary	8
tags	An avro array of tag objects	Binary	Variable
data	The data contents	Binary	Variable

Responses

## 201 - Created

Schema

{
	"type": "object",
	"properties": {
		"message": { "type": "string" }
	}
}

Example

{
  "message": "A user friendly message from the MU"
}

DELETE /monitor/{process-id}

Description

When calling this endpoint, the request body should have a valid DataItem that contains the process-id in the target field, that is the {TXID} of the Process DataItem. This same id should also be in the Url as shown above. The data field of this DataItem is not important here but the target and the signature are. After posting here, the MU will stop attempting to crank scheduled messages for the process.

Url Param

Param	Description	Value	Optional?
process-id	the process {TXID}	{TXID}

Request Body

Field	Description	Encoding	Length (in bytes)	Optional
signature type	Type of key format used for the signature	Binary	2
signature	A signature produced by owner	Binary	Depends on signature type
owner	The public key of the owner	Binary	512
target	An address that this DataItem is being sent to	Binary	32 (+ presence byte)
anchor	A value to prevent replay attacks	Binary	32 (+ presence byte)
number of tags	Number of tags	Binary	8
number of tag bytes	Number of bytes used for tags	Binary	8
tags	An avro array of tag objects	Binary	Variable
data	The data contents	Binary	Variable

Responses

200 - Ok

Schema

{
	"type": "object",
	"properties": {
		"message": { "type": "string" }
	}
}

Example

{
  "message": "A user friendly message from the MU"
}