Skip to main content

Automated Operations

Our automated system implements automated risk management strategies and manages routine execution tasks. It encompasses bots, automated actions, and guardians.

1. Bots​

Bots are at the core of our system, responsible for fetching data from networks, assessing the current system state, and initiating actions as required. They can autonomously disassemble or adjust positions that may be at risk in response to certain triggers. These triggers include potential exploits, unusual pool behavior, and rapidly decreasing collateral ratios, among other predefined risk scenarios.

2. Automated Actions​

These actions are pre-defined parameterized transactions scheduled to execute at specific intervals (e.g., weekly, daily, or on specific calendar dates) or in response to particular alerts from our providers.

3. Guardians​

Guardians serve as the orchestrators of the system, managing multiple bots and automated actions across diverse networks. They require an Externally Owned Account (EOA) with the necessary permissions to perform the required transactions, adhering to predetermined ad-hoc policies.

Operational Flow​

These components fetch and process data to evaluate the system's status or define transaction parameters. If triggering conditions are met, actions are executed either through bots—reactive to different states—or automated mechanisms, based on time or alerts.

Deployment​

Deploying automated operations involves setting up the logic that determines the triggering conditions and the DeFi Repertoire strategies it will execute. A guardian role is created with a permissions policy crafted via DeFi Kit, containing the minimal set of permissions necessary for the established DeFi Repertoire strategies. This role is assigned to a guardian dedicated signer EOA for automated programmatic single-signature execution.

Examples​

Utilisation Rate Guardian​

This guardian mitigates the risk of liquidations or penalties. It comprises the following bots: Aave_v3 Bot Morpho Bot CompoundV3 Bot

Trigger Parameters​

The bots operate based on the following five parameters: Liquidity: The total available liquidity in the respective protocol. User Balance: The individual user’s current balance within the protocol. Multiplier: A factor that influences the conditions under which withdrawals occur. Minimum User Balance: The minimum balance a user must maintain to avoid penalties or unintended liquidations. Percentage to Withdraw: The fraction of the user balance designated for withdrawal.

Logic and Execution​

The withdrawal transaction is executed based on the following conditions:

Condition 1: The user balance must exceed the Minimum User Balance.

Condition 2: The user balance must also exceed the calculated threshold, Liquidity / Multiplier

When both conditions are satisfied, the bot will trigger a transaction to withdraw: user_balance * percentage_to_withdraw

Hack and Exploit Response Guardian​

This guardian reacts exclusively to alerts received from our alert providers, triggering immediate withdrawals of funds from protocols suspected of being compromised.

Workflow​

Alert Reception: The guardian continuously listens for real-time alerts from our alerts providers. Validation: Upon receiving an alert, the guardian validates the alert against predefined criteria to ensure it warrants action. Execution of Withdrawals: If validated, the guardian automatically triggers the withdrawal of all funds from the potentially affected protocol.

Aura Harvester Guardian​

The Aura Harvester Guardian is designed to automate the process of claiming and locking Aura rewards across multiple reward addresses. It counts on a single bot, the Aura HarvestAndRelocker.

This bot is responsible for claiming accumulated Aura rewards from all specified reward addresses. Once the rewards are claimed, the bot immediately locks them in the vlAURA contract, converting them into vote-locked Aura tokens (vlAURA). This process increases governance rights and maximizes reward potential.

The Aura HarvestAndRelocker bot can be scheduled to run at specific intervals (e.g., daily, weekly) depending on user preferences or market conditions.