RFP-6: v2 Vesting and Locking - Protocol Mechanics

Abstract

RFP-6 proposes changes to the vesting and locking mechanisms.

Motivation

Fixed unlock periods create unnecessary FUD. Grouping unlock events into universal weekly epochs creates weird game theory dynamics which aren’t particularly helpful or useful.

As liquid tokens, expired locks should not receive the same treatment as locked RDNT tokens.

It is imperative that Radiant v2 rewards and encourages long-term support of the Radiant protocol in alignment with the Radiant DAO core value of collective benefit.

Key Terms

• Epoch: a period of time used to mark specific events in the life of a blockchain network.
• Longtermism: an ethical stance which gives priority to improving the long-term future of a system.

Specifications

The following protocol changes are being proposed for v2:

Vesting & Locking: Expired Locks Treatment (1 of 3)

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
• The proposed mechanism will utilize “searcher” bots that look for expired locks and remove them from the pool upon a successful check and contract call

Rationale

The original v1 locking mechanism is flawed: there is no reason to continue earning locking fees on a token if the lock period has expired. This gives users free optionality by allowing them to keep their tokens in the lock pool and continuing to earn exit penalties and protocol fees—all while having access to their full balance at any time, even after lock expiry.

Users will now have to decide whether or not to re-lock their tokens upon expiration of the lock, as it should be designed.

Vesting and Locking: Removal of 7-Day Epochs (2 of 3)

v1 Design

• Vesting and locking periods are grouped into 7-day epochs which release all vests & locks at the same time. This has the adverse effect of creating a weekly cycle of “FUD unlock events”.

v2 Design Proposal

• Removal of the 7-day lock cycle. Tokens will vest based on a user’s individual vesting schedule, and locks will expire independently.

Rationale

The "epoch" approach used by Geist Finance produced unintended adverse effects, including large amounts of tokens all unlocking simultaneously.

This grouping also incentivizes users to wait until the last possible second to lock their tokens, as locking them on day 1 vs. day 6 would bucket all of these into the same epoch—which is unfair to those who locked up earlier.

These en masse unlocks created unnecessary FUD, and the batched nature of these unlocks resulted in misaligned incentives. It is more practical to distribute token unlocks over time in line with each individual's vesting schedule than in batches on a weekly basis.

Vesting and Locking: Duration of Vest and Lock (3 of 3)

V1 Design

• Vesting and locking periods are 28 days

V2 Design Proposal

• The vesting period for earned RDNT through emissions extends to 90 days.
• Protocol is currently exploring the technical feasibility of offering different locking lengths ranging from 1-12 months for different reward tiers. If feasible, a tiered structure will be implemented in v2, subject to community vote on weightings in a future RFP.

Rationale

Many users and advisors have noted that the protocol currently does not sufficiently reward longtermism vs. speculative short-term actions.

This extension of the vesting and locking period, coupled with the potential locking of LP tokens on each chain, will create more certainty about liquidity at any given time—and reduce potential risk for investors during "black swan" bank run scenarios.

The protocol should offer greater compensation to investors who choose extended lock periods, while not overlooking those who prefer shorter profiles. To be successful, the protocol must appeal to as broad a range of participants as possible.

Steps to Implement

• Smart contract and front end logic have been completed in a test environment
• Upon completion of beta testing, code will go to PeckShield for review
• Upon completion of the audit, implementation would take place immediately upon launch of Radiant v2

Overall Cost/Impact

Likely some maintenance dev cost, no additional structured costs beyond existing time/resources spent in development.

Timeline

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

Summary of RFP-6 v2 Design Proposals

1. Remove expired locks from protocol fee streaming
2. Removal of universal seven-day unlock epochs for locking/vesting
3. Change vesting and lock durations; implement variable lock lengths tailored to the individual user

Voting

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