Comment on page
Andromeda Messaging Protocol
The Andromeda Messaging Protocol (AMP) is an advanced messaging system tailored for Andromeda ADOs. It has been designed to optimize communication between ADOs, addressing common issues present in existing CosmWasm messaging protocols.
All ADO communication can be done through AMP. This means that ADOs would send their messages to AMP (The kernel) which relays it to the intended ADO. The AMP layer also interacts with the rest of the OS systems such as the Virtual File System (VFS), economics engine, ADO database.

This messaging system is primarly handled by our Kernel ADO and is aimed to solve the following problems:
Although not recommended, we have kept the option of sending messges directly from one ADO to another without passing through the AMP layer.
As you may know, standard messaging protocols on CosmWasm are limited when it comes to providing traceability of messages. This means that if contract A wants to send a message to contract C through one or more intermediate contracts, such as A->B->C, contract C has no way of knowing the original sender of the message, which in this case is A. This can lead to complications in verifying the origin of messages, and can make it difficult to accurately track the path a message has taken.
AMP takes care of this by keeping a record of the previous and original sender of a message.
The Andromeda Messaging Protocol has been designed to enhance the security of the system, providing an extra layer of verification to ensure that messages are only relayed through AMP by authenticated, Andromeda-certified ADOs. This guarantee helps protect the system from potentially malicious contracts, while allowing contracts instantiated using a certified ADO to securely and reliably send and receive messages.
The Andromeda ADODB keeps a mapping of ADOs and code Ids. To be a certified Andromeda ADO and interact with AMP, an ADO needs to be instantiated by one of the code Ids found in the ADODB.
Our AMP messages offer senders added control over their messages. Each AMP message can have two key parameters specified by the sender, including reply_on and gas_limit. The reply_on field defines when the message should deliver a callback to the contract, while the gas_limit feature allows the sender to set an upper limit for the amount of gas to be used.
The AMP layer also handles IBC calls between ADOs.
The Kernel ADO of each chain is responsible for handling and relaying IBC messages. When the Kernel receives an AMP packet So for example, if ADO 1 (On the Andromeda chain) wishes to send a message to ADO 5 (On another Cosmos chain) :

- 1.ADO 1 sends an AMP packet to the kernel on the Andromeda Chain.
- 2.The Kernel receives the packet, verifies it, and forwards it to the kernel on the receiving chain through a channel via IBC-hooks.
- 3.The Kernel on the second chain receives the packet,verifies it, and then forwards it to ADO 5.
It is important to note that every time the Kernel ADO receives a packet, it makes sure to verify that it is coming from a trusted and wanted source ensuring security and preventing malicious messages to be passed through the system.
ADOs use an Andromeda packet structure to communicate with the AMP layer. This
AMPPkt
structure stores details about the message sender and origin, as well as a vector of AMPMsg
struct containing the execute messages that require relaying to the intended ADO recipient. The packet may contain several messages which allows for message batching.
pub struct AMPPkt {
pub messages: Vec<AMPMsg>,
pub ctx: AMPCtx,
}
This struct defines how the kernel parses and relays messages between ADOs. It contains a simple recipient string which may use our namespacing implementation or a simple contract address.
If the desired recipient is via IBC, then namespacing (VFS) must be employed.
The attached message must be a binary encoded execute message for the receiving ADO.
Funds can be added for an individual message and will be attached accordingly.
pub struct AMPMsg {
pub recipient: AndrAddr,
pub message: Binary,
pub funds: Vec<Coin>,
pub config: AMPMsgConfig,
}
Name | Type | Description |
---|---|---|
recipient |