[BIP-472] Enable RDNT/WETH 80/20 Gauge [Ethereum]

Governance
1

PR with Payload

Enable RDNT/WETH 80/20 Gauge [Ethereum]

Summary

Proposal to add gauge support for the newly created Radiant 80/20 RDNT/WETH on Ethereum Mainnet.

After successful launches on Arbitrum and BNB Chain, Radiant has expanded to Ethereum Mainnet. In April 2023, the Balancer DAO granted a gauge to Radiant’s RDNT/WETH 80/20 pool on Arbitrum, which was instrumental in the pool’s exemplary performance and being the top Balancer pool on Arbitrum. The results of this pool on Arbitrum have exceeded all expectations and can serve as a data point to project similar success on mainnet.

References/Useful links

Protocol Description

Radiant aims to be the first omnichain money market where users can deposit any major asset on any major chain and borrow various supported assets across multiple chains.

The Radiant DAO’s primary goal is to consolidate the ~$20 billion of fragmented liquidity (lending TVL) dispersed across the top ten alternative layers (source: DefiLlama).

Lenders who provide liquidity to Radiant are interacting and providing utility to the platform. In addition, lenders can capture the added value from the communities’ engagement through the native token $RDNT.

Borrowers can withdraw against collateralized assets to obtain liquidity (working capital) without selling their assets and closing their positions.

Motivation

The Radiant DAO aims to be the most fee-earning & omnichain protocol in crypto whilst ushering in the next 100m of new DeFi users. Adding this gauge to the robust Dynamic liquidity vault represents another step in strengthening the relationship between the two protocols. In addition, this pool is intended to be the primary source of liquidity on Ethereum.

Details

  1. Governance: The Radiant DAO governance model can be found here: Proposal Process.

  2. Oracles: Radiant price feeds are secured by Chainlink oracles.

  3. Omnichain: RDNT, an OFT-20, is Radiant’s native utility token. Layer Zero Labs’ omnichain fungible token (OFT) interoperability solution enables native, cross-chain token transfers. Radiant’s dAPP provides users with a borrow & bridge function via Stargate’s stargate stable router interface.

  4. Audits: Radiant conducted multiple top-to-bottom v2 audits with Peckshield, Zokyo, BlockSec, and OpenZepplin with zero unresolved critical or high issues. Members of the white-hacking community and participants of the ongoing ImmuneFi bounty program are also leveraged to buttress potential vulnerabilities.

  5. Centralization vectors:

    1. The Radiant DAO asserts that the network’s governance, development, or usage is not centralized and progressively gets more decentralized as the number of RDNT token holders grows. Together with Fenwick, Radiant set up the Radiant DAO governance portal (dao.radiant.capital) and ratified the first two governance proposals, RFP-1, and RFP-2, on which RDNT token holders voted.

    2. The Radiant DAO Constitution includes a very clear process for the community to discuss, propose, and vote on new measures, regardless of whether the team ceases to exist. This includes technical changes, improvements, bug fixes, protocol changes (emissions, allocation points), or other protocol improvements. The establishment of the DAO formalizes this, as well as voting power through RDNT liquidity tokens.

    3. The smart contracts are verified, and any community member may propose changes or improvements. Several community members who are not affiliated with the project at launch have been brought on as “core contributors” in developing smart contract improvements and helping manage portions of the Radiant community.

    4. Because Radiant was built on a similar framework to Aave and Geist, many of the core contracts are upgradable by the owner. To mitigate security concerns and foster transparency, all Radiant smart contracts are placed behind a timelock, with a two-day delay for any action. The Radiant team has no intentions to ever push upgrades to these contracts except to address a critical vulnerability. We will prominently inform the community before any admin-related actions involving the timelock and encourage community members to monitor inbound transactions to the timelock address. The Radiant team will always announce all admin-related actions before queuing them in the timelock

    5. Over 215k unique wallets have interacted with the protocol. Administrative functions within the smart contracts are under timelock and Gnosis multisig. The committee that manages that multisig was ratified as part of Radiant DAO’s first proposal, RFP-1.

  6. Market History: Radiant fair launched on 7/24/2022 and was self-funded with no VCs. Radiant v1 became the top lending protocol on Arbitrum with 148.45m TVL before the transitioning to v2 in March 2023.

Achievements by the 1st Year Anniversary 7/24/23.

  • Arbitrum’s **top lending protocol by TVL ($204M) **and daily active users (DAUs).

  • BNB Chain’s #2 in lending TVL ($93M) and leader in DAUs.

  • Generated $16M in protocol fees, fully distributed as real yield.

  • Ranked #2 in lending protocol revenue across ALL DeFi, with only two chain deployments (Arbitrum & BNB chain)

  • 154K token holders and 217K protocol users.

  • Locked $76M in dLP—$55M on Arbitrum and the rest on BNB Chain—with a total market size exceeding $500M.

  • In a 180-day earnings comparison, $RDNT led with $3.8M, edging out $AAVE ($3.6M) and $XVS ($1.6M).


    While working towards its goal of seamless omnichain lending and delivering the achievements listed above, Radiant has delivered on its aim for cost efficiency with a competitive price-to-fee (P/F) ratio of 23.7x—far outpacing Aave’s 69.9x and Venus’ 38.1x.

  1. Value: This pool is intended to be the primary source of liquidity for Radiant on Ethereum. In addition, the Radiant DAO sees the value of this gauge in alignment with other protocols in the ecosystem and sees potential and value in doing so with Balancer.

Specifications

Gauge Weight Cap

Based on Radiant’s market cap, weighting and fee contributions, it sits just on the border of the Capped Gauge Framework 3, sitting currently slightly over the limit allowing for an uncapped gauge based on high trading fees. The current intention of this pool is to allow collected fees to be paid back into the gauge via Core Pool Bribes.

A Gauge capped at 10% provides more than enough room for these activities for the foreseeable future. In order to alleviate any concerns around RDNT being used in an “capture most of the pool and over-vote for it” scheme, a voluntary 10% cap has been placed on the gauge. Radiant may return to governance at a later date to request an increase as the need arises and the pool has more history to be used to evaluate it against BIP-57.

Gauge Type

Note that this gauge is a traditional gauge, not a single recipient gauge used as part of the ve80/20 program. As a result BAL incentives will be paid out to addresses depositing tokens in the Balancer Gauge. Not to a single smart contract that redirects these tokens to lockers.

Core Pools Designation:

While this pool contains no boosted tokens, a 0.5% fee has been set on the pool with an intention to participate in the BIP-19 4 boosted pool program. As with RBN/USDC gauge, It is therefore requested that 100% of the fees earned by this pool and not paid to the DAO are used to pay bribes on the pool. It is further requested that these fees are used bribe the RDNT/WETH pool directly, instead of participating in the distribution of bribes by TVL as following the protocol for mainnet instead of for side-chains specified in BIP-19. Handling of this pool should change in line with changes to BIP-19.

Details of Gauge to be whitelisted

  1. Gauge address: 0xF22BbdAd6B3Dd9314BdF97724DF32b09Ff95C216
  2. Pool address: 0xcf7b51ce5755513d4be016b0e28d6edeffa1d52a000200000000000000000617

The specific actions of authorizing the DAO multisig, adding the gauge, and removing the authorization using the gauge address above are included in the linked payload.

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):0xF22BbdAd6B3Dd9314BdF97724DF32b09Ff95C216
gaugeType(string): Ethereum

Additionally, this pool is requesting core pool status as per BIP-457

2 Likes
2

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