Frax Community Member and Gelato Team Member David Liebowitz
Summary
Create Gelato AMO to automate functions of Frax AMOs. Begin decentralizing select AMO functions such as FXS-1559.
Background
Gelato is a general purpose automation protocol on Ethereum that powers a decentralized network of bots to automate functions of smart contracts. For many projects such as Instadapp, Gelato is the go-to automation solution for automating their smart contract functions without projects teams becoming the central point of failure. For example, Gelato currently monitors over $200M worth of Maker positions which get auto-refinanced to Aave and Compound in times of market distress. In addition, the team behind the protocol built sorbet.finance, bringing limit orders and dollar-cost averaging to DEXs via tapping the liquidity of Uniswap on Ethereum and Quickswap on Polygon.
Abstract
If adopted, the proposal seeks to establish a Gelato AMO with the goal of automating the functions of Frax AMOs when possible. The AMO is essentially a wrapper that will be the entry point for Gelato to call certain functions on AMOs in order to execute their logic.
I propose the first AMO to be automated to be FXS-1559 since this is the most straightforward one. For example, the parameters can be set to “if $50000 of excess interest piles up, then the Gelato AMO will automatically buy and burn FXS and send FXS to veFXS holders.”
In the future, other AMOs that could be automated include the Curve AMO which automatically rebalances the Curve pool, Collateral Investor AMO which automatically moves idle USDC into select protocols, and FRAX Lending AMO that automatically mints FRAX into money markets.
Gelato bots only charge a small % fee (around 5%) on top of the regular Ethereum network fee Frax has to pay anyway.
Motivation
The motivation behind this AMO is that in order for Frax to truly become an algorithmic stablecoin, it needs to automate as many functions in the most decentralized way possible. Currently, AMO operations are controlled by the Frax team and although this is fine to start, it diverts focus away from developing frax and leaves the Frax team as the central point of failure if it is running its own bot infrastructure. By integrating the Gelato Network, Frax will be able to scale future AMOs seamlessly, making the protocol more robust, decentralized and efficient.
Moreover, starting this integration now will enable Frax to benefit from Gelato’s upcoming developer transaction mining program, where those dApps that channel transactions through the network get rewarded Gelato tokens in order to be able to participate in the upcoming GelatoDAO and have a say in defining the rules by which the executors bots have to abide by.
If i’ve red it correct, the main gain would be automated execution of currently manual actions by the FRAX team. The gelato network is used to ensure that this automation is safe and transparent. The automation, and upgrade thereof, will still be under control of the FRAX team, correct (which makes sense at the current state of the protocol)?
So automation has great benefit. Ensuring that actions are taken at the right time and according to predefined and transparent set of rules. We should also consider the cost/risk. 5% fee on ethereum network fees is negligable imo. The risk is however something I can’t assess, and am more worried about. The TVL metric you mention is promising, but I would love to hear from (security) experts on this.
The frax team will definitely still be in control about all the parameters of the protocol, the only difference being that now executing those functions at the right time is not only done by the descretion of the FRAX core team, but by the Gelato Network. The only thing Gelato can do is execute those functions at the right time, all the other control remains with the Frax team.
Depending what the function that will be automated does, there isnt really that much security related risk as well, other than all bots of Gelato being down at the same time. However this is the whole point about using a network like Gelato instead of having project teams do that centrally, you avoid having a central point of failure and added redundancy.
I understand that right now the FXS1559 contract is not called automatically, but manually by the FRAX team to burn / distribute FXS.
The long-term goal is to automatize all AMOs to ensure capital efficiency, based on some established metrics. But even with this framework implemented, the FRAX team would still be able to shut it down and switch to “manual mode”, so I do not see how this makes FRAX more trustless. The protocol will still be dependent on the FRAX team, codes the execution timing parameters, which can be changed at any time.
Without further knowledge of how Gelato works on a technical level and how much time it would take to debug/autdit this, I am not sure that setting the condition for a contract call execution is worth the risk. Also, gas costs would increase as well, which makes it even more complicated.
But given that the FRAX community stands for progress and innovation, I would kindly ask the author of this proposal for a more technical debate and outline the technical benefits of using his framework to make sure that technical aspects are communicated and well understood by the community. This would make it possible to evaluate the risk/reward of implementing another layer of complexity into the protocol. Also, I would like to know how the track record of Gelato is and how familiar the FRAX team is with the Gelato network.
Also, a 5% fee seems very high to be honest. It’s 10% of what veFXS stakers receive, who have locked their FXS capital long-term.
Also, how is this fee set? Is it hardcoded by the Gelato team? By a fee market? Do FRAX AMOs need to compete on a fee market for bot performance?
I suggest that the proposal should be rewritten to account for such important technical details.
Hi there, I will try to answer most of the questions based on the information given to me in this thread.
FRAX team would still be able to shut it down and switch to “manual mode”, so I do not see how this makes FRAX more trustless
This depends on the implementation. Preferably to provide the community with stronger guarantees that certain contracts will indeed get executed as promised, there should be no “stop switch” (only if a DAO representing the community controls it). However as the FRAX team currently handles all these executions themselves, I guess it is up to them if they would like to keep certain restrictions in calling certain functions to themselves or not. Gelato does not really have an opinion regarding that.
Without further knowledge of how Gelato works on a technical level and how much time it would take to debug/autdit this, I am not sure that setting the condition for a contract call execution is worth the risk.
Gelato has no impact on the code security of the functions it calls on e.g. the FXS-1559. It simply calls it like other EOAs would also call it. The difference being that rather than just the core dev team monitoring and calling it, you now have multiple parties that are running gelato nodes calling that function through the main Gelato.sol contract.
In terms of security, one thing that the main Gelato contract handles is the fee verification. Fees charged by Gelato operators are actually computed off-chain (most accurate way) and then passed as calldata to the function that will be executed. Gelato as the “middle contract” verifies whether the passed fee param corresponds to the actual gas consumption on-chain, making it impossible for bots to “overcharge”. You can see the logic that handles that here.
I would kindly ask the author of this proposal for a more technical debate and outline the technical benefits of using his framework to make sure that technical aspects are communicated and well understood by the community
I see the technical benefits being a) higher reliability & redundancy that desired functions are getting executed as expected at the right time without the frax team being the single point of failure and b) actually saving the Frax Dev team significant time which is normally being spend monitoring and maintaining these bots which can be allocated elsewhere (e.g. creating cool new features for the Frax Ecosystem).
Also, I would like to know how the track record of Gelato is and how familiar the FRAX team is with the Gelato network.
Regarding “track record”, best I could do atm is provide you with some links about the Gelato v2 instances deployed on mainnet and polygon where you can follow along with new executions happening regulary for various use cases (Refinancing Maker Vaults to Aave before they get liquidated on Instadapp, executing limit orders for users on Uniswap or Quickswap on Polygon, managing ETH balances for Chainlink Node operators and automatically topping then up, etc).
As an example, even under the recent market crashes where gas prices spiked to 3000 gwei, gelato bots had 100% uptime and secured multiple Maker Vaults on Instadapp before getting liquidated.
Also, a 5% fee seems very high to be honest
It is 5% of the network fee needed to execute a transaction, meaning if the tx x costs $100 it would be a $10 fee. Given that nodes often times have to cancel transactions midway through to void encountering costly reverts, I think this is reasonable. Probably will cut down the overall devops costs for the Frax team when accounting all of the overhead and time consumption around monitoring and managing these bots significantly.
Also, how is this fee set? Is it hardcoded by the Gelato team?
Yes, currently this param is set by the Gelato Core team. But starting early August we will have our DAO live which will take over these decisions. Frax will also have the ability to participate by automatically mining GEL tokens for using Gelato for automating its transactions, but we will release more info regarding these dev mining schemes in the near future!
Do FRAX AMOs need to compete on a fee market for bot performance?
No. Bots have sufficient capacity to serve all AMOs adequately without requiring fee competition between them.
Definitely let me know if there are still any things left unclear. Regarding how a technical implementation would look like, functions that should be automated simply have to be wrapped by a wrapper contract like this one:
Here you can see an example contract that utilizes gelato to call a function every time pre-defined account balances drop below certain thresholds, using the Gelatofied wrapper contract:
@fraximalistdave this is very cool - glad to see Frax community members in other projects that we can work with - would the FRAX treasury just pay into a transaction account for the gelato bots to pay for calling the functions?
Great response and appreciate your informative post. I definitely like this proposal and thin automating some portions of the AMO functionality is indeed a great idea.
Some questions I had personally:
1.) It seems like you guys are charging less for the transaction than it costs to execute as some form of promo/farming, is this correct? In your example, you said that a tx that would cost $100 costs $10 in Gelato which is definitely attractive if true.
2.) Are we able to give Gelato automation creds for poking public functions so that there’s no tragedy of the commons?
Currently the fee model is still pay as you use with no promo. E.g. if a complex transcation costs $100 in ethereum network fees, it would cost $105 with gelato ($5 gelato fee, sry math was off in my previous comment). However, we will start a “transaction mining scheme” in Q3 2021 where projects receive “rebates” in form of GEL tokens for using Gelato. This is actually meant to decentralize our governance to the projects that use us the most and can definitely be a good way to lower the overall transaction costs of the FRAX protocol. We will be releasing more information around that pretty soon.
Yes, usually projects add the modifier gelatofied() to their functions which limits the msg.sender to being the Gelato.sol contract where all bots have to go through. However, you do not have to restrict the actual public function itself that contains the logic which should be executed, you only have to restrict the logic which wrapps around that public functions’ logic and handles the fee payments. That way the actual function could still be executed without limiting it to Gelato, however the function which has the fee compensation is only executable by Gelato.
What would be the process to try this out?
Point me to the function which should automatically be executed by Gelato
We’ll deploy a wrapper contract around that specific contract where this function lives, on which funds can be deposited to pay for the execution of that function
If not defined in the function itself, we’ll add some requires that restrict the function to only be executable under certain conditions (e.g. every time the DAI balance of the contract exceeds X)
Funds (Ether or any ERC20) get deposited on the Wrapper to pay for executions
Monitoring and execution starts!
Time to get this live should be a day or two tops. We can start with a trial phase and if things work nicely slowly take this into prod!
That makes perfect sense, thanks @hilmarx. Especially #2 thanks for clarifying that up.
I think the best things to start out with as a demo could be our FXS-ETH TWAP or FRAX-USDC TWAP and then slightly more complex things that we will deploy in the next 10 days!
One thing we think about a lot when it comes to the TWAPs is that usually they aren’t updated for hours until someone really wants to mint/redeem FRAX at which point they update the TWAP and the average of the prices between a few hours is quite high and leads to a large arb that is unnecesasrily large for the protocol. Something that would be incredibly helpful is if the Gelato bots actually analyzed the state of the TWAP onchain and updated it if the deviation of the price was increasing past a certain range similar to how Chainlink nodes update their prices. You guys might have probably gotten similar requests when it comes to automation so I’m sure this probably isn’t new.
Overall, really cool ideas here and excited to implement something together going forward.
@samkazemian have you considered using Uniswap v3 oracles that do not require regular checkpointing anymore? My current understanding is that you only have to increase the array of historical price accumulators length once to a number that should be sufficient to store historical prices of up to 1 hour and then you should be good to go without needing that sort of automation externally to your system (users pay for that when swapping on Uni v3).
Gelato Legendary Member Ari dove quite deeply into that topic, happy to connect you to him on Telegram to discuss this (even though it doesnt use Gelato )
)