The Rebalancing Bot
This guide explores building a production-ready rebalancer automation, focusing on system architecture and components. We'll examine the various building blocks needed for a robust automation system.
Last updated
This guide explores building a production-ready rebalancer automation, focusing on system architecture and components. We'll examine the various building blocks needed for a robust automation system.
Last updated
Now that we've covered the fundamental API structure and workflows, let's proceed to design a straightforward Vault Rebalancing bot. This bot will automatically redistribute assets among Morpho Vaults
The complete example is available in the project's GitHub repository at https://github.com/Brahma-fi/console-automation-examples/tree/main/examples/yieldagg
To Design Our Rebalanceoor Bot, we need to define a policy that grants our bot permission to perform rebalance actions between multiple vaults. For simplicity, let's assume the bot only accepts USDC and rebalances between the top few vaults. The policy would look something like this:
Once we've defined our policy and registered our executor, we can design the full system end-to-end.
As users subscribe and unsubscribe from automation, the subscriptions endpoint would be used to fetch new and cancelled subscriptions. Our bot would keep track of the currently active ones. This can be facilitated with a persistent data storage layer like Redis or PostgreSQL, where the bot would maintain execution logs and current subscription statuses.
The trigger mechanism is straightforward: for each subscriber, the monitoring service would periodically check if the user's assets are currently allocated in the vault with the highest APY. If not, a rebalance trigger would be generated to move the user's position to the new vault.
This can be achieved using a simple cron monitor or a more sophisticated system like Temporal for a production-ready and more resilient system.
Once a rebalance trigger is generated, the bot proceeds to the callData generation logic, which would move funds to the new vault. Our bot should ensure that the new vault is one of the whitelisted vaults.
Once the callData is ready, our bot attests the request by signing the EIP712 message for execution. The signer would be the same as our registered executor. Key management should be handled carefully, using any of the available key managers or a simple vault-based plugin to secure the signing key.
After signing, the request is submitted to the execute endpoint, and a taskID or an error is returned.
Our bot polls the Brahma relayer to get the relayed transaction hash from the returned taskID. Once the transaction is relayed, it validates the user's state, and the monitor schedules the next interval to perform the check and run the automation.
We can also persist the executed transactions and logs in the datastore for better visibility.
When building automations, developers need to manage several critical components:
State Management: Tracking logs, execution states, and operational data
Monitoring: Implementing reliable job scheduling and failure recovery systems
Key Management: Ensuring secure handling and rotation of signing keys
Error Handling: Developing robust mechanisms to manage failures across components
The Brahma Builder Kit offers two approaches to handling these requirements: developers can either manage these components independently using the Execution Layer's core endpoints, or leverage the Orchestration Layer which abstracts these complexities. The Orchestration Layer provides:
Streamlined development process
Reduced boilerplate code
Built-in best practices for common automation tasks
Improved scalability and maintainability
By understanding both approaches, developers can choose the implementation that best suits their automation needs - whether it's direct control through the Execution Layer or the simplified development experience via the Orchestration Layer.
