Proposal to add Balancer BPTs as collateral

[The_Jabot]

Proposal to add Balancer BPTs as collateral on IP

Summary
This proposal is to begin adding Balancer LP tokens as supported collateral by Interest Protocol. Balancer LP tokens are yield-bearing tokens that accrue yield to the owners from fees and rewards. This proposal is for Balancer LP tokens generally, and B-stETH-STABLE specifically as a first Balancer LP collateral.

Overview

Interest Protocol and GFX Labs have worked to implement measures to add Balancer LP tokens as collateral, and to stake these for Aura Liquidity Provider reward tokens while in the Interest Protocol vaults, giving borrowers the ability to stake these assets where applicable, as well as the ability to claim any rewards for staking.

This proposal will require an upgrade to the existing VotingVaultController, to allow it to track the new vault type as well as registered BPTs.

The first asset to be proposed for listing is B-stETH-STABLE. This is a MetaStablePool on the Balancer protocol. MetaStablePools are made up of two assets that are tied together in some way, where one is generally pegged to the other. In this case, the assets are wstETH and wETH. MetaStablePools like this one incorporate a rate provider contract to determine the exchange rate between the two assets.

Like most other assets on Interest Protocol, the collateral will be wrapped by a Cap contract in order to limit the total supply allowed on the protocol, thus mitigating liquidity risk. In this case it will be wrapped by a new CappedBptToken Contract.

While the goal is to end up with a staked Aura Reward Token in the Interest Protocol vault as collateral, these tokens are not able to be transferred, so users must deposit regular Balancer LPs (BPTs) such as B-stETH-STABLE, and these must then be staked on Aura in exchange for the reward token. This staking is, of course, done in an automated way upon deposit into a user’s vault.

The reasoning for this is because if we look at the holders of B-stETH-STABLE on Etherscan, we can see that the overwhelming majority of these BPTs are held by the Gauge Contract. This is because in order to maximize rewards for your BPT, it should be staked on the corresponding gauge contract, in exchange for these Gauge Tokens.

However, if we further look at the holders of the gauge token, we can again see that the overwhelming majority are held by the Aura Voter Proxy. This is because one can further increase rewards by staking through the Aura Finance infrastructure, which stakes deposited BPTs for Gauge Tokens, then consolidates the voting power into the single Aura Voter Proxy contract.

So we can see that the majority of stakers are providing liquidity through the Aura Finance infrastructure, as the holders of the Aura Reward Token have a good distribution. Unfortunately, the Aura contracts do not allow the deposit of Gauge tokens for staking, only the underlying BPT, so this is why on Interest Protocol the listed asset will be the BPT, rather than the Gauge Token or Aura Reward Token.

Because BPTs, Gauge Tokens, and Aura Reward Tokens are all issued 1:1 with each other, our oracle can price all of them at the same value.

Staking is done via the Aura Booster Contract, which handles all of the staking, and delivers the Aura Reward Token in exchange for the underlying BPT. The logic to handle this is on the new version 3 Vault on Interest Protocol, the VaultBPT.

Parameters

Token Address: 0x32296969Ef14EB0c6d29669C550D4a0449130230
Capped Token address: Capped BPT contract
LTV: 60%
Liquidation incentive: 8%
Maximum Cap: 100k USD
Oracle Address:
Primary oracle: OutGivenIn oracle
Secondary oracle: MinSafePrice oracle
Price deviation: 5%

Liquidity

Market Cap: $110,000,000 USD
Liquidity: Redeemable at any time for underlying tokens of the pool
Volatility: Similar to ETH
24h volume: $4,250,000
90d volume: $427,250,000
Notable exchanges: Balancer Protocol

Technical risks

Type of contract: LP token
Underlying asset: wETH/wstETH
Time: 653 Days (Created August 17, 2021)
Value:
Privileges: Balancer Governance
Upgradability: None
Supplemental Information: Please read below for details on staking and how the primary risk (oracle manipulation) is addressed.

Staking In Detail

Staking BPTs while using them as collateral presents some challenges.

The first of which is that if the Aura Reward Token is not transferable, how do we liquidate a position if needed?

In order to achieve this, the transfer function of the VaultBPT is overridden to automatically unstake any staked BPTs therein. As the transfer function should only be called upon liquidation or withdrawal, this results in a smooth transition of staked illiquid Aura Reward Tokens to transferable BPTs.

In the case of a partial liquidation, all of the staked Aura Reward Tokens will be unstaked, but not all of the underlying BPTs will be transferred out from the Vault, so the vault owner will need to stake again in order to maximize the rewards.

Another challenge is that the staking of BPTs into Aura Reward Tokens happens differently than staking AuraBal, and we wanted the new vault type to be able to handle both.

AuraBal is similar to BPTs in the sense that it can be staked for Aura Reward Tokens, however rather than being an LP for the Balancer Protocol, AuraBal represents liquid veBal, (Vote Escrowed Balancer BPT). This token is not transferable, and represents the voting power for the Balancer protocol. More about veBal can be read about in the Balancer Docs, and more about AuraBal can be found in the Aura Docs.

Essentially, AuraBal can be staked by simply calling stakeAll() on its corresponding Aura Reward Token, whereas regular BPTs must first be staked into Gauge Tokens which must be sent to the Aura Voter Proxy contract in the correct way. Therefore, staking of normal BPTs happens via the Aura Booster Contract.

As part of the asset listing process, BPTs are associated with their corresponding Aura Reward Token so that staking can take place.

Claiming of Rewards

Rewards can be claimed regardless of liability, including support for extra rewards (supported by some Aura Reward Tokens).

For example, in the case of the token being listed, B-stETH-STABLE, standard rewards are paid in BAL tokens, and extra rewards are currently configured to be paid in LDO.

Claiming of extra rewards is an optional bool argument when calling claimAuraLpRewards() on the VaultBPT contract. Claiming extra rewards is gas intensive and so should not be done if there are no extra rewards to be claimed.

Rewards are always sent to the vault minter, and as such claiming rewards is not a permissioned function.

Claiming of rewards has the possibility of doing a solvency check if needed. While this consumes a lot of extra gas, it is needed because if any of the rewards or extra rewards tokens happen to be a BPT registered as collateral, then claiming rewards would transfer out all of the collateral without regard for any liability that may exist on the vault.

The solvency check only happens if the rewards or extra rewards tokens happen to be a BPT registered as collateral, otherwise, the solvency check is skipped, saving about 450k gas.

Original Oracle System

By far the biggest hurdle to this project is coming up with a robust and accurate oracle system to price BPTs as collateral.

The naïve approach to pricing an LP token is to simply gather the total asset values that back the LP (total balance of each asset multiplied by a known price) and divide by the total supply of the LP. So LTV / Total Supply.

We can call this price the naïve price, and if manipulation were not a factor, this would be the ideal price to use when deriving a value for BPTs as collateral on Interest Protocol.

If priced this way, a flash loan attack could manipulate the underlying asset balances in a significant enough way to alter the price of the LP token for a single block, allowing for malicious actions such as inflating the ‘price’ of the BPT, so a borrower on IP can borrow more than they should against their BPT collateral. If this attack can alter the balances enough to inflate the BPT price to a greater extent than the LTV, an attacker could walk away with a profit in borrowed USDi, leaving some bad debt behind.

A solution to price BPTs from Weighted Pools was already developed in principle by Revest Finance as described in this article. The implementation for weighted pools works based on this formula and has been tested to be accurate.

Importantly, this solution does not even ask the Balancer Vault what the pool balances are, yet is still able to accurately calculate the LTV of the pool, and so should be safe and resistant to manipulation.

The solution to solving this problem for StablePools / MetaStablePools unfortunately is less straightforward.

StablePools differ from MetaStablePools in that they are made up of two assets that are often similar in value, rather than two otherwise related assets. For example, the stable pool B-auraBAL-STABLE is a pool between AuraBal and the BPT B-80BAL-20WETH, which is the unstaked version of veBal. Therefore, these two should be roughly equal in value, as they represent the same underlying asset and functionality.

The solution recommended by Chainlink via this article is to use a method that we can call MinSafePrice. This method is supposed to calculate a safe lower bound for the true price of the BPT. Protocols can then use this MinSafePrice as the market price for the BPTs, resulting in a safe (if slightly undervalued) price for the collateral.

However, in testing, the results of this method are often slightly higher than the expected naïve price, which doesn’t make much sense if this price is supposed to be a lower bound.

This behavior can further be confirmed by an audit of Sturdy Finance which utilizes this type of oracle for StablePools / MetaStablePools. See QSP-4 of their audit report.

After trial and error with a number of other possible solutions, the best solution currently tested is to utilize the outGivenIn logic to determine if manipulation has taken place.

In essence, we can know the market exchange rate of the two assets in the pool if we can price them with external oracles. We can then compare this to the price rate computed by the pool.

This pool price rate is of course subject to manipulation, but we can detect this manipulation by comparing the result to the true market exchange rate.

In this way, we can confirm that manipulation has not taken place, and therefore utilize the naïve price.

More info on this can be found in this full technical writeup of the oracle systems.

[nekosan]

Hi Jake - just want to say tremendous effort on the oracle work the past few months. It must be an incredible feeling to finally get it up on the forum after going through so many iterations.

And thank you for the comprehensive post; I learned a lot about the Balancer/ Aura ecosystem and the thought process that went behind adding their assets as collateral.

I am going try to summarize the main points of your proposal for myself and anyone that wants the TLDR.

• Proposal will upgrade VotingVaultController
• First asset to be proposed for listing is Capped B-stETH-STABLE with an initial cap of $100k
• Users are to deposit vanilla BPTs into Interest Protocol. They will then be prompted to stake these tokens into Aura in order to earn additional yield.
• Rewards can be claimed regardless of liability and are sent to the vault minters address
• During liquidation, all staked assets are first un-staked and liquid-able BPT tokens are withdrawn from the minter’s vault and sold. The rest stay in the vault and the user will have to re-stake to continue earning Aura rewards
• The biggest challenge in this endeavor was undoubtedly the work to prevent oracle manipulation, particularly of stable and meta-stable pools
• Many designs were tried and tested that traded robustness and accuracy
• The outGivenin logic is the oracle design implemented, which in essence takes the naive price (TVL / Total Supply) and checks it against an external Chainlink oracle to see if manipulation had taken place

Please correct me if I’ve misunderstood anything. I also had two general questions:

• Protocol like Sturdy (and similarly Notional and Gearbox) already accept BPT collateral, though the markets are silo’ed and you are only able to borrow like-kind asset, eg borrow wETH against wETH-stETH collateral. What are the key considerations or challenges that’s different for borrowing stable against volatile collateral like what Interest Protocol is doing? With Sturdy, you don’t need to calculate the collateral value in USD terms(?), but I imagine both are still susceptible to flash loan / oracle manipulation attacks.
• The starting cap is for B-stETH-STABLE is $100k. What are the criteria you’re looking for before you are comfortable increasing the cap or adding smaller LSD-LP collateral such as rETH-wETH?
• Does a successful implementation of the outGivenin Oracle mean new LSD collateral added can start with a larger cap or it’s still advised that they all start at $100k first

Again, amazing job and excited for when the proposal is ready to be put in an offical vote!!

---

PSA: There are roughly only 100 B-stETH-STABLE LP Holders accounting for $110M in TVL , and our top #1 priority should be to cater to these holders (along with Chai LPs). Even if we can only serve a small handful of them, it would result in a significant increase in TVL and borrowing demand for Interest Protocol (and maybe even interest in IPT tokens too). While the availability of lend-side USDC remains a major bottleneck, we can explore other feature requests that we can fulfill as well.

As Paper said it best - lending is a commodity. Having a differentiated product (not fancy tokenomics) is what counts in the space and our attention needs to be on how to leverage the heck out of what Jake and co have built.

[nekosan]

Also noticed Aura just voted to migrate some of their older pools (including wstETH-wETH) So, I imagine we will add our first collateral after the migration has completed

https://vote.aura.finance/#/proposal/0x757de5a32aa632713773260db5ecd294d1a67a0a2047ce5e39e09e351694ced5

EDIT: looks like group 1, which includes wstETH-wETH), will be migrated onJune 5th if the vote passes.

Edit: ops it’s group 2

[The_Jabot]

Hey there, good summary!

Currently, in my opinion, the best solution for IP is the outGivenIn method on its own, with no secondary.

I have tested with the minSafePrice method as a secondary oracle, and generally, this works fine. But due to how the minSafePrice method works, as the price of wstETH deviates from ETH over time, the results from minSafePrice become increasingly skewed with respect to the naïve price. So we can expect this to eventually fail.

Regarding the questions you brought up, I think with simple (non-leveraged) borrowing like on IP, it comes down to borrowing power vs liability, and if we have a good oracle system, I don’t see why BPTs should behave any differently from any other token. Having a conservative LTV/Liquidation incentive helps with this as well.

I only suggested a lower starting cap here because this oracle design is the first of its kind, as far as I know. Once there is some TVL in BPTs, the community can propose a vote to increase the cap.

[The_Jabot]

Looks like the pool we are listing is in the second batch that will execute on the 12th. All we will need to do is get the new PID and rewards pool after this happens, and ensure all of the tests are still passing.
We can make the proposal after that point.

[IPTMan]

I started on this reply here but never hit enter - apologies to post now while poll is being run but since I am still undecided vote wise time to post…

A few comments first:

Congrats on getting this done!

Based on the length of the description on the basic technical details I can see multiple places for failure that begs questions. These BPTs aren’t just a standard ECR-20 wrapper or deposit/management methodology.

• What is the fall back here if various advertised aspects of the above technology fails? (can’t claim aurora rewards or whatever, take your pick of the steps listed in first post that fails for a user perspective - a bpt depositor and USDi borrower)
• Does the change to VotingVaultController create new protocol hazards either from a IP Smart Contract attack surface area standpoint or a collateral liquidation one?
• Doesn’t gas/tx costs mean there is some lower capital limits to make the rewards efficient? Is $100K effectively too low a limit for anyone other than a single user to perhaps use?
• Will BPT asset management in the UI require additional UI design/changes. (How is all of this going to track Balancer Aura contract changes?)

While I applaud the work done I have significant concerns we are building infrastructure that won’t have users, or worse we won’t have USDC (or really any deep USDi/stETH/ETH) liquidity for those users. I have stated for a while now that I personally would find use for Uniswap v3 NFT assets and these should be far simpler to implement oracles for than above. Which brings me to last questions regarding the extensive oracle.

It looks like two prices are going to be looked at:

1. Market price (determined by what?)
2. MinSafePrice (as calculated how/by what?)

and

3. looking at some ratio between 1:2 OutGivenin to:

@The_Jabot

In essence, we can know the market exchange rate of the two assets in the pool if we can price them with external oracles. We can then compare this to the price rate computed by the pool.

This pool price rate is of course subject to manipulation, but we can detect this manipulation by comparing the result to the true market exchange rate.

In this way, we can confirm that manipulation has not taken place, and therefore utilize the naïve price.

Which means when market IS being manipulated the ‘oracle’ is going to default to a known manipulatable price. I don’t understand this logic to the oracle when it is flagged as being manipulated or what the fall back ‘should be’ in this case.

• Given this is very new collateral is to the protocol how are we going to insure against losses and/or how does the protocol test this in some way to isolate/limit possible losses.
• Is this work expected to compliment IP deployment on Optimism in any obvious way?
• Will the work be available on IP deployment on Optimism or not?
• Lastly is there any reason not to LTV 50%: LIq 10% vs. 60%/8% etc. I don’t see any strong reasoning on LTV/LIq here.
• Can you clarify the 5% price deviation parameter risk?
• As well as Balancer Governance risks?
• Was there a formal audit of the new VotingVaultController?

UI for user is going to have to incorporate a liquidation monitoring feature to highlight user to following:

@The_Jabot

In the case of a partial liquidation, all of the staked Aura Reward Tokens will be unstaked, but not all of the underlying BPTs will be transferred out from the Vault, so the vault owner will need to stake again in order to maximize the rewards.

The following comment is a personal one and as a IP vault, USDi borrower user:

I personally don’t use Balancer for trading or for any liquidity on any chain so I do not personally expect to be able to make use of such a vault. It is my personal view given the structure and use in the markets that IP limits itself to a much smaller market by supporting the more complicated Balancer/Aurora assets than Uniswap v2/v3 assets that I have been asking for for months now and it is my hope that IP will look to what I see as a much broader market with these new collateral types given what I see as a lot of UI and Oracle headaches to be dealt with in IP with the more complicated BPT collateral being proposed here.

Comments As an IP delegate that will be voting: I know a lot of work has been done by team and the DC here is minimal (partly a concern the DC may not be big enough to have anyone use it) but given my voting power I’d rather be a clear yes after crossing t’s and dotting i’s than just willy nilly say yes because I can. I may just abstain vote here vs. doing a yes or a no but at least wanted to finally post ask the questions and make a more informed vote.

[The_Jabot]

Hello,

Addressing your first set of questions,

1. As the one who developed and tested this, all functionality is working as intended from a testing perspective, and I don’t see why this wouldn’t be the case after execution. The only thing more that could be done is a full audit, and I can’t say if that is in the cards for the immediate future. That being said, as all of the core contracts are upgradeable, just about anything can be fixed rapidly with an emergency proposal or a standard proposal if it’s not so urgent.
2. The upgrade to the VotingVaultController only extends the storage so that it can track BPT vaults in much the same way as it currently tracks Voting vaults. None of the changes are able to alter the memory currently used to track the Voting vaults, and there is no overlap in the Voting vault and BPT vault functionality.
3. The low cap initial cap of $100k will function as a proof of concept. Any issues that come up will be easier to fix this way (not that any are expected, but better safe than sorry). Once the community is happy and comfortable with this upgrade, anyone is welcome to propose a higher cap.
4. The UI/UX should only change by about the same amount as for the standard Capped assets. Deposit and stake happen in the same transaction. The user will have to mint a new kind of vault the first time (as with Capped assets), and from there, the only change is the claiming of rewards. The UI could conceivably determine if extra rewards are available and infer the required argument there, so the user doesn’t have to worry about it and can instead click a single claim button when ready to do so.
   While it may be annoying to have to re-stake in the event of liquidation, it is arguably more annoying to be liquidated at all, and IP’s liquidations are already more equitable for borrowers than other protocols.
   Perhaps there could be a pop-up reminder in the UI in the event of a partial withdrawal to remind the user to re-stake, but that is an edge case.

As far as your questions about the oracle, it works a bit differently than you have described. We need to get some documentation drafted that does a better job than my original description.

There was originally a plan to utilize the outGivenIn logic as the primary oracle and the minSafePrice as the secondary in a typical Anchored View system, as most other assets have. Both oracle types will revert if the price is out of bounds, such as during manipulation. This is consistent with all of our other oracles, such that if the main oracle doesn’t agree with the secondary, it will revert. There is no deferment to some other price.

However, the minSafePrice only has a very narrow band of edge cases where it additionally benefits the outGivenIn logic. This, combined with the recent hack of Sturdy Finance (who uses the minSafePrice logic themselves, something I argued against for our protocol from the start; see the original post, which was made before the hack took place), has been decided to utilize the outGivenIn logic only.

To clarify, this oracle will typically return the naïve price, which is manipulatable, but will only do so after confirming that the pool has not been manipulated and is trading at market rates. This is done by comparing the exchange rate of the pool to the expected exchange rate (derived from external oracles of the underlying assets).

While I am completely confident in this oracle, it is the first of its kind, hence the conservative starting parameters.

As far as your second set of questions,

1. The conservative cap, LTV, and liquidation incentive allow significant headroom even with the buffer allowed by the oracle. Even if manipulated to the maximum extent allowable by the oracle, no advantage would be gained in borrowing power as the LTV is sufficiently low.
2. The Optimism deployment will include the upgraded VotingVaultController, so minting BPT vaults is technically possible. Until any such assets are listed, this functionality will, of course, be unused
3. We want to have competitive LTV and liquidation incentives while remaining as safe as possible. The community is welcome to have a dialogue about more conservative or lenient parameters in a future proposal or by opposing the current proposal.
4. As the outGivenIn oracle is acting as a standalone oracle, the price deviation is reduced to 2%. The accuracy is generally more like 0.25%, so the buffer should not be a problem; for more info, you can read the full technical write-up.
5. Balancer’s and Aura’s core protocol functionality is immutable, and IP utilizes well-used pieces of each protocol. Borrowers posting BPTs as collateral should be doing so with knowledge of Balancer v2 and Aura protocol’s mechanisms.
6. There has not been a formal audit of the VotingVaultController at this time, but as mentioned previously, the added functionality there is very close to a copy/paste of the Voting vault functionality. There is also a simple registry for registered BPT assets as well.

[IPTMan]

Hello @The_Jabot Thank you so much for detailed response.

Lets see what we have.

@The_Jabot

As the one who developed and tested this, all functionality is working as intended from a testing perspective, and I don’t see why this wouldn’t be the case after execution. The only thing more that could be done is a full audit, and I can’t say if that is in the cards for the immediate future. That being said, as all of the core contracts are upgradeable, just about anything can be fixed rapidly with an emergency proposal or a standard proposal if it’s not so urgent.

Remind me as to time frame of an emergency proposal and what would be needed in that case (a proposal, then 2 days wait till vote, then another 5 before proposal can pass?).

@The_Jabot

The upgrade to the VotingVaultController only extends the storage so that it can track BPT vaults in much the same way as it currently tracks Voting vaults. None of the changes are able to alter the memory currently used to track the Voting vaults, and there is no overlap in the Voting vault and BPT vault functionality.

I guess we are going to find out on this one.

@The_Jabot

The low cap initial cap of $100k will function as a proof of concept. Any issues that come up will be easier to fix this way (not that any are expected, but better safe than sorry). Once the community is happy and comfortable with this upgrade, anyone is welcome to propose a higher cap.

I generally agree with this. I think my comments were the practical use and tx fees on the rewards functionality making 100K not so practical from a tx fees sense on any rewards. I think the $100k is reasonable for a test. I wondered whether we could isolate adding BPT to a new IP instance say on Optimism. Barring that as a user I may personally end up pulling my collateral, and go flat USDi until this looks ok. Even then any hacker might just wait until there are enough assets to execute an attack. Brings me to another question: What is the path to reporting a potential SC problem? Who does one contact, how, etc. to keep the report private until it can be addressed. I remember I found an issue in Maker that no-one noticed and it wasn’t clear who to report this too. I happened to know a few key developers well enough that I handed the issue off to them but it brought up a problem with how fixes would be deployed in a timely fashion so as not to reveal the bug so publicly so it could be exploited before an emergency fix could be applied (this was all called dark issues and dark fixes). There was no clear or clean solution to such things and to this day the issue I found still exists in the Maker system. To be clear this was not an exploit bug, just something no-one to date has noticed in the Maker vault system.

@The_Jabot

The UI/UX should only change by about the same amount as for the standard Capped assets. Deposit and stake happen in the same transaction. The user will have to mint a new kind of vault the first time (as with Capped assets), and from there, the only change is the claiming of rewards. The UI could conceivably determine if extra rewards are available and infer the required argument there, so the user doesn’t have to worry about it and can instead click a single claim button when ready to do so.
While it may be annoying to have to re-stake in the event of liquidation, it is arguably more annoying to be liquidated at all, and IP’s liquidations are already more equitable for borrowers than other protocols.

I think this was another issue that will need some sort of statement by IP. This is a new feature and as such use at your own risk and rewards may be impaired etc. My concern was that the UI might not be fully functional in these edge cases and our 1-2 BPT users might get upset. idk. I am just sensitive to UI changes because this can cause other issues. Fortunately the UI is not in governance control (directly) so issues could be (and has been) addressed in a reasonably timely fashion.

@The_Jabot

Perhaps there could be a pop-up reminder in the UI in the event of a partial withdrawal to remind the user to re-stake, but that is an edge case.

Definitely want to do this in some sensible way. On thing to consider in UI is that display elements need to be distinctly different than control elements. So display the status, and then have buttons that are supposed to address changing the status. imho

Now to the oracle

@The_Jabot

As far as your questions about the oracle, it works a bit differently than you have described. We need to get some documentation drafted that does a better job than my original description.

This one piece is what causes me significant pause here. I just don’t understand well the oracle logic. Like what happens if:

@The_Jabot

There was originally a plan to utilize the outGivenIn logic as the primary oracle and the minSafePrice as the secondary in a typical Anchored View system, as most other assets have. Both oracle types will revert if the price is out of bounds, such as during manipulation. This is consistent with all of our other oracles, such that if the main oracle doesn’t agree with the secondary, it will revert. There is no deferment to some other price.

I think this was my issue ‘what do these oracles revert to’ in which cases?

@The_Jabot

To clarify, this oracle will typically return the naïve price, which is manipulatable, but will only do so after confirming that the pool has not been manipulated and is trading at market rates. This is done by comparing the exchange rate of the pool to the expected exchange rate (derived from external oracles of the underlying assets).

This is the part I don’t understand. IF minSafePrice is found to be manipulated what is the fall back oracle price? What are these oracles going to revert to if manipulation has been found to have occurred.? I guess I will have to paw the full technical write-up again and see if I can make sense of this. Please do post a simple as possible kind of flow chart logic on the oracles. I am just trying to figure out what is going to be used if manipulation is happening since I don’t see how OutGivenIn and minSafePrice will be able to be used in this case.

@The_Jabot

As far as your second set of questions,

Pretty much clear on where we stand on this.

• VotingVaultController changes haven’t been fully audited
• Some lack of clarity on how the oracle works which I am still trying to sort.

As it stands here my personal reaction is that IP wants this but I have enough concerns on this one that if it were to pass I would be pulling my collateral and swapping my USDi for USDC until I am convinced these changes have not introduced exploitable hazards. While I can take these position changes myself and vote yes on the above, as a delegate I have to look beyond myself to other users. I am having a hard time voting yes potentially exposing others to hazards I don’t intend to expose myself to.

I think this is why I wondered what IP fall back cases are in various conditions:

• bpt collateral only exposed via some hack of the VaultController (this means IP potentially on hook for up to max bpt collateral value (which is what 160K based on LTV of 60 and borrow cap of 100K?). I am not sure we have enough funds for insurance or compensation in the case of such a loss.
• Oracle hack that leads to effective loss capped at 100K USDi - again do we have insurance for such a loss.
• If there is such an issue how fast can an emergency measure be applied?
• If the new vault controller exposes other assets (this means all collateral at risk) and perhaps is a reason to encourage people to temporarily reduce collateral and USDi exposure. But again a hacker might wait to execute a exploit until the protocol fills with collateral. This is a higher value event that even with something less than $1M of collateral isn’t easily dealt with from a user perspective.

I think before I can vote for this I want some clarity on what pricing oracle will be used in each situation, and what the emergency fall back position is from a smart contract change perspective (how long, and steps to carry out an emergency action), as well as what the protocol position would be if we faced losses in the 100-200K range or up to $1M.

For example how long would it take to basically revert the VaultController to previous version and could this be done?

Who actually monitors the protocol operationally against hacks, odd collateral, USDi, USDC movements and then who get notified to act?

I used to do quite a bit of software development on operational systems and we always were clear about what fall back positions were, or whether we simply couldn’t fall back on a particular upgrade and had to have developers on-call 24/7 to hammer out any operational issues with the live system. (this may mean taking down the system to fix it) I am really sensitive to this because I have seen critical upgrades that went well in development suites fail miserably when put formally into production.

Thank you again for previous and future replies and I look forward to hurdling this so we can move forward with new vault collateral types, and new/better oracles.

Lastly, I have an odd question regarding oracles. I was going to ask this of the oracle team at Maker but perhaps better to ask here. Why are oracles not returning prices based on liquidity depth. We all know that if I want to sell $100K of something I am going to get a different price quote than if I want to sell $1K. I have never understood why oracles don’t include such information as the depth of a market liquidity wise is just as important as the price that goes with it.

[The_Jabot]

@IPTMan

Remind me as to time frame of an emergency proposal and what would be needed in that case (a proposal, then 2 days wait till vote, then another 5 before proposal can pass?).

At the moment, an emergency proposal has a 24-hour voting period and then a 12-hour timelock. Exact times may vary slightly, as this is in practice measured in blocks.

@IPTMan

Brings me to another question: What is the path to reporting a potential SC problem? Who does one contact, how, etc. to keep the report private until it can be addressed.

Reports can be made on Discord by contacting myself, Getty, or anyone else on the GFX Labs team. In addition, the GFX team can be reached at team@gfxlabs.io.

@IPTMan

I just don’t understand well the oracle logic. Like what happens if:

@The_Jabot

There was originally a plan to utilize the outGivenIn logic as the primary oracle and the minSafePrice as the secondary in a typical Anchored View system, as most other assets have. Both oracle types will revert if the price is out of bounds, such as during manipulation. This is consistent with all of our other oracles, such that if the main oracle doesn’t agree with the secondary, it will revert. There is no deferment to some other price.

@IPTMan

I think this was my issue ‘what do these oracles revert to’ in which cases?

@The_Jabot

To clarify, this oracle will typically return the naïve price, which is manipulatable, but will only do so after confirming that the pool has not been manipulated and is trading at market rates. This is done by comparing the exchange rate of the pool to the expected exchange rate (derived from external oracles of the underlying assets).

@IPTMan

This is the part I don’t understand. IF minSafePrice is found to be manipulated what is the fall back oracle price? What are these oracles going to revert to if manipulation has been found to have occurred.? I guess I will have to paw the full technical write-up again and see if I can make sense of this. Please do post a simple as possible kind of flow chart logic on the oracles. I am just trying to figure out what is going to be used if manipulation is happening since I don’t see how OutGivenIn and minSafePrice will be able to be used in this case.

I think there is still a misunderstanding as to how the oracles are working in general on IP. When I say ‘revert’ I mean that the transaction will literally revert. This is the case with all oracles on IP, such that if the price is deemed invalid, then the transaction that is reading the price will revert as if it never happened.

In the context of our BPT oracle, this is specifically to protect against flash loan attacks. Without getting too into detail, an attacker could borrow a large amount of the underlying assets of the pool, deposit into the pool in the same transaction (thus making the value of the pool seem higher, and therefore the value of the BPT), and then borrow more than they should be able to against the BPT. But because this would affect the exchange rate, this manipulation would be detected and the transaction would revert. So the attacker would not be able to take the loan in this way.

There is no deferment to some other oracle if manipulation is detected, and the minSafePrice oracle is not being used in the final implementation.

I’ll work on getting some documentation up for this soon.

Also, this is for the StablePool and MetaStablePool oracles specifically. The weighted pool oracle works differently, and in contrast to most oracles on IP does not actually revert if manipulation is taking place, as it will still return a safe price even in the case of manipulation.

@IPTMan

bpt collateral only exposed via some hack of the VaultController (this means IP potentially on hook for up to max bpt collateral value (which is what 160K based on LTV of 60 and borrow cap of 100K?). I am not sure we have enough funds for insurance or compensation in the case of such a loss…

I also wanted to clarify how the cap works. The cap is in terms of token amounts that may be deposited. So a ~$100k cap works out to about 60 tokens, as they are worth about $1700 each. The borrow cap could then be calculated by (cap * token price) * LTV.

@IPTMan

As it stands here my personal reaction is that IP wants this but I have enough concerns on this one that if it were to pass I would be pulling my collateral and swapping my USDi for USDC until I am convinced these changes have not introduced exploitable hazards.

Assuming governance passes this collateral proposal, and perhaps it won’t, any other deployment of Interest Protocol that is operational would be economically insulated from any of the potential risks you have outlined here, and may be a way for you to continue to support IP while waiting for some “lindy” to accrue.

Additionally, borrowers with any other collateral are not exposed to these risks. Only those borrowing against BPTs and USDi holders are exposed to any potential risks.

@IPTMan

Why are oracles not returning prices based on liquidity depth. We all know that if I want to sell $100K of something I am going to get a different price quote than if I want to sell $1K. I have never understood why oracles don’t include such information as the depth of a market liquidity wise is just as important as the price that goes with it.

This is a great question. Most caps have been chosen on the basis of liquidity where large amounts of slippage (~10% or more) begins to cascade. These should be periodically reviewed unless an oracle as you describe can be economically built. At Maker, there is a dedicated risk team for this. At IP, it would make sense to set regular dates for someone to check that on chain liquidity has not substantially decreased for any capped collaterals. That would be a useful governance task to coordinate if you or some other stakeholder would like to take that on. Otherwise, someone like PaperImperium will probably need to mark his calendar until a formal review process can be established.