LockedRevenueDistributionToken (LRDT) extends Maple Lab's RevenueDistributionToken (RDT) to add time-based and fee-based withdrawal mechanisms. This implements the EIP-4626 Tokenized Vault Standard for composability with vault wrappers and aggregators.
GovernanceLockedRevenueDistributionToken (GLRDT) extends LockedRevenueDistributionToken to add Compound governance compatibility, using OpenZeppelin's ERC20Votes.
- ERC20 implements the ERC-20 token standard and transfers.
- RevenueDistributionToken implements reward distributions and the ERC-4626 vault standard.
- LockedRevenueDistributionToken implements time-restricted and fee-restricted withdrawals.
- GovernanceLockedRevenueDistributionToken implements Compound-compatible governance voting.
- LockedRevenueDistributionToken implements time-restricted and fee-restricted withdrawals.
- RevenueDistributionToken implements reward distributions and the ERC-4626 vault standard.
It is possible to use LRDT without the governance properties of GLRDT by inheriting or deploying it directly.
GLRDT extends LRDT and adds Compound governance via ERC20Votes and ERC20VotesComp. This exactly matches Compound's interface, supporting a maximum supply of (2^96 - 1) type(uint96).max on deposited assets.
To account for rewards and allow for multi-chain voting the governance voting power is based on the amount of assets held in the vault rather than the number of shares, this means that rewards earned also apply to voting power. Checkpoints are managed by capturing both the amount of shares and the amount of assets (votes) upon each checkpoint and therefore voting power can be moved and redelegated whenever the share token is minted, burned, or transferred since the amount of underlying assets will be calculated for the sum of delegated shares.
For multi-chain setups it is important to note that the vault share token cannot be bridged since underlying balances and conversion rate will not be equivalent, but since governance voting power is based on the underlying asset balance it holds that this can enable multi-chain governance strategies when the underlying asset is also bridged 1:1 between chains.
LRDT has been designed to be a foundation for governance tokens, which often requires time-locked commitments for the alignment of participants. Once a staker deposits into the vault, there are two possible withdrawal mechanisms:
- Time-based 'Standard' withdrawals, not subject to a fee.
- Fee-based 'Instant' withdrawals, available instantly.
This results in a system wherein participants must be subject to withdrawal conditions thereby demonstrating a longer term horizon and commitment to the protocol.
To start a time-based 'standard' withdrawal, a staker must first create a withdrawal request by calling createWithdrawalRequest with the number of shares that they wish to redeem in future. This transaction will calculate the amount of underlying assets (deposited + rewarded) available to the staker at the point when the transaction is executed along with an unlockedAt timestamp for when the withdrawal is executable. To execute the withdrawal the staker can call executeWithdrawalRequest to burn their vault shares in return for the assets recorded in the withdrawal request.
To prevent stakers from creating multiple withdrawal requests using the same vault share tokens, transfers are restricted for stakers with an active withdrawal request. To first be eligible for transfer the withdrawal request must be removed using cancelWithdrawalRequest.
No fee on the returned assets is applied when using a time-based withdrawal.
Also sometimes known as a 'rage quit', this applies a fee penalty to stakers that wish to have instant access to their underlying assets. For composability with the ERC4626 standard this fee penalty is applied by default to the previewRedeem, redeem, previewWithdraw, and withdraw functions and would be applied when called by any vault wrappers. The fee can be set as a percentage using the owner setInstantWithdrawalFee function.
It is possible to exempt certain vault share token owners from the instant withdrawal fee and this may be used to exempt a particular third-party vault or future migration contract, an example of this would be to exempt a lending vault from the fee, so that liquidations can take place without subjecting the original holder to an additional fee. Exemption addresses can only be set by the contract owner.
The ERC-4626 standard does not offer functions for previewing a redeem or withdraw for a particular account, as is the case when an exemption has been set. Two new functions, previewRedeem(uint256 shares_, address owner_) and function previewWithdraw(uint256 assets_, address owner_) have been added to facilitate account-specific withdrawal estimations.
Reward distribution can be made fully autonomous using keepers by calling the public updateVestingSchedule function. To prevent any abuse this uses a fixed vesting period and cannot be called again until the last day of the vesting cycle and without this protection then it would be possible to frequently call the updateVestingSchedule function to extend the reward distribution time far beyond the fixed period. It is important to note that the owner-protected updateVestingSchedule from RDT is still present and calling this with a vesting period longer than defined in the public function will prevent the public function being called until the last day of the vesting period.
git clone [email protected]:GETProtocolDAO/locked-revenue-distribution-token.git
cd locked-revenue-distribution-token
forge install
forge test
This project was built using Foundry.
Slither and Mythril have been configured to be ran with make using their official Docker containers. These can be ran with make slither and make myth.
The GET Protocol DAO exists to support the NFT ticketing products, blockchain operations, and the broader GET Protocol ecosystem through marketing, outreach, and software development. GET Protocol exists to bring transparency, honesty, and the power of Web3 to event ticketing. For further technical documentation on protocol specification and usage, please see the Documentation Hub