Covenants is a suite of general-purpose multi-AMM financial factories to securely help Ethereum projects in building the financial aspect of their communities without development risks.
The core of Covenants is the on-chain AMM aggregator. With only one line of code, any dapps or organizations can use it for multi-AMM farming, token inflation, and other functionalities. All other aggregators — 1inch, for example — operate semi on-chain. While excellent at finding the best prices for trades, they process all transactions via their off-chain frontends. Smart contracts cannot read frontends, so they can’t interact with these aggregators. Only human individual wallets and off-chain arbitration bots can, and only for basic token swaps.
The Covenants AMM Aggregator is free from such limitations. It is equipped with AMM-standardizing Solidity APIs that smart contracts can read. This means that any wallet, dApp, Organization or customized smart contract can use it, and for much more than just token swaps. It unlocks different DeFi services like multi-AMM farming, token inflation and more. Currently, the whitelisted AMMs in the Aggregator are: Uniswap v2, Sushiswap, Balancer v1, Mooniswap v1 and Uniswap v3.
Covenants applications, such as Farming and Routines help teams to clone and deploy the secure contracts through Factories, guaranteeing to users that there are no bugs and criticality at the security level, intentionally or unintentionally. Cloning a contract that has already been developed, tested and used by many users is safer than re-deploying it from scratch. Devs also have the possibility of customization using an Extension to perfectly integrate cloned contracts in any project.
The Farming application provides general purpose multi-AMM Farming contracts that any Organization, DAO, individual wallet or customized smart contract can use to host a farming setup. By being clonable through a Factory, the use of these contracts allows users to farm with the confidence that there are no bugs or any malicious behavior from the team (because the core is untouchable), and developers can clone this widely tested and used code, focusing on the on-top application.
Different parameters of the farming setups are customizable:
- AMM and Liquidity Pool to use
- Reward token
- Setup duration and the start block
- The number of times to automatically renew the finished setup
- The minimum amount of staking tokens
This flexible design makes it easy to set rules for distributing rewards from a treasury or via minting, while preventing hosts from touching farmer tokens or manipulating rewards for positions, securing farmers from exploitation. Farming contracts support all the Aggregator whitelisted AMMs (including Uniswap v3).
Routines can be used to automate token supply inflation, treasury management, and any other financial operation that needs to be executed in precise, block-based intervals.
The protocol can mainly be used to manage the inflation of a token but, from a wider point of view, it is a tool of fundamental importance to manage the entire tokenomics of a project.
Besides deciding the amount of periodic inflation, it also allows for the deciding of whom to send the new tokens issued. This means that for example a part can be sent to the Treasury of the Organization, i.e. the public treasury, and a part to one or more operation wallets, i.e. private wallet managed by the team that carries out the technological development of the project. Consequently, if used in this way, part of the inflation serves to self-finance the team working on the project in a completely autonomous way.
Like Covenants Farming contracts, Routines contracts are designed to be hostable by any Organization, DAO, individual wallet or customized smart contract.
All Routines operations are fixed, and involve any combination of the following:
- The minting of token(s)
- The transferral of token(s) from address(es) to address(es)
- The swapping of token(s) within or among AMMs
- The burning of token(s)
Routines contracts can reward the manual execution of operations. Rewards are customizable as a % of all tokens involved in the operation. In the case of swap entries, the executor can choose to be rewarded with either the input token or the output token.