Auto-Leverage and Capital-Efficiency in the Borrowing Module
Tutorial to take advantage of Angle Borrowing Module capital-efficiency features
Angle Borrowing Module was designed in a way to maximize capital-efficiency of stakeholders when interacting with the protocol. This takes place at different levels in the protocol and opens the gate to several different operations:
- One-transaction leverage: if in a single transaction you deposit collateral and borrow stablecoins against it, the protocol leaves you the opportunity to swap your borrowed stablecoins against collateral. You can technically use this to increase your exposure to an asset in just one transaction.
- Liquidations without capital: during a liquidation, you have the opportunity to swap the discounted collateral obtained in stablecoins in order to repay the debt of the liquidated vault. This makes it possible to participate in liquidations without any capital commitment.
- Capital-efficient debt repayment: if in a single transaction you want to repay stablecoins and get collateral back from your vault, you can swap a portion (or all) of the collateral you should obtain to stablecoins to repay your debt. This means that you do not actually have to bring the stablecoins back in the first place.
In this guide, we intend to explain how developers should prepare such transactions to maximize the capital and gas efficiency of their interactions with the Angle Protocol Borrowing Module.
These capital-efficiency features are optional and reserved for advanced users or for users interacting with some verified user interface (like Angle Labs app). They require deploying and relying on some specific contracts with the right interfaces to perform the swaps at the right time and for the right amounts.
There are two main functions in the
VaultManagercontract in which this kind of feature can be used: the
angle()function and the
ActionType memory actions,
bytes memory datas,
bytes memory repayData
) public payable returns (PaymentData memory paymentData);
uint256 memory vaultIDs,
uint256 memory amounts,
bytes memory data
) public returns (LiquidatorData memory liqData)
Both of these functions contain a
dataparameter. This is what allows stakeholders of the protocol to specify a contract (
who) to perform swaps if needed. The
dataparameter can be used by the
whocontract to know which route it should use to do the swap.
VaultManagercontract expects that the
whocontract conforms to the
ISwapperinterface. This means that they must implement the
bytes calldata data
This function when called on a
ISwappercontract lets this contract know that it got
inTokenand that it should swap these
outToken. The execution of the transaction fails in the
ISwappercontract fails make sure that at the end of the call the
outTokenRecipientis not at least
Auto-leverage is the operation which allows people to get a an exposure to an amount of collateral greater than what they initially brought. Assume I bring 0.5 ETH, then by using the auto-leverage feature of Angle Protocol, I can for instance get an exposure to 1.5 ETH.
How to do this in practice?
Let's say you have an empty vault (with no collateral and no stablecoin) in a
VaultManagerwith ETH as a collat. If you want to get to get exposure to 1.5 ETH from 0.5 ETH, you need to call the
angle()function of the contract and perform the following actions (in the right order):
addCollateral: 1.5 ETH
borrow: 1 ETH worth of stablecoins
angle()function is coded in a way that in this case stablecoins are sent before collateral is given. As such, if you specify in your call to the
whocontract along with
dataneeded for this contract to know how to process the swap, then the operation will succeed even if the
msg.senderjust has 0.5 ETH in your balance.
In this situation, the
toaddress specified in the transaction should either be the
whocontract, or it should have approved the
whocontract for the collateral (for the
whocontract to fetch stablecoins from this address).
The flow of operations during the transaction is as follows:
VaultManagersends 1 ETH worth of stablecoins to the
whocontract (which should in many cases and depending on the implementation be the
- Assuming no slippage, stablecoins are swapped for 1 ETH and sent to the
msg.senderaddress (your address). The
whocontract could for instance perform 1Inch or UniswapV3 swaps.
VaultManagerfetches the 1.5 ETH from the
msg.senderaddress and concludes the transaction
After this, you own a vault with an amount of collateral of 1.5 ETH, and a debt worth 1 ETH. Beware though of liquidation risks with this auto-leverage feature: the higher the leverage you take the bigger the risk.
Liquidations and debt repayment correspond to the same situation in which the protocol expects to receive stablecoins and gives collateral in exchange for this.
Assume a liquidator comes to liquidate 1 ETH worth of debt in a vault and gets a 10% discount on the liquidated collateral: then this liquidator is expected to receive 1.1 ETH from the protocol and to repay 1 ETH worth of stablecoins to the protocol.
liquidatefunction, to perform such swaps, you should specify a
whocontract which supports the
ISwapperinterface, depending on the implementation of the
toaddress should be the
dataparameter given should help the
whocontract perform the swap.
Flow of operations is then as follows:
VaultManagercontract sends 1.1 ETH to the
whocontract swaps a portion (or all) these 1.1 ETH for 1 ETH worth of stablecoins
VaultManagerburns the 1 ETH worth of stablecoins from the
fromaddress given in the function. For this to work, the
fromaddress should have by the way given approval to the
msg.senderfor the stablecoin.
Last modified 4mo ago