Request: New Credit Manager limits for Brahma Vaults

[BROwan]

Brahma proposes Gearbox deploys a new credit manager with higher borrow limits (2000ETH, approx. 8% of the WETH pool supply) for Brahma Vaults. This will enable Brahma to scale and expand its offering of risk-managed vaults built on top of GearboxV2 more efficiently and drive further Gearbox TVL growth and pool utilisation.

Brahma’s TopGear Vault Intro

Brahma launched the TopGear Vault built on Gearbox V2 on the 8th of November. The vault aims to unlock the composable leverage and capital efficiency that GearboxV2 provides and allows users to earn leveraged stETH yield on their FRAX deposits with real-time automated risk management of positions.

The core value proposition of the vault is three-fold.

1. Real-time automated risk management of positions. While the power of composable leverage is endless, this leverage needs to be managed or the multitude of crypto risk factors (pegs, oracle deviations, SBF etc.) can lead a degen’s position into ruin. Those who don’t want to manage these risks themselves can simply deposit into TopGear and the vault takes care of the rest.
2. The missing middle. With the current minimum borrow amounts, smaller degens may be missing out on composable leverage. For example, a user wanting to take a 5x ETH borrow would need starting capital of around $18000. TopGear gives these users access to Gearbox even though Ivan hates poor people. And this access comes with automated risk management and complete gas cost subsidisation.
3. Withdrawal liquidity. Currently, the partial withdrawal of capital from a credit account is not enabled and users need to close their credit account to gain access to their capital. TopGear’s vault structure provides users improved withdrawal flexibility by utilising the liquidity in vault buffer funds as well new depositor liquidity.

Vault Progress and Scaling

The Vault had an initial cap of 350k FRAX and was filled within 72hours. In the weeks since, the vault has deployed this capital over two credit accounts and scaled into the leveraged long steth short eth position in a gradual manner to minimise risks. The vault has now reached its steady state at its current target leverage and the risk management and monitoring infrastructure is up-and-running.

Given the current eth pool maximum borrow limits of 600 ETH, the current ETH price and expected strategy leverage scaling TopGear to $1m TVL would require up to 5 separate credit accounts. Scaling to $10m TVL would require 50 separate credit accounts, hence the need for higher borrow limits in order to scale Brahma vaults in a more efficient manner.

Vault Details

Vault Page: https://degenv2.brahma.fi/vault/topgear
Vault Docs: https://docs.brahma.fi/products/degenvaults/topgear
Blog Post: https://blog.brahma.fi/introducing-topgear-vault-on-gearbox-v2/
Credit Account 1:
https://etherscan.io/address/0x51afdbA5596474C3a0aF60f5Fb091226Ac111e0c
https://charts.gearbox.fi/accounts/0x5887ad4Cb2352E7F01527035fAa3AE0Ef2cE2b9B/0x3EC781A1Eb9dc378e7b13c9B259f6eFb6eD95CD1
Credit Account 2:
https://etherscan.io/address/0x4bc42e9470199d8fdb831fdcb4db37c393a7b043
https://charts.gearbox.fi/accounts/0x5887ad4Cb2352E7F01527035fAa3AE0Ef2cE2b9B/0x3deCF4f183fDfC93F5B273A1cEFb4ef55532a38c

Stats

Nr. of deposits: 45

Average Deposit Amount: 8364.53 (FRAX)

Median Deposit Amount: 2500.55 (FRAX)

Total Gas Costs Subsidised: 0.0948ETH

Credit Account Position Summary (as of 30Nov)

Risks and Mitigants

Gearheads may be concerned about the risks that larger credit manager debt limits present to the protocol. These risks include bad debt risks and borrower concentration risks.

We believe Brahma’s risk management infrastructure provides a significant first line of defence for the protocol against bad debt. We also believe incentives are aligned here. Clearly, a liquidation event is the worst outcome for one of Brahma’s vaults and the risk management framework is designed with capital preservation given the utmost priority. This means vault positions are automatically reduced well before being flagged for liquidation.

More details about Brahma’s approach to automated position management are broken down below:

1. First and foremost, user capital must be protected. This means block-by-block monitoring of credit account health factors and positions are closed if the health factor drops below the hard limit. The key here is that de-risking should occur before a credit account is flagged for liquidation.
2. Secondly, the position leverage is continuously monitored. The position leverage is used to assess the overall position risk by analysing the liquidation point relative to previous moves and the current health of stETH liquidity pools. Continuous monitoring of oracle prices, Curve Pool states and interest rates provides actionable strategy intelligence. (A range-bound methodology is used to minimise execution costs and prevent over-trading)
3. Lastly, the differential between stETH staking yields and Gearbox WETH borrow rates are monitored and leverage adjusted to best capture opportunities.

For further details and a historical analysis of this framework in action, we refer readers to the TopGear blog post.

[Dnszzz]

Generally support the proposal. Long Live Brahma, Rohan and risk-managed vaults!

[bberry259]

Im very much in support of this.
Top class risk management and a way for plebs and poors to access the wonders of Gearbox.
As a user of gearbox and a holder of gear im in favour.

[apeir99n]

Main concern here is security… From security issues Gearbox isolates risks inside itself (and checks that all works as it’s designed), but using SC creates some additional risks to the system aka freezing of funds / losing control to SC etc.
So I’d prefer to see some generalized approach for such proposals:

1. Audit
2. Date of launch & History of incidents (if applicable)

I know that TopGear launched few days after Gearbox v2, but still @BROwan I believe you use some internal vaults design that previously were audited and were live for few months. Would be great if you can share this information.

@Van0k @0xMikko pls check proposal and share your opinion

[0xmikko]

Agree with @apeir99n about security and generalized approach there. @BROwan started pretty interesting discussion about p2p (protocol to protocol interactions). Let’s talk about limits nature:

Minimum borrowed amount is calculated to keep liquidations PROFITABLE. Gearbox should it keep always, it’s a core parameter which correlated with liquidation premium.

Maximum borrowed amount is calculated to keep liquidations POSSIBLE. In theory, it’s computed to be able to trade some most illiquid asset on the worst scenario market. So, the protocol should be ensured that during market turmoil, liquidators would be able to swap / unwrap this asset using allowed protocols.

So, even if we talk from permissionless position, these two reasons should be kept in mind. At the current stage, max limit is used to reduce the max potential loss barrier if a hacker could find a way to steal money.

I support the idea to have alternative p2p credit manager with higher limits and additional features / better parameters. However, DAO should have clear requirements for protocols to be added there:

• Have at least one security audit
• Do not use upgradable contracts
• Get confirmation from risk subdao that it the strategy could not invest all money in illiquid assets which could block liquidations during market turmoil
• Do not have super-user functions which could allow to execute any method with any calldata (it’s a potential threat)

Which perks could be provided to p2p credit managers:

• Lower liquidation premium => higher leverage if we can raise min amount. So, vault could collect money and deploy CA if it has at least X tokens.
• Partial withdrawals could be tested there with additional gas-consuming checks.

So, protocol2protocol CM is a good idea from all angles, it could help to test new features and achieve Gearbox leverage infrastructure vision.

[Van0k]

I believe Brahma only utilizes FRAX, WETH and stETH collateral in their strategy, holding all of their collateral in stETH with WETH debt. Unless stETH depegs significantly, this should be fine - liquidating 50000 stETH (assuming the mentioned $50M TVL target) would incur 0.5% price impact, so liquidation premiums can probably be safely reduced to around 2%.

I think we could explore additional controls for the new CM:

1. Limit the CM in general to more liquid assets - I think this would disqualify LUSD, GUSD, WBTC and sUSD compared to the primary CM, but the rest should be fine.
2. Considering that protocols would likely use liquidity for specific strategies, does it make sense to limit the allowed assets for each CA? E.g., for Brahma it would be FRAX, WETH and stETH only.

(2) is especially up to discussion, since this would require permitting an asset list with each issued DegenNFT - this could lead to governance bloat. But could be doable if this is a controller function and not a configuration one? Wdyt @0xmikko ?

[Van0k]

I believe SC risks on Brahma side could only lead to losses for Brahma itself and not Gearbox (i.e., if they lose control over the contract, they just get liquidated eventually with Gearbox recovering the borrowed amount).

It may be different if we enable partial withdrawals though, since it enables a scenario where an adversary takes control over the Brahma contract and then uses its access to partial withdrawals to exploit Gearbox somehow. Though I think it’s unrealistic as long as the SC doesn’t have any general-purpose “execute” functions.

I don’t think a full audit is required - which just have to make sure on our side that (as Mikko mentioned above):

1. The borrower contract is not upgradeable
2. The borrower contract does not have general-purpose execute capability (this includes being able to perform multicalls with arbitrary data in Gearbox, or arbitrary calls from the contract itself)
3. The borrower contract can’t do swaps with arbitrary paths (less sure about this one, up to discussion)

[0xmikko]

Cant agree with audit point, when DAO provides special terms for another protocol, it creates trust in users’ eyes. If so, DAO should be ensured that the contract is safe, any hack on 3rd party contract could affect Gearbox as well.

[BROwan]

Thank you for the prompt responses. I guess we are all in agreement that a protocol2protocol Credit Manager’s makes sense for Gearbox and integratoors. The main question centres around the requirements that protocols need to meet before allowing them to utilise these CMs.

I fully agree with @apeir99n that proposals of this nature should be standardised with clear requirements to streamline the process. Security is of utmost importance and protocol smart contracts that interact with gearbox contracts need to meet some basic standards. That being said, I second @Van0k’s point that Brahma smart contract risk sits with Brahma vault uses and are unsure if audits should be a requirement.

In terms of TopGear, the borrower contract that we want to use with the new credit manager is non-upgradable once deployed. Additionally, we do not have plans to utilise partial withdrawals until it is enabled by the protocol directly.

In terms of strategy risks, the TopGear vault has a clearly defined strategy and has been live for close to a month now. I think this is a good requirement going forward to allow the Risk sub-dao to assess concern with being able to liquidate larger positions. TopGear’s main market risk is its long stETH/ short ETH position so there should be comfort given stETH/ETH is one of the most liquid onchain pairs.

Our main concern is that the alternative (running many credit accounts with lower limits) has arguably the exact same market and smart contract risks but is just harder for the risk sub-dao to track and increases the vault’s execution risk. Not to mention the extra work and higher operating costs for integrating protocols that would otherwise be required to scale any product built on top of Gearbox.

[yaron]

From an economical risk perspective, it is best not to assume the vault would properly execute the described strategy.
But even under this assumption, FRAX currently has huge liquidity vs ETH.
According to our dashboard, over $60m of frax could be liquidated in one shot.

The current exposure of the WETH pool to stable coins is below $850k. And the rest of the pool collateral is fully correlated to ETH (ETH derivatives, and small amount of WBTC).

Hence, the protocol could successfully handle 2k ETH/FRAX liquidation.

Even if some critical bug in the vault code would somehow provide other form of collateral instead of FRAX, say CRV, the current LT, and lack of existing exposure to CRV should still make it safe to the protocol.

[0xmikko]

Sir, thanks for your proposal, I appreciate what you’re building, Gearbox protocol is a system, and DAO should discuss requirements first to approve such proposals. Otherwise, it would create manual procedures and reduce transparency.