Reward Distributor
A flexible and truly decentralized reward distribution model
Last updated
A flexible and truly decentralized reward distribution model
Last updated
As publicly well known, every execution on EVM requires gas fees to paid. Thus, an automated reward distribution is not efficient and has to be done periodically. Additionally, calculation and distribution has to be configurable to allow new projects to build on Jellyverse and verifiable. Reward distribution is one of the key elements of the Jellyverse ecosystem and consists out of two contracts:
minter.sol
rewarddistributor.sol
These two contracts work together seamlessly to facilitate a straightforward weekly reward distribution process. In simple terms, any user can perform an off-chain calculation using a provided (or optional) snapshot to determine which addresses are eligible to receive rewards. This approach ensures flexibility, complete decentralization, and efficiency in the distribution process.
This smart contract will inherit an ownable smart contract so it can be called by the Governance to update critical parameters.
To optimize gas efficiency, the system adheres to a weekly cycle. Within this cycle, a snapshot is generated, rewards are computed, and subsequently made available for users to claim. Users can claim tokens for one snapshot at a time, but if they haven't claimed for an extended period, multiple claims are feasible. To facilitate this process, a multicall mechanism will be .
From a technical standpoint, it's possible to select any snapshot and timeframe for reward distribution. However, in practice, the minting of JLY tokens is specified in the JLY contract and serves as a constraint on the reward distribution contract. Additionally, the community may reach a consensus on an unofficial, easily verifiable occurring every X blocks.
The system may utilize the Blockscout API or similar services for snapshots; however, it is essential to enhance security by implementing an on-chain snapshot, possibly using cryo. This on-chain snapshot should precisely match the snapshot obtained from the Blockscout API.
Due to complexity related to voting power, which depends on lock-up time, it's crucial to perform a snapshot of the entire relevant state. Subsequently, Jellyverse outsources the off-chain script and constructs the Merkle-Patricia Tree from the given leaves. This enables anyone to verify that the same tree is generated using the same state (leaves).
For each snapshot, a JSON file is generated and named "<blockNumber>_snapshot.json." An off-chain TypeScript script will utilize the OpenZeppelin merkle-tree library to create a Merkle tree for that snapshot. Calculations for token claims for Liquidity Providers or Chest NFT holders should be based on a percentage of the weekly emission of JLY tokens. To optimize gas usage, these calculations are performed off-chain. If TypeScript is deemed unsuitable, the script can be written in Python, Rust, Go, or any suitable language. Each leaf of the tree should include the index in the tree, the beneficiary's address, and the number of JLY tokens owed to that address in that snapshot (scaled to 18 decimals).
The Merkle Tree will be uploaded to both IPFS and a GitHub repository. GitHub serves as a centralized location to store all snapshots and make access convenient. In addition its stored on IPFS to ensure decentralization.
To manage claimed tokens and prevent double claiming, a bitmap known as "Claimed" is utilized. It is intended to implement this using OpenZeppelin's BitMaps contract for efficiency and reliability.
