Architecture
Last updated
Last updated
Mimic protocol consists of three core layers: the Planning Layer, the Execution Layer, and the Security Layer. Each layer involves key actors and components working together to ensure deterministic task execution, reliable intent handling, and robust security for any kind of user operations. Below is a detailed breakdown of each layer and its responsibilities:
The Planning Layer is the starting point of the protocol. It allows users to define tasks—deterministic units of logic that evaluate predefined conditions. A task specifies the inputs it needs, the execution trigger, and the logic that processes those inputs to decide whether an intent should be generated. For instance, a user may create a task to monitor the price of a token and generate an intent to sell if its value exceeds a specific threshold.
Relayers are responsible for executing these tasks. Acting as decentralized operators, they fetch the required inputs from oracles, execute the user-defined logic deterministically, and submit the results back to the system. If the task conditions are met, relayers generate intents, which are then sent to the Execution Layer for further processing.
The oracles play a vital role in ensuring that tasks are based on reliable data. They provide cryptographically signed inputs, such as token prices, account balances, or other blockchain-related data. These inputs are validated to ensure they fall within acceptable ranges or consensus mechanisms, such as medians or averages. By integrating signed oracle data, the Planning Layer ensures that tasks are deterministic and verifiable.
In essence, the Planning Layer connects the efforts of users, relayers, and oracles to generate intents—user-defined requests to execute specific operations in the protocol. These intents form the output of the Planning Layer and serve as the primary input for the Execution Layer.
The Execution Layer acts as the central coordinator for processing intents. Once an intent is generated in the Planning Layer, it is handed off to Axia, the protocol’s central engine. Axia is responsible for validating the intent to ensure it complies with user-defined constraints and broadcasting it to a network of solvers.
Solvers, competitive entities within the system, respond to intents with execution proposals. Each proposal details how the solver intends to fulfill the intent, including fees, execution parameters, and estimated outcomes. Axia evaluates these proposals based on predefined criteria—such as execution fees, solver reputation, and timeliness—and selects the most optimal proposal through an auction-like process. The winning solver then executes the intent on-chain and submits proof of execution back to Axia.
This layer ensures that user-defined operations are executed efficiently while maintaining flexibility and scalability. By enabling competition among solvers, the Execution Layer maximizes efficiency and minimizes costs for users.
The Security Layer is the backbone of the protocol, ensuring that all operations are executed securely and reliably. At the heart of this layer is the Settler, a smart contract that validates the execution proofs submitted by solvers. The Settler ensures that the solver’s execution aligns with the original intent and user-defined constraints.
In addition to validation, the Settler facilitates the flow of tokens into and out of the system. It manages user deposits, withdrawals, and other token movements, ensuring that funds are only released when the conditions of the intent are fully satisfied.
Complementing the Settler is the Safeguards Engine, a protective mechanism that enforces additional conditions and prevents malicious or erroneous transactions. For example, it can ensure that a transaction does not exceed predefined slippage limits or violate other user-defined parameters.
Through this layer, the protocol provides strong guarantees of security and correctness, safeguarding user funds and maintaining trust in the system.
