Introduction
Leveraging Olas autonomous agents technology with Shutter’s encrypted mempool this proposal outlines the technical design and approach Keyko would take to build agents that simulate regular trading human behaviour alongside standard MEV and front-running strategies. The specification below gives more details of the functionality and scope of the two groups of AI agents as well as common elements such as the transaction validation, database schema and dashboard design.
Technical Specification
Objective:
To deploy and operate two distinct collections of autonomous agents that simulate regular human behaviour across both non-encrypted and encrypted mempools. This simulation aims to gather data on transaction behaviours and the impact of using an encrypted mempool.
Detailed Plan:
Agent Deployment:
- Non-encrypted Mempool Agents: We will deploy autonomous agents to interact with the non-encrypted mempool. These agents will simulate typical human trading behaviour, which will help us understand how transactions are executed and the potential for MEV attacks in a standard environment.
- Encrypted Mempool Agents: Similarly, we will deploy another set of autonomous agents to interact with the encrypted mempool. These agents will follow the same simulation of human trading behaviour, allowing us to compare the impact of encryption on transaction execution and MEV occurrences.
- Transaction Logging: Each agent will log transaction details in a dedicated database. The database will include a Transactions table with the following columns:
| Name | Description |
|---|---|
| id: | Unique identifier for each transaction. |
| transactionId | Identifier of the transaction in the blockchain. |
| encrypted | Boolean flag indicating if the transaction is encrypted. |
| tokenSent | Type of token sent in the transaction. |
| amountIn | Amount of tokens sent. |
| tokenReceived | Type of token received in the transaction. |
| estimatedAmountOut | Estimated amount of tokens expected to be received. |
Transaction Process
The transaction process for each agent will unfold in several stages, ensuring a comprehensive simulation of human & bot trading behaviours:
-
Fetching Assets: Each agent will fetch the current assets in its wallet. This involves determining the types and amounts of tokens held.
-
Random Asset Selection: Agents will randomly select an asset to swap and a target asset for the swap. This randomness will mimic real-world trading behaviours and will ensure a wide range of transaction scenarios.
-
Liquidity Pool Analysis: Agents will then fetch the liquidity pools for the selected assets and estimate the amountOut based on the current liquidity and the amount to be swapped.
-
Transaction Payload Construction: After estimating the amountOut, agents will construct the transaction payload, which includes all the necessary information for executing the swap on the blockchain.
-
Submitting Transactions: Agents will submit the constructed transaction to the mempool. We will need to adjust the existing FSM (Finite State Machine) app used for transactions in Olas based projects in order to avoid waiting for transaction finalisation, which could slow down the process.
-
Recording Data: Finally, agents will record the transaction details in the database, ensuring that estimatedAmountOut is based on current liquidity pool data. After this, agents will restart the process, creating a continuous cycle of transactions. The following data items will be saved to the database for each iteration:
- Block number
- Block timestamp
- Number of transactions included in the block
- Mempool size
- Gas prices for transactions in the mempool
-
Optimised Amount Selection: The amount of the selected asset to be swapped will be determined using a machine learning model. This model will analyse past transaction behaviours and specify the optimal amount that minimises slippage and the ratio of fees to amountOut. Once this optimal amount is identified, a Gaussian distribution will be generated around this value to create a sense of randomness while ensuring that most transactions are close to the optimal value. For agents in the non-encrypted mempool, some transactions will intentionally have amounts and slippages that are susceptible to MEV behaviour to study these effects - Possible post v1 functionality
Objective
To deploy a suitable number of agents that specifically perform MEV strategies, with a focus on the sandwich attack. This will help us understand the effectiveness and prevalence of MEV strategies in non-encrypted environments.
Detailed Plan:
We will deploy a suitable number of specialised agents tasked with executing MEV strategies within the non-encrypted mempool. These agents will primarily focus on performing sandwich attacks, which are one of the most prevalent MEV strategies targeting normal trading behaviour. Detailed information about the strategy can be found in the MEV toolkit repository here.
Database Logging for MEV Agents
Each MEV agent will meticulously log transaction details into the MEV table of our database. To maintain clarity and facilitate easier debugging and future adjustments, each MEV transaction will be recorded on separate rows. The columns for this table will include:
| Name | Description |
|---|---|
| id | Unique identifier for each MEV transaction. |
| mevType | mevType: Type of MEV strategy employed (e.g., sandwich attack frontrun, sandwich attack backrun). |
| transactionId | transactionId: Identifier of the MEV transaction. |
| tokenSent | Type of token sent. |
| amountIn | Amount of tokens sent. |
| tokenReceived | Type of token received. |
| estimatedAmountOut | Estimated amount of tokens expected to be received. |
| targetTransactionId | Identifier of the targeted transaction. |
MEV Strategy Execution Steps
Each MEV agent will follow a series of steps to identify and exploit MEV opportunities. These steps will be performed individually based on each agent’s wallet and will include:
- Fetching Assets: The agents will begin by fetching their current asset holdings to understand the available tokens for executing MEV strategies.
- Scanning the Mempool: Agents will monitor the current mempool transactions, specifically looking for those that call one of the following functions based on the ABI of the swaprv3 Chiado contract:
| Chiado contracts |
|---|
| exactInput (0xc04b8d59) |
| exactInputSingle (0xbc651188) |
| exactInputSingleSupportingFeeOnTransferTokens (0xb87d2524) |
-
Liquidity Pool Analysis: Agents will fetch the liquidity pools for assets involved in potential victim transactions. This analysis helps in understanding the potential impact on the liquidity pool and the profitability of performing an MEV attack.
-
Profitability Calculation: Agents will calculate the profitability of executing an MEV attack on the identified transactions. This involves assessing the change in the liquidity pool, the slippage of the victim transaction, and the approximate gas price. The algorithm should also consider the possibility of sandwiching multiple transactions involving the same pair of tokens.
-
Execution of MEV Opportunities: If an MEV opportunity is deemed profitable, the agents will:
- Estimate the amountOut for both their own and the victim transactions.
- Construct the necessary transaction payloads.
- Submit the transaction pair for each targeted victim transaction to the mempool.
- Log the details of each submitted transaction pair in the database, ensuring the estimatedAmountOut is based on current liquidity pools.
-
Restart Process: After executing and logging the transactions, agents will restart the process. To simulate real-world competition among MEV bots, agents will randomly target different transactions. This randomness will prevent a single agent from monopolising all opportunities and allow for overlapping targeting, mimicking the behaviour of multiple MEV bots competing for the same opportunities.
Encrypted mempool research:
We’ll also research and try to implement MEV on the encrypted mempool to evaluate its viability.
Objective:
The goal is to ensure the accuracy and completeness of our transaction data by using dedicated agents or CRON jobs to verify transactions on the Chiado testnet and update our database records. This ensures that our primary trading and MEV agents can continue their operations efficiently without being slowed down by the need to wait for transaction results.
Detailed Plan:
To achieve this objective, we will deploy 3-5 verification agents or use CRON jobs that will operate independently from our primary agents. These verification agents will regularly check and update transaction details in our database, focusing on both the Transactions table and the MEV table.
-
Checking the Transactions Table:
- The verification agents will periodically scan the Transactions table for entries marked as updated = false. This flag indicates that these transactions need to be verified.
- For each of these entries, the agents will use the transactionIds to query the Chiado blockscout and fetch the latest information about each transaction.
- The purpose of this verification step is to confirm the success or failure of each transaction and gather additional transaction details.
-
Updating the Transactions Table:
After retrieving the verification data, the agents will update several columns in the Transactions table to reflect the verified transaction details:
| Name | Description |
|---|---|
| success | Indicates whether the transaction was successful. |
| tokenSentFinal | The amount present in the wallet of the sent token after the transaction. |
| finalAmountOut | The final amount of tokens received in the transaction. |
| tokenReceivedFinal | The amount present in the wallet of the received token after the transaction… |
| gasPrice | The gas price paid for executing the transaction. |
| mevVictim | Indicates if the transaction was a victim of an MEV attack. |
| lossToMev | The amount lost due to MEV (if applicable). |
| blockNumber | The block number in which the transaction was included. |
| updated | A flag to indicate that the entry has been verified and updated. |
- Updating the MEV Table:
Similarly, the verification agents will update the MEV table for transactions related to MEV strategies. The updates will include:
| Name | Description |
|---|---|
| success | Indicates whether the MEV strategy was successful. |
| failureReason | Enum indicating the reason for failure (e.g., transaction not performed, transactions executed outside the targeted window). |
| amountIn | The amount of tokens involved in the MEV transaction. |
| tokenSentFinal | The amount present in the wallet of the sent token after the transaction. |
| amountOut | The final amount of tokens received in the MEV transaction. |
| tokenReceivedFinal | The amount present in the wallet of the received token after the transaction. |
| gasPrice | The gas price paid for executing the MEV transaction. |
| profit | The profit earned from the MEV transaction. |
| blockNumber | The block number in which the MEV transaction was included. |
| Updated | A flag indicating that the entry has been verified and updated. |
Reasoning: The verification process is separated from the primary trading and MEV execution processes to avoid any delays that might arise from waiting for transaction results. This separation ensures that the primary agents can continue to operate at a high transaction throughput. By handling the verification and data update tasks independently, we maintain the efficiency of the trading and MEV agents while ensuring the integrity and accuracy of our transaction data.
This is a lightweight RESTful API for the Dashboard to access the transactions and agents data and also allow the agents and transactions monitors to populate the database. Endpoints to be defined in the first week of development.
We will develop a comprehensive dashboard to monitor the activities of all agents and display research results. The dashboard will feature:
- A screen displaying the current status and uptime of all agents, consensus, votings and transactions performed by them
- Table screens showing relevant statistics for encrypted, non-encrypted, and MEV sections.
- Filterable tables displaying actual rows saved in the database, useful for debugging and verifying transaction details.
- A screen presenting the research findings, highlighting the impact of the encrypted mempool on MEV mitigation and transaction behaviours.
- Normal Behaviour Trading Agents
- MEV Trading Agents
Challenges and Considerations
Algorithm Development for Simulated Trading Behaviour:
- One of the key challenges is developing algorithms that accurately simulate real-world trading behaviour. This involves selecting tokens and determining appropriate amounts to trade in a way that reflects genuine market activities.
Securing Sufficient Funds for Continuous Transactions:
- To ensure the agents can perform continuous transactions over an extended period, we need a substantial amount of currency in at least one token. This funding is crucial not only for the 20 trading agents but also for the MEV agents, as they require even more resources to execute their strategies effectively.
Implementing the Sandwich Algorithm:
- Creating the sandwich algorithm from scratch presents a significant challenge, as there are no readily available examples to follow. While there are some strategy descriptions and articles, the actual implementation will require innovative problem-solving and thorough testing to ensure its effectiveness.
Developing FSM Applications for Transaction Management:
- We need to implement Finite State Machine (FSM) applications to handle both the reading of liquidity pools and asset data, as well as executing swap transactions without waiting for transaction results. This implementation is critical to maintain the efficiency and speed of our transaction processes.
Integrating Machine Learning for Optimal Transaction Amounts:
- Integrating machine learning to predict optimal trade amounts based on historical data poses challenges in data selection, model training, and real-time application. This is vital for minimizing slippage and optimizing fee ratios, ensuring efficient and realistic transactions.
Project Delivery Timeline
For a project of this nature, we would typically propose the structure below with an initial validation exercise as part of the development phase to dive into any specific areas of focus in parallel to starting development. Beyond the development phase as we progress closer to an MVP/v1 we would then allocate time to refine the product and prepare it ready for deployment.
Once the barebones of the solution have been created during development we would work on a high paced iterative process of sprints adding new functionality and testing/proving out the implementation as the project progresses vs a big bang delivery and testing phased approach.
The Delivery phase would not only focus on priority fixes or enhancements prior to go-live, but also start to help shape up a backlog for future iterations/phases of development should the project be taken forward.
Based on the above we estimate an eight week delivery timeline on the basis that the finalised requirements and scope would be finalised in the early stages of development.
Project Phases Overview
1. Development Phase
- Duration: 6 weeks
- Objectives: Finalise requirements, design, implement, and test autonomous agents and dashboard.
- Key Activities:
| Activity |
|---|
| Review and refine project requirements. |
| Develop a detailed project plan and timeline. |
| Agent development and deployment. |
| Database schema design and implementation. |
| Dashboard design and initial development. |
| MEV dedicated research. |
| Initial testing and debugging. |
2. Delivery Phase
- Duration: 2 weeks
- Objectives: Refinement, fine-tuning, final testing, and deployment.
- Key Activities:
| Activity |
|---|
| Performance tuning and optimization. |
| Comprehensive testing and validation. |
| Final deployment and go-live preparation. |
Milestones
- End of Week 1: Requirements finalised and development started.
- End of Week 3: Initial trading agent FSM app and database schema implemented.
- End of Week 5: All agent types (non-encrypted, encrypted, MEV) developed and MEV additional research finished.
- End of Week 6: Integration of agents, database, and dashboard completed.
- End of Week 8: Final testing and deployment completed.
Key Considerations
- Algorithm Development: Ensure accurate simulation of real-world trading behaviour.
- Funding: Secure sufficient funds for continuous transaction simulations.
- Sandwich Algorithm Implementation: Develop from scratch, ensuring effectiveness.
- FSM Applications: Implement transaction management to maintain efficiency.
- Risk Management: Continuous assessment and mitigation throughout the project lifecycle.
Team Members
The team is led by the senior technical and architectural management of Samer, a long standing member of the Keyko team and extremely experienced in building solutions of quality across different technologies.
Alongside Samer, we have Carlos who is a senior full stack engineer with a Masters in AI and has recently completed the Olas Academy so knows how to work with Olas and build autonomous agents.
Then we have Alex who is also a senior engineer and has coding experience with Olas having shadowed Carlos during the Olas Academy in June.
Both Samer and Alex are planning to attend the Olas Academy further enforcing our knowledge and expertise with Olas and autonomous agents.
Finally, Huseyin completes the team, an experienced frontend developer, who will focus on the dashboard requirements visualising the behaviour and data exposed by agents and the complete solution.
Links below to their LinkedIn profiles and profile slides for each are available on request.
Samer Sallam - https://www.linkedin.com/in/samer-s-0968644/
Carlos López Riesco - https://www.linkedin.com/in/carloslopezriesco/
Alex Constantin - https://www.linkedin.com/in/alexmcon/
Huseyin Can Soylu - https://www.linkedin.com/in/hcsoylu/
Commercials
In line with the total budget available Keyko would be happy to engage with the rewards and incentives as laid out in the RFP and based on the completion and success of the project receive up to the maximum amounts available.
About Keyko
Formed in 2019, Keyko is a Web3 and AI engineering powerhouse with a track record of delivery for a number of high profile projects. We pride ourselves for going above and beyond the technology being built ensuring it meets business goals and we are delivering solutions in the most optimal way.
Keyko is actively working with Olas having already built AI Agent solutions to automate trading behaviour based on market data and is currently building agents for different use cases. We have a dedicated AI practice within Keyko made up of some great engineers and we are excited about the opportunity to work with Shutter on creating a great solution.
Website https://www.keyko.io
LinkedIn https://www.linkedin.com/company/keyko-ag/
Twitter Keyko (@keyko_io) / X (twitter.com)
Github Keyko AG (github.com)
Past Success Stories Success Stories Archive - Keyko