[BIP-339] Enable Stafi rETH/WETH Gauge 10% Cap [Arbitrum]

BAL Gauges
1

PR with Payload

Authors: StaFi Contributors

Summary:

StaFi proposes the creation of a Balancer gauge for a rETH-ETH pool on Arbitrum, with a 10% emissions cap. This pool will be enrolled as a core pool as well due to the yield bearing token it contains.

Protocol Description:

StaFi is a liquid staked derivatives protocol launched in Q3 2020, with a focus on bringing liquidity to staked assets on Ethereum and other Proof of Stake chains such as Polygon, Solana, and Polkadot. Since launch, the protocol has accrued over $36,000,000 worth of staked assets across 11 tokens, with 3,439 active validators.

Similar to other LSD protocols, StaFi issues a liquid receipt token (rETH) representing your share of ether staked on the Beacon Chain via a permissionless validator set. Deposits are partially covered by validator deposits. The exchange rate between rETH/ETH will gradually increase as staking rewards accumulate, though rETH is not redeemable for the ether principal and rewards until after the Shanghai upgrade.

StaFi has a native governance token with the ticker “FIS”. FIS is freely tradable on a number of centralized exchanges, alongside some decentralized exchanges not inclusive of Balancer. FIS has governance utility and can be staked by validators in the StaFi consensus network.

Motivation:

StaFi currently has an existing rETH-ETH pool on Balancer on Mainnet which has seen healthy growth.

StaFi is looking to expand the availability and liquidity of its staked derivatives, starting with rETH, through Balancer on Arbitrum. Ahead of and after the Shanghai Ethereum hard fork, liquidity and yield on LSDs will be a key competing factor as LSD protocols seek integrations and a broader base of holders.

StaFi is committed to driving value to the veBAL and vlAURA ecosystem by incentivizing pool liquidity via Hidden Hand voting incentives. Deeper liquidity should lead to increased volume and revenue accrual.

Specifications:

Governance: DAO forum

Oracles: Direct Balance Query: The rETH rateProvider has a getRate() function that is defined by the rateProvider it points to. See the contract here.

Audits: StaFi rToken App Audits

Centralization Vectors:StaFi’s rebalancing is done by a bot that is run by the foundation. Presently the bot is not profitable to run, so we would not expect anyone else to run it. However, there is no chance of money being inaccessible as a result of the bot stopping–Just that the bridge would run less efficiently.

Market History: rETH has been a tradable asset since March 2021. Trading has primarily taken place in the aforementioned rETH-ETH pool on Curve. FIS is a liquid asset traded both on top centralized exchanges as well as decentralized exchanges.

Value: StaFi will make its Balancer rETH-ETH pool a primary source of liquidity for rETH on Arbitrum. By bolstering liquidity of the pool, Balancer should gain from increased trading fees.

Links & References

Website:https://www.stafi.io/

Documentation:https://docs.stafi.io/

Github Page: stafiprotocol ¡ GitHub

Communities: Community | StaFi

Other useful links: https://twitter.com/StaFi_Protocol

Pool: 0x01990f1e6f7F32296f125eE9469705C1C070054D

10% capped gauge: 0x870Cd189889C1117b33bc8c94394a7477d4EB6fa

Transaction Specification:
The Balancer Maxi LM Multisig eth:0xc38c5f97B34E175FFd35407fc91a937300E33860 will interact with the GaugeAdderv4 at 0x5DbAd78818D4c8958EfF2d5b95b28385A22113Cd and call the addGauge function with the following arguments:
gauge(address): 0x870Cd189889C1117b33bc8c94394a7477d4EB6fa
gaugeType(string): Arbitrum

1 Like
2

https://snapshot.org/#/balancer.eth/proposal/0x1892b56aeb8b8de635fec6b19abb5dd52848b808c2a293bdf746f71f607330ad

1 Like
3

I might be missing something, but this pool’s rate provider is set as 0xd8737ca46aa6285de7b8777a8e3db232911bad41, which in turn points to 0x6c2f7b6110a37b3b0fbdd811876be368df02e8b0, which doesn’t look like it calls rETH’s getExchangeRate() function. Instead, it seems to return a rate that can be set by the owner or a set of signers.

4

Hey you’re right, forgive my oversight as I trusted the original author on the getExchangeRate function. The rate provider returns getRate() which comes from the rate provider it has set as you described. Waiting for response from integrations and rETH team to give some more context on this.

5

Hey there, Rab from Integrations doing a skim review upon request.

This RateProvider does not invoke rETH.getExchangeRate() - it cannot do so because the Arbitrum deployment of rETH is a bridged token (StandardArbERC20).

The trust assumptions for this RateProvider are pretty extreme:

  • The owner (EOA) of the RTokenRateProvider can arbitrarily change the underlying _rateProvider.
  • The current _rateProvider has:
    • An owner (same EOA) who can arbitrarily set the rate without limit and without emitting a SetRate event.
    • A set of subAccounts which acts as a “multisig” for voting on rate changes.
      • The following rules are enforced within the voting process:
        • A threshold of yes votes is required to pass the vote.
        • The rate cannot change more than the rateChangeLimit (currently 0.1%) in a single proposal.
      • However:
        • The owner can arbitrarily add or remove subAccounts.
        • The owner can arbitrarily change the rateChangeLimit.
        • The threshold is currently set to 1 vote.
3 Likes
6

Strongly against putting the pool on gauge as the rateProvider can be easily manipulated.

1 Like
7

Agree, would like to have the Stafi team weigh in on this to see if additional safeguards can be put in place prior to voting or making a decision.

1 Like
8

Yeah - additional safeguards are mandatory.

1 Like
9

wonder how the trust assumptions of eg the rate provider in BIP-340 compare to this?

2 Likes
10

Also wondered about that. @rabmarut is it worth integrarions sharing in BIP-340the specifics that you folks id’d?

11

also wonder how the trust assumptions of eg the rate provider for wjAURA compare to this?

12

In the BIP-340 proposal i did add comments direct from rab (integrations team) under the oracles section for reference.

13

Hi, I’m from StaFi. We are very glad to see everyone’s in-depth discussion on this proposal. As @rabmarut mentioned, the current rate provider does need to be optimized. In fact, we hope to use Chainlink or Layerzero solutions in the future to make the whole process truly secure and decentralized, but it may take months or even longer. So currently only a very simple version has been implemented for quick access and low-cost maintenance. Of course, we understand your concerns about some of the issues mentioned, and we are willing to make some improvements.

Here are several improvements:

  1. Use multi-signature contract as the owner(2/3 or more).
  2. Deploy the proxy contract for the rate implementation contract, so that we can upgrade to a better solution in the future.
  3. Remove the setRate function.
  4. Estimate an accurate rateChangeLimit value and remove setRateChangeLimit function.
  5. More voters, 3/5 or more.

Btw, once there is a better solution in the future, such as integrating Chainlink, etc., we will switch to the safer and more general solution to bring you more secure and stable services.

Finally, thank you again for your thoughts and suggestions. We will do everything we can to optimize the solution and let you feel that it is feasible. Really hope the proposal can be approved. Thanks!

1 Like