We recommend all community members begin this series by reading part 1, submitted by community member @arosenthal4.
In part 1, we outlined why most protocols in DeFi 1.0 failed, and why the proposed upgrades to Radiant V2 will usher in a new, sustainable ecosystem that provides real cross-chain lending/borrowing utility to all Radiant ecosystem users.
We also introduced the concept of Dynamic Liquidity, which is a core part of the protocol design for V2.
Outlined below are several other critical new features proposed by tokenholders and advisors and several upgrades necessary for Radiant V2.
This RFP contains three categories:
Vesting + locking
Protocol fees
Migration plan
Part 3 will have details regarding Tokenomics Changes
Vesting & Locking
1. Exit Penalty: Static vs. Dynamic Penalty
V1 Design
50% exit penalty is applied to vesting Radiant, regardless of when a user exits the vest
Exit penalty RDNT tokens are distributed to lockers of RDNT
V2 Design Proposal
Implement a “Linear sliding scale of exit penalty” depending on when a user exits a vest
The penalty will start at 90% and, in a linear fashion, decline to 25% by the end of the vest
Rationale
Users who exit a vest on Day 1 vs. Day 27 are currently penalized in the same way, which doesn’t make sense
This dynamic penalty will reward long-term users and penalize short-term liquidity providers who are just looking to “farm & dump” tokens
Makes the decision less binary about whether to exit or vest
2. Exit Penalty - Token Distribution
V1 Design
Exit penalty tokens are distributed to RDNT lockers and are “fully liquid” in the market
V2 Design Proposal
Exit penalty tokens are split in the following ways:
90% of the “Exit Penalty tokens” will return to the RDNT DAO reserve to be used for future emissions and community initiatives
10% of tokens are burned from circulation
Rationale
This change has the net effect of significantly slowing the rate of inflation and also extending the runway of the RDNT DAO Reserve, given that emissions can be re-circulated at a later date from users who do not wait until the end of their vesting periods
This distribution helps solve one of the core issues, given the % of early exits observed, that the inflation into the market was too high relative to protocol fees generated
Burning a portion from circulation serves as a deflationary mechanism in what is otherwise an inflationary schedule, akin to an EIP-1559 for ETH
3. Expired Locks Treatment
V1 Design
Expired locks continued to earn protocol fees
V2 Design Proposal
Expired locks will be removed from the locking pool and no longer receive protocol fees
Rationale
This mechanism was a design flaw in V1; no reason expired locks should continue to receive protocol fees vs. freshly locked tokens. This flaw gave users a free option to leave locked tokens in the locking pool and earn protocol fees/exit penalties while having fully liquid tokens
The current mechanism will utilize “searcher” bots that look for expired locks and remove them from the pool upon a successful check and contract call
Now users will need to make a new decision whether to re-lock tokens upon expiration of the lock, as it should be designed
4. Vesting and Locking - 7-Day Cohorts
V1 Design
Vesters and lockers are grouped into “7-day cohorts,” which would make their vests/locks all unlock/vest at the same time, generally creating “FUD unlock events”
V2 Design
Removal of cohorts completely. Users will vest tokens, and locks will expire depending on their specific vesting schedules
Rationale
The cohort approach used by Geist Finance had some unintended adverse effects, including large amounts of tokens all unlocking simultaneously
This grouping also incentivizes users to wait for the last possible second to lock, as users locking on Day 1 vs. Day 6 would be bucketed into the same cohort, which is unfair to users who locked on Day 1
These “big unlocks” created unnecessary FUD and misaligned incentives; it’s much more practical for unlocks to occur at the exact time after locking and not batched
5. Vesting and Locking Period - Duration of Vest and Lock
V1 Design
Vesting and locking periods are 28 days
V2 Design Proposal
The vesting period extends to 90 days
We are currently exploring the technical feasibility of offering different locking lengths ranging from 1-12 months for different reward tiers. We’d love to see community discourse/ideas around this subject
Rationale
Feedback from many users and advisors is that the current protocol does not sufficiently reward long-term users or “long-termism”
Extending the vesting and locking period, coupled with the potential locking of LP tokens, will create more certainty about liquidity on multiple chains at any given time and reduce the risk of liquidity “bank-runs” of on-chain liquidity
Users who opt for more extended lock periods should be rewarded, but not all users may have that long-term profile and need to have “something for everyone”
6. Protocol Fees - % of Protocol Fees Given to Lockers
V1 Design
50% of protocol fees are streamed to RDNT lockers, while 50% of protocol fees are given as the base APY to lenders
25% of protocol fees allocated as the base APY to lenders
15% of Protocol Fees streamed to a Treasury OpEx wallet which will pay for salaries, exchange listings, and marketing partnerships
Rationale
Further incentivize lockers given the ask to lock LP tokens vs. single-sided locking in V1. This change will have the net effect of improving locking utility vs.the V1 state
Base lending fees will still be competitive with all major lending protocols
Creating a Treasury OpEx fund will make it possible to pay salaries, contractors, and future exchange listings. The initial team funded the entire project with no outside investment and over $1.5M spent. This will also reduce the pressure to use RDNT tokens to pay for these initiatives
7. Protocol Fees - Earned by Lockers and Vesting RDNT
V1 Design
Vesting RDNT and Locked RDNT earn protocol fees
V2 Design
Vesting RDNT will not earn protocol fees, only locked Dynamic Liquidity providers will earn protocol fees
Rationale
Vesting RDNT earning protocol fees has the effect of significantly diluting the locking pool vs. users that have committed via locking tokens
This redistribution of fees further incentivizes lockers as this will have the net effect of improving locking utility vs. V1 state and reducing dilution in the locking pool
This change rewards users who have provided utility to the protocol (via locking LP tokens) vs. vesting RDNT
V2 Migration Plan
Once auditors have given a timeline for completing the audit, Radiant will disable new locks from the UI so that all tokens can migrate to V2.
a. Around December 23rd, we will disable the ability for users to lock RDNT. However, pool2 rewards will still be active, and users can stake their liquid RDNT in the RDNT/ETH pool directly on the Radiant Staking page (currently 90%+ APR).
Existing and expired locks will continue to receive Protocol Fees and RDNT Exit Penalties
Emissions are reduced to 0 on Migration Day
Due to the significant upgrades made in Radiant V2, including migrating the current ERC-20 token to LayerZero OFT model (which will make cross-chain fee sharing much more seamless & allow ownership of bridging contracts) - users will need to migrate lending & borrowing positions manually to V2 on Arbitrum
Users will then be able to migrate their RDNT V1 tokens to the new V2 RDNT token contract seamlessly on the Radiant platform.
a. Instructional, step-by-step videos will help guide you through the process, and moderators/community members will be available 24/7 to assist with any migration questions.
After your farming positions and RDNT v1 tokens migrated to V2 contracts, voila! Migration is complete, and users can fully enjoy Radiant’s vision for a sustainable, cross-chain world.
Yep. Go for it. I will say that while breaking each of these 3 sections into their own proposals is better, I do feel that too much is being discussed in these proposals. Too many options is discouraging to those needing to be time efficient.
That being said, I really like this specific RFP section Part 2 of 3, as I see value being directed more to those providing actual utility.
Thanks @Czero for the feedback, when it comes to Snapshot, these will be broken up into several proposals as it would be hard to vote holistically. This is meant for discussion, which is why it is a longer document
This really makes so much sense. It would be great to have options like
3 months, 6 months, and 1 year locking periods so the people can be rewarded per their choice and ability to lock up their tokens…
Am I correct that locked RDNT being forcibly unlocked here is referring to locked LP as outlined in RFP-3?
I think forcibly removing locked LP would be a bad idea. I realise there are two steps to lock LP (LP, then lock) but we want to prevent removal of liquidity from the LP pool since that’s the point of moving to a LP-centric model. Plus this creates a burden for LP lockers since they now need to manage whether still locked plus pay gas to relock.
I think its better just to have the lock sit there, it could encourage some bizarre dynamics in the LP, particularly since it is low liquidity.
Also, regarding 2. Exit Penalties, I disagree with this aspect.
I think it is a bad idea to burn any tokens at this point because it doesn’t really gain anything over having them sit on the DAO Treasury. The DAO can issue vesting RDNT bonds for ETH at a later point, there’s no point burning.
I also think it is necessary to emit tokens into the locked LP because you still need to compensate for IL and imo 40% income in a 50-50 pool (or even an 80-20 pool) doesn’t do this.
I would propose changing this aspect - sending early exit penalty fees 50% to RDNT DAO Treasury and 50% to locked LP as emissions.
Users should not accrue fees when their tokens are not locked, as in, they are liquid to remove from the protocol. So when locks expire, they expire. This doesn’t remove the LP from the Dex, just removes it’s locked state from Radiant and no longer accruing fees.
Thanks for the comments @supernoveau, you’ve made your comment heard on a few threads about emitting RDNT to the locked LP and will take it under consideration.
The value of locked LP is not solely that it will give protocol fees, and allow for voting in Radiant Governance, but rather it will also unlock the ability to earn RDNT emissions. So the utility is more than simply the protocol fee portion. Thanks for the comment!
Regarding burning tokens, this is definitely something that should be under discussion, as there is a strong perspective that the marginal benefit of burning is outweighed by the ability to issue RDNT at a future date. That said, combating what will be pretty consistent inflation is a consideration as well
The tokens out there that burn also have a mint, and these tokens are created with an unspecified total supply.
However this token was created with a fixed supply. If you conceptualise the token as equity, to burn is effectively a slow motion restructure of total supply. It’s needlessly destroying equity.
Sending tokens to the Treasury is sufficient to restrict emissions and reduce float/sell pressure/inflation. It’s a buy back since it would require a vote to issue them later.
A good way to issue later to diversify the Treasury is to issue vested token bonds at discount to market for ETH. So you want to retain that optionality on the balance sheet.
Interesting approach, however there are some stuff that are sensible that needs to be solved.
Exit Penalty - Token Distribution
As @supernoveau stated. Instead of burning it or storing it on DAO, it would be a nice mechanism to offer bonds for RDNT/WETH LPs. This way we can get ETH or BNB and start making a real POL Mechanism, instead of bruning it. I dont see any value to burn it either.
6. Protocol Fees - % of Protocol Fees Given to Lockers
This one is sensitive, now a 15% will be distributed for the team to cover operational expenses. The thing is the team already has more than 20M RDNt tokens that were locked on v1 and were getting protocol fees for this purpose. So my question is, given the amount of tokens the team has:
What will happen to these tokens? will the 20% be swapped for WBNB or WSTETH to form LPs and lock it as dLP? If not, what is going to be done with these tokens? This is a huge risk for people because team could dump anytime. This one is important as I dont agree that teams will get the protocol fees from their tokens plus a 15%. It is way too much.
If the 15% goes on. Then I propose that half of teams tokens go directly to our Balancer Liquidity Pool. (2,5M RDNT should be used to collect WSTETH through bonding mechanism and form LPS). This would be useful as it would help distribution of the native token, hence improving decentralization and also would get a deeper liquidity.
I agree that additional 15% shouold not go to the team since they already have over 20M tokens in compenstation. If anything, distributions should always go to non-team stakers.
Regarding the 15% DAO OpEx and the high locked team share, I think this opens up a very important question about how the team plans the DAO “to lead post v2”.
Is the intention that the OpEx fund should go into a black box to pay the current team, or is the intention that the DAO will request proposals etc for future improvements, and the current team steps away?
One solution is to use the OpEx to fund the team going forward. In this case some share of the team RDNT should return to the DAO Treasury because the share to fund development is no longer necessary. The team loosely defined already has 27% of the distribution (20% for “team”, 7% for “advisors”).
Another solution could be to have the 15% go to the DAO Treasury instead of the OpEx and for there to be a formal request to budget/fund the OpEx each year out of Treasury. The solves the double dip question because it creates some capital control around a budget for the DAO, as opposed to funding a black box with no insight into how the funding is getting used.
It’s important to get the funding and shares balanced and sustainable otherwise smart people won’t get behind the DAO transition and contribute.
When lock expires, it should expires instead of the expire-but-not-really state. It’s confusing and your concern about sticky liquidity will be well addressed by the longer lock periods that will be available.
Perhaps this is an opportunity to revamp the overall tokenomics. Whatever the numbers might end up being, couple of salient thoughts from me relating to team and OpEx.
The protocol has to pay it’s own OpEx ASAP and not continue to rely on team’s investment (already 1.5m in…) or the team’s RDNT allocation & yields, which brings us to #2.
Since late 2021, the team has been risking its own $ to build a DAO-governed gem without dilution and influence from VCs. What is a fair return for the compelling vision, hard $ investment, energy, focus, and execution to bring the winning protocol to market? I don’t think the solution is “let’s perma-lock team allocation and use its rewards for OpEx”. It is completely unreasonable, however we got here.
We’ve gotta figure this out in a fair and equitable way forward for both the DAO’s success and what’s due to the founding team, recognizing past achievements and motivating future performance.
Hi @supernoveau, appreciate the thoughtful comments and contributions to the governance discussion!
The locked team share from genesis is a significant amount of RDNT that is effectively removed from the market forever- since the team agreed they would remain locked and never sold. Even with the ~500K earned from fees since launch, as stated above- over $1.5M has been spent- not including what WILL be spent.
Most projects allocate tokens to a treasury which are then sold to raise capital to pay for opex. Very few protocols have fees or any revenue.
It’s a bit of a different case when projects raise capital (from VCs), and they can use that capital to pay for expenses. It would be less relevant if Radiant had done so, and the above proposal of 15% of fees to be used for opex would not be needed. However, that comes with downsides of its own, needing to be beholden to VC interests, or deal with large VC token unlocks.
There is a middle ground with your suggestion regarding following up on the parameters of what type of expenses will need to be submitted to the DAO and can be discussed in a subsequent proposal.
Regarding that topic, I think the best way that we understand that 15% number for opex, is that team publishes a monthly balance sheet. Many protocols do so and it makes easier to understabd proposal with the numbers in hand.
I would treat the opex topic on a different RFP because the way it is now, lacks info.
PS: I do completely agree that operational expenses have to be covered and teams need to get investment back, but it has to be done in a proper way.
Hi Roger, so when you say that the initial team stake will continue to be permalocked, this means it will be allocated to arbitrum dLP once v2 comes into effect? I agree with Gerhard that given the large sums involved and currently opaque expenses, providing regular balance sheets would be a welcome contribution toward greater transparency with the community.
regarding exit penalty distribution, I think it would be a mistake to eliminate the distribution to stakers completely, we should be increasing incentives to stake not removing them. Burning also seems unnecessary, instead this portion should be locked as PoL and it would have much more benefit long term.
I disagree that expired locks should be removed from the locking pool, I feel that once you have completed the lock period then you are entitled to earn rewards while remaining liquid, and its nice being able to set and forget and continue earning rewards indefinitely, especially with such a long lock period, rather than having to constantly check and relock in order to continue earning rewards.
This being said, the proposals are interesting and I applaud the teams efforts to strengthen the DAO and take community ideas and concerns into account.
I noticed that I made a mistake (Sorry, not native english speaker lol).
What I was referring to, was not a balance sheet, but a income statement (Not that balance sheet is unnecessary but for OpEx calculations is not neccessary I think).
This one is important so we could see real how much Opex do we need to cover it all.
Also if there are some new partnerships in sight, new features that gets voted on DAO (Leveraged Farming, New chain launches, etc). This one should be discussed after we have a 2023 Roadmap, because right now it is not clear. In the mean time we could send fees to make this treasury grow.
For this purpose, we should be implementing CapEx to fund all these initiatives. I think @supernoveau stated something like this. The CapEx Funds should be kept in a treasury (A multi sig wallet maybe) and the custody of this treasury should be given to the community based on a voting pol (3-5 Multisig Wallet for example, 5 member council elected that can authorize transactions that gets approved on DAO).
For me this is the proper way that protocol management should work through a DAO.
