RFP-8: Extending the Emissions Runway - Protocol Mechanics

Abstract

RFP-8 proposes changes to tokenomics in order to extend the emissions runway and handle the allocation of RDNT emissions across multiple chains.

Motivation

Two years--the original runway for RDNT lender and borrower emissions--does not provide Radiant Capital with sufficient time to achieve its cross-chain vision. When looking at some of the successful DeFi protocols that achieved product market fit (Uniswap, Aave, Compound), these protocols took years to achieve the current scale. It’s important for Radiant to have sufficient incentives in its reserves to use for a significantly longer timeframe.

Key Terms

• Runway: the period of time over which emissions will last.
• Longtermism: an ethical stance that gives priority to improving the long-term future of a system.

Specifications

As discussed in previous RFPs, with respect to extending the runway of Lending/Borrowing emissions, the following protocol changes are being proposed for v2:

Extending Emissions Runway

Radiant v1 Design:

Lending and Borrowing emissions would last 24 months, concluding in July 2024.

Proposed v2 Design:

Scheduled emissions to Lenders and Borrowers will last for a total of 60 months since inception, extending the scheduled emissions schedule to July 2027 (5 years total).

This is described as a minimum of 5 years because there will also be the Radiant DAO Reserve, which is the recipient of exit penalty RDNT (per RFP-5) and the reduction in emissions executed in RFP-2. This proposal is recommending expanding the initial scope of the RDNT DAO Reserve (which was originally only to be used for lenders/borrowers) in that it should be used more at the discretion of the Radiant DAO to do things such as:

• Extend emissions runway beyond the scheduled 5 years
• “Top up” chains that have successful Radiant deployments with additional RDNT in order to incentivize additional user onboarding
• Additional initiatives to be voted on by the community TBD such as strategic partnerships and other business development/DAO swaps

Extending the runway, combined with RFP-5, has the net effect of reducing net inflation per month to more sustainable levels, relative to the front-loaded emissions schedule originally designed in v1.

Allocation of RDNT Emissions by Chain

Radiant v1 Design:

All emissions were directed to RDNT’s first deployment on Arbitrum.

Proposed v2 Design:

It is difficult to know how many users and how much demand there will be across Radiant deployments as it moves cross-chain. While the second deployment will be on BNB Chain, the vision has always been to deploy Radiant Protocol across all major EVM chains.

As a result, it’s difficult to make a completely fixed emissions schedule for 5 years, and not be able to respond to the market and where users are going. The following idea has been proposed by a community member as an initial way to split emissions by chain, inspired by the LayerZero team’s cross-chain emissions allocations:

• Total Max Emissions represent the total number of emissions that can be allocated to all Radiant deployments combined in a given month; Total Max Emissions will operate on the proposed schedule ending in July 2027.

• At the end of each month, the DAO will take a retrospective view of closing TVL on each chain, and allocate emissions accordingly for the subsequent month.

• For example, at the end of March, If Arbitrum has 30% of Radiant TVL, BNB Chain 30% of TVL, and Eth Mainnet 20%, emissions should be allocated 30%/30%/20% for the subsequent month.

• At launch, 100% of emissions will be directed to Arbitrum Radiant Markets; upon launch of BNB Chain, it is proposed that 50% of emissions be directed to BNB Chain for Month 1.

This is a simplistic approach, and more sophisticated ideas (e.g., gauges per chain, per market, allocations based on protocol fees generated) should continue to be discussed and brought to subsequent proposals. This portion of the RFP can be subject to update upon subsequent proposals generated by the DAO stakeholders. That said, this is a predictable and formulaic approach that can give transparency in the short term.

Breakdown of Token Distribution

Radiant v1 Design

• Lenders and Borrowers: 50%
• “Pool2”: 20%
• Team: 20%
• Advisors & Ecosystem: 7%
• DEX and CEX Liquidity:3%

Radiant v2 Design

• Lenders and Borrowers, Community Allocation: 70%
• Team: 20%
• Advisors & Ecosystem: 7%
• DEX and CEX Liquidity: 3%
• RDNT DAO Reserve: No formal allocation

This is a re-allocation of emissions from “Pool2” to Lenders and Borrowers on the Radiant Platform. Given Radiant’s cross-chain ambitions, and the shift from single-sided lock to LP locking, this allows Radiant to more appropriately plan for the long-term future and allows for more chain deployments.

Remaining Token Supply

Radiant v1 Design

Tokens were minted as they were emitted using MasterChef contracts.

Proposed v2 Design

Follow LayerZero’s STG token design where the remaining tokens (1b total supply) are minted at “genesis” of v2, but remain locked and will follow the vesting schedule laid out above for Lenders and Borrowers.

This has no impact on inflation or market cap, but solves one of the pain points of v1: Radiant will need to be flexible in changing emissions rates per chain as the protocol matures. With the v1 contract structure, making these kinds of changes as the number of chains expands would be impossible.

This is in line with STG, which needs to adjust emissions rates by chain depending on TVL needs.

Steps to Implement

• Creation of Emissions Reserve MultiSigs for each chain where Radiant is deployed, which allows for more flexibility in adjusting emissions rates as directed by the Radiant DAO in the future.
• Adjust lending/borrowing vesting schedule from ending in July 2024 to July 2027.
• Adjust Pool2 emissions rate down to 0 RDNTPerSecond as per RFP-3.

Overall Cost/Impact

Minimal.

Timeline

Implementation would go into effect upon the launch of v2, and would deploy on all subsequent Radiant chains (current & future).

Voting

• In Favor: Supportive of the RFP-8 v2 tokenomics redesign proposals
• Against: Against implementation of the RFP-8 v2 design proposals
• Abstain: Undecided, but contributing to quorum