Gearbox UX: Meet the Gearbots 🤖
Gearbox V2 was a milestone achievement for the DAO. Composable leverage in its true sense was finally brought to life with a massive product upgrade. While the product is the core of any project, over the months we have seen another aspect of the dApp gain traction. Of all the accounts that were opened, 67% used a new UX feature called “Ready Strategies” that can help you deploy your preferred strategy in a single click. And that’s what we wanted to keep building on in Gearbox V2.1, User Experience.
Learn more about V2’s progress in the monthly protocol update below
With that in mind, last week, we unveiled Gearbots and the idea through a YouTube stream with Mellow Protocol, Brahma Finance, Wonderland and Gelato Network. The stream talked about the need for automation in DeFi, it’s impact on UX, how Gearbots can be developed and possible applications we can develop for the bots. You can (and should) watch the stream on the link below, some true gigabrains combined together to brainstorm the next phase of Gearbox.
If you can’t watch the call for now, read on below to know about all the things discussed. The technical information shared in the article itself is in layman terms(It was written by a muggle afterall). To know the exact tech details, you should watch the same part in the recording or ask questions in our discord.
What are and Why Gearbots🤖?
You can watch this part here.
With V2, Gearbox improved the experience of users having to connect to another DeFi protocol through Gearbox and then going to their dApp to deploy the position. This was done by Ready Strategies. We further made them faster by enabling single click execution through multicall. But we noticed an issue still…
A Credit Account user still has to open their laptops multiple times and log on to our dApp to manually monitor how their Health Factor and position is doing. Further, the add collateral option has been used 1.74 times per account opened. This is an indication of how much manual intervention is required to operate a CA at the moment with automation not being possible at the moment.
There are third party methods and the option to build your own smart contract to help you automate this but neither are user friendly or entirely safe.
Brahma and Mellow protocol have come up with an alternative by building vaults on top of Gearbox and have done wonders for small sized depositors looking for leveraged farming. But users lose out on the flexibility of operating the CA with their preferred risk management. High value accounts further don’t have a solve in this regard.
And that’s why Gearbots🤖
Gearbots are open sourced, immutable, automation contracts that solve a particular pain point like managing HF above a level, creating stop losses, switching strategies and so much more. Combine them with Gearbox’s Credit Accounts and there is so much that is possible…
To describe it the way Brahma did:
“As an industry, we are moving more towards self custody, so having bots directly on your Credit Account is definitely a much easier way and safe way for the users to access automation without taking any additional smart contract risk.”
So what can Gearbots do?
Gearbots are going to have specific access types in which they can be coded. The creator will have the choice to restrict the use of the bot they have created to a certain specific set of users with permissioned bots. Or they can allow permissionless access to everybody. While we are still early with bots, there were a couple of strong and clear use cases with these methods where the bots can add significant value.
1. Automated portfolio management
The core feature of the bots is effectively to enable automated portfolio management. This effectively enables you to choose the bots you want to manage your strategy and let the bots take care of the execution. This will be massive leap towards making Gearbox’s UX closer to that of a CEX. And with some bots, maybe even beyond…
- Stop losses/Take profit Bot: Pick an exit price point for your position and once the oracle reaches the input value, your position will be auto closed.
- HF management Bot: Want to ensure your HF is above a certain threshold at all times? Just set it in and the bot will auto deposit your funds to the CA in order to avoid liquidations.
- Strategy management Bot: Strategy management bots effectively enable you to move your funds from a strategy to another basis your priorities. Want to only farm above 15%? Switch it on and the bot will move you to the pool with 15%+ APY if your strategy drops below it.
These are just initial examples and multiple more bots can and will probably be there. But how can users use these? Simple, for permissionless bots, they are going to be using “Trust models”. Every CA user can define their specific bots trust model values and have it customised. Even more customisation is possible as the user decides which all bots they want to use and which they don’t. And this brings all the CEX features ON CHAIN.
As Mellow quoted:
“We have a tool built for Health Factor and can build others. But it would be better if Gearbox could have one. Because if everyone would build this kind of solution on their site, this would be even less secure if there would be one solution that is outdated and everyone can use it. So I think it’s much better in terms of security and it’s really great that you’re doing this.”
While this is completely true for most individuals, there are institutions who use multisig to manage their portfolios. But at the moment there is no easy way to do it given repetition in signing. While we expect larger decisions and control to still be maintained by the multisig owners, more frequent actions like monitoring HF level above a certain threshold or exiting at a certain price can be coded in while reducing significant hassles. And thus is an even bigger UX upgrade for institutions. As for the bots, they can choose to make them permissioned and ensure that only the people authorised can set the parameters.
2. Trustless, On-Chain Delegated Fund Management
Speaking of institutions, we have been through a year of centralised crypto venture blow ups. Fund management in itself has had the “trust us” frailties exposed and creditors have been left at the mercy of the funds that borrowed too.
While there are genuine fund managers who build strategies that outperform, there are very few who do this on chain and trustlessly. With Gearbots, it’s now possible to create an on chain fund that’s easy to manage with automation while the depositors won’t have to give the custody of their funds to a third party. You’d still have to trust the competence of the fund manager but you can rest assured that the funds itself aren’t in their custody. Additionally, the choice of trades and farms they make is relatively safer owing to our allowedlist too. While the risk is managed as per the trust model chosen and the proof of reserves can be confirmed on chain any time.
As for creditors, you don’t need to worry about the “Yoo, uhh, hmm”s or being lied to about the leverage and other factors on play. By using Gearbots you can lend money knowing what the trust model is and verify all the fund’s claims on chain.
So how do I build a bot?
This part of the article is likely to be slightly technical but is full of alpha if you want to learn how bots work on chain. There are effectively four crucial parts to building your immutable bot contract on Gearbox.
- Execute(): the larger aspect of execute focuses on accessibility and who could access a bot that has been created. The user can effectively make a bot permissioned with restricted access or have a permissionless bot accessible to everyone.
The first one, permissioned bots. For example if you are an institutional player or if you are willing to build your own custom solution and not add it to the bot store which could enable others to access it. You can create a modifier in the code itself to make access limited to certain permissioned actors. This will enable you to control the accessibility of the bot
The other side of the bots is permissionless and it’s more related to automation using decentralized services like Wonderland or Gelato. So in this case everybody could execute this method. But how do you ensure it’ll work efficiently? - storeState(): This is the function which is effectively the parameter house of the bot. A user inputs their desired parameters to this before they run the bot in order to make sure it works as they intend to. These datapoints that ensure proper working is what we call a trust system.
Even if a user were to allow a 100 potential access points to their funds, they can take steps to ensure safety of these funds through the parameters they set. By using the storeState() function they can effectively create parameters for the bot to function on before the bot starts running. You can input your SL, HF protection and more on bots created by others and make the most out of it. - botMulticall(): this is effectively the executor of the bot contract. Available in the CreditFaçade directory, botMulticall has two crucial functions. It first calls the data to see what values various parameters would have. If the values are confirmed to be within limits by check(), the multicall function then goes ahead and initiates the swap to make sure that the strategy is executed.
- check(): Check function effectively looks at the values in the trust system and calculates whether or not the transaction execution values adhere to the same. One such example is slippage params. A bot checks and finds out that slippage input params while switching a strategy are lower than the actual, this will lead to the bot not executing the transaction and ensuring that the strategy is executed effectively.
To understand this in more depth:
From the above discussion, it became clear that two priorities while executing the above lie in:
1. Need for strong trust models- The goal isn’t just to automate, it’s to automate with efficiency higher than what we can manually achieve. In order to do so, parameters that enable ideal outputs need to be worked out in order to optimise for best results.
2. UI for users- We need to be able to communicate to users exactly the impact that is possible in terms of various risks, downsides and other likely scenarios in a manner that minimises jargon. A user must completely understand what all is possible with the bot when they deploy.
Code Example: Limit Order Bots
The code example was presented live by Dimitry from Gearbox. You can skip reading this section by watching their part of the video.
As limit orders suggest, you can effectively have a price priority model where your order is completed at the point where the market price becomes equal to the price you input to either go long or short on a position. Gearbox users who have connected these bots to their accounts can place limit orders and anybody, literally any party, can execute these orders if the conditions are met
The functions here have been designed in a manner that while this can be executed by anyone, no one else will be able to manipulate or edit the user’s input of the matching price. At the same time, since multiple swaps are required with tokens of varying liquidity we must also ensure that no attack is possible at the botmulticall level as it can be another potential attack vector. But it should still go ahead and do it’s core job of swapping the assets efficiently.
As stated above, we start with the execution function which here includes a “validate order function”. This function basically checks that’s order is not expired. Order is triggered if trigger price was set and basically that order can be executed.
In order to trigger the order we then validate the code through the check() function passing on the user inputs from the storeState() function. These are validated on our allowedlist based DEX adapters. In case of any other DEX, we would see the transaction revert and thus the allowedlist reduces the risk of price manipulation attacks for this too.
While we then go to the botMulticall if the check is cleared, we need to make sure that the base value of the assets doesn’t deviate significantly while the swaps are happening. In order to do so, we need to parse the tokens at multiple stages and ensure that their combined amount is close to the initial USDC while taking some minimal slippage into account. By reiterating these checks at all levels of the transaction we can ensure that the token swap doesn’t lead to unintended outcomes.
The balance check then also validates the overall output tokens being equal to the tokens the order specified. And another validation on whether the input token spent amount is correct. Once this is validated, the order is executed and the executed order is deleted in order to ensure that this isn’t executed twice.
While the above is enough to know how to create the bot, Gelato Network was kind enough to be a part of the tutorial and help us understand how to then go ahead and automate this smart contract. You can and should watch the below part of the stream to understand it in detail.
Dev resources: Making development easier
As you can see from the example above, it doesn’t take too long to code the bot as the code is a concise one. The above bot took about two weeks to create. Out of this, 4 days were spent on creating the bot itself while the remaining were spent on testing the bot for accuracy and correcting the code. While creating a bot might not take too long, it’s still a new thing and can be challenging. Thus, we intend on developing certain capabilities that can help the devs develop bots easily
- Template bot repository: A preferred way for devs is to often pick up a code and edit certain parameters or add their own bit in order to modify it to their liking. By creating a repo of template of such codes we can effectively help the devs adapt for their needs and build a strategy. This can be looked as a code validation set that is shared by multiple bots and thus infra can be created.
- Testing Suites: Given a lot of these bots will be created for Gearbox itself, having a testing suite for the bots people make reduces risk.
- Role management system: For gearbox, there aren’t too many “roles” that are to be created. Sytems are defined and thus defining their scope properly and getting them audited can help increase the safety levels as well as the ease with which the devs are able to create bots.
- Grants and Initiatives: The DAO currently has discussions open for people to propose initiatives they believe can add value. If you feel you have an idea regarding Gearbots or Gearbox in general but need support to build it, go ahead and propose it. If voted on, the DAO will grant the support required for you to build your proposal. You can check the details below.
The docs for bots are yet to be updated but you can check the developer docs for bots here.
There are also discussions regarding an SDK for Gearbox amongst more that can enable external devs to help understand and contribute. But for now, this is it on bots. We’ll be back with more updates soon!
If you would like to join — just get involved on Discord. Discuss, research, lead and share. Call contributors out on their bullshit and collaborate on making things better. Here is how you can follow developments:
- Website: https://gearbox.fi/
- dApp: https://app.gearbox.fi/
- User Docs: https://docs.gearbox.finance/
- Developer Docs: https://dev.gearbox.fi/
- Forum: https://gov.gearbox.fi/t/start-here-forum-rules/
- Blog: https://medium.com/@gearboxprotocol
- Github: https://github.com/Gearbox-protocol
- Twitter: https://twitter.com/GearboxProtocol
- Snapshot page: https://snapshot.org/#/gearbox.eth
- And, of course, the DAO working docs:
