Autonomy Network is a fully generalized and decentralized automation protocol. It allows anyone to automate almost anything on-chain. One interesting use case is automatic self-liquidations to avoid liquidation fees.
Abstract
We would like to propose an integration to add a self-liquidation feature for Kashi, but first it would be ideal to see how the community feels about a feature like this. Essentially, this would allow users to determine at what price they would want to liquidate their position without any liquidation fee from a bot.
Motivation
Currently Kashi has a liquidation threshold of 75%. This means that if the borrowed asset is worth more than 75% of the collateral, the borrower is at risk of being liquidated. Not only does the borrower loses its collateral but it is also required to pay about ~12% liquidation fee to the liquidator bot. In order to minimize losses, a borrower should be able to liquidate/exit their position before the liquidator bot.
To make a self-liquidation feature possible, automation is required, just like liquidator bots have to constantly be checking if the LTV has exceeded the liquidation threshold, a borrower must be able to constantly check the same, but in this case if their self-liquidation condition has been met.
Autonomy Network is a fully generalized decentralized automation protocol, functions can be automated to execute under any specified condition. With Autonomy a borrower will set a specific amount for when to exit their position, ideally some amount before the borrowed asset is over the liquidation threshold. That specific amount is a condition that wraps the repay function, this is then posted on-chain where Autonomy executors (anyone can be an executor) constantly monitors if the condition is met. Once the condition is met, Autonomy executors will execute the repay function and the borrower will exit its position without paying any fee other than some extra gas.
Specification
Potential native integration of Autonomy’s automatic self-liquidation feature on Kashi, but would first like to hear some comments and opinions from the community. We have already implemented a working MVP. We decided that the design should be minimal, just a toggle button and one input, but open to suggestions. The automatic self-liquidation feature only works on Avalanche, if you go into Kashi you should be able to see something like this:
Current set up offers xSushi holders 10% of closed liquidation, those between 75-77%.
I wonder how would this benefit xSushi holders who are not trying to self liquidate their positions.
Kashi is already a delicate network of contracts and I don’t really like the idea of adding complexity that we are responsible for in that regard.
I don’t hate that liquidations are handled externally and not so much a point of contention when they happen.
There may be other areas that could benefit from automation, could be worth exploring if appropriate.
Rewards are one that come to mind. Maybe filler bots if they can fill more reliably for cheaper somehow.
Think could be areas for collaboration though gut feeling is not in favor of this feature.
These are just initial thoughts, am interested to see how everyone else feels.
Much love.
Just wanted to clarify that self-liquidation would be optional, not enforced over liquidation bots.
I also wanted to add that we can make self-liquidations still pay a fee. In addition, some thoughts around economic benefits is that generally the less risky something is, the more someone is willing to use in larger amounts. In this case, the less risk of losing money there is to a user (through liquidation bot or a fee on self-liquidation), the more likely they are to borrow, and with larger amounts - that leads to more attractive interest rates which leads to more TVL in Sushi which leads to more fees for Sushi in general. That’s also only looking at Kashi in isolation - in reality Kashi is competing with much larger platforms like Compound/AAVE, which don’t have these features. Especially in these current market conditions, I think users are far more likely to choose Kashi in the 1st place compared to platforms that don’t have this feature. Also it’s already tested and can be made live in production in a week to maximise on the current market conditions to boost Sushi’s TVL
Regarding the contracts, the self-liquidation contracts are purely add-on, so Sushi’s current contracts are not modified in any way. Also for this feature we have been working closely with some people from the Sushi core dev team
There is another feature requiring automation that we are about to propose, however we wanted to get the general feeling of the community before we went ahead with a second proposal. But essentially, we have a stop-limit feature.
Thanks for the proposal @caraluna ! I think it would attract more users to use Kashi with this feature in place as they would certainly feel more in control. If it can be setup in a way that a % of the fee benefits xSushi holders I don’t think there’s any reason we shouldn’t support this
Good to see Autonomy’s MVP integration with Kashi on Avalanche. The project seems promising and has announced some major integrations recently. I would be looking forward to having this feature officially go live on Kashi.
Also, the stoploss order does sound like a sensible next step for the DEX.
In principle I like this idea. Maybe to start things off you could host this service externally (your own UI) and Sushi could add a link on the Kashi page to it. Once it has a more proven track record, it could be integrated. This could reduce the risk on users when borrowing on Kashi, and what’s good for users is good for Sushi
Of course this protection isn’t guaranteed. When price moves quickly and cascading liquidations start happening this may not be fast enough, but it’s a good safety net in most cases. Because there are still risks I’d like to see it as a separate service first. Nice initiative!
I am very happy to see that sushi is expected to integrate the autonomy network. I think there will be more and better functions after the integration of the two. I am looking forward to it.
It’s a really cool feature that could additionally saftey to the community and to Kashi. I like also your notion of having it as an optional feature. It really helps to avoid unnecessary costs for the user.
I thought this was relevant to highlight the cost. So basically you guys make the 10-30% of tx2 fee? Thats how you make money in this arrangement?
What happens if the liquidation is triggered and the estimated gas cost (tx2) is not sufficient? Because realistically liquidation events typically occur at times that the network is going haywire, so gas price spikes. I know it says you estimate the ‘worst possible’ but lets just say its still not enough. Does the txn fail and everything is sent back to the user and no liquidation occurs?
For instance, in the example above with a simple limit order, there are 2 transactions: tx1 (registration of the Request) and tx2 (execution of the Request). The user directly sends and pays for tx1, and the executing bot directly sends and pays for tx2. Obviously, the bot doesn’t do this for free — when a Request is executed, the user has to pay for the execution of that Request plus a small fee. The total cost of tx2 is therefore the gas cost of tx2 + fee. This fee depends on whether you pay with ETH or AUTO. If paying with ETH, the fee is an extra 30% of the execution cost of tx2. If paying with AUTO, the fee is an extra 10% of the execution cost of tx2.
If paying in ETH, enough ETH to pay for the total cost of tx2 needs to get sent along with tx1 (so that the user only has to make a single transaction directly in total). The transaction cost of tx2 depends on the gas cost and the gas price. The gas cost can be estimated, but the gas price is hard to predict since it’s in the future, and gas prices on Ethereum are notorious for being volatile and unpredictable. Therefore enough ETH needs to be sent in tx1 to pay for the worst-acceptable-case for the total cost of tx2. If the actual total cost of tx2 is less than this worst-possible-case, then any excess ETH is sent back to the user. For example if the user sent 0.01 ETH in tx1 to pay for tx2, and tx2 cost the executing bot 0.002 ETH in regular Ethereum transaction fees, then 0.002 * 1.3 = 0.0026 ETH would be sent to the bot in tx2, and the remaining 0.01-0.0026 = 0.0074 ETH would be sent back to the user in tx2. In reality, the UI of the integrating dapp would abstract away all this information.
If paying in AUTO, nothing needs to be paid upfront. This is because AUTO tokens can be transferred from the user to the Registry during tx2 to pay for its execution. This allows users to be able to keep their funds in their account and only pay for Requests that are actually executed. It also allows for tx2 to be paid for without the user ever having to manually buy AUTO, because the trading contract that’s used can buy AUTO on behalf of the user to pay for tx2 within tx2 itself. For example if the user is doing a limit order, then the trading contract can take some of the output tokens and sell them for AUTO in order to pay for the execution of the trade.
We don’t really make money in this arrangement directly, its an open network so anyone that runs a bot makes that 10-30% of the tx2 fee. Autonomy as a protocol does not gain directly from the incentive fees, the only gain is that the network becomes more valuable as more transactions flow through it, this is because it becomes more profitable to become an executor/run a bot.
Effectively what Autonomy gains from this feature is:
Increase the usage of our network, which in turn makes our network more valuable.
Building trust with the Sushi community (We started with self-liquidations, but we have other use cases ready to deploy, one of them is stop-limit orders.)
It is a valid concern with how that blog describes Autonomy. However, for this specific use case there is no need to prepay. The way we are setting it up is so that the fee comes out of the collateral at execution time. In the really improbable case that the fee is over 12% of the collateral, then not even the current liquidator bots would have the incentive to liquidate. It is also possible to set it up so that you can prepay the execution, but in terms of UX and for the reasons that you describe it might not be the best move.
