Skip to main content

Voting & Reward Manager

It's crucial to remember that when a user deposits miAsset into a dApp contract:

  • The contract gains voting power.
  • Extra rewards from EOL accumulate in the contract, which should be claimed by the contract.

Typically, a dApp consists of multiple contracts. You may want to aggregate the voting power and extra rewards of these contracts into a single account for streamlined management and operations.

// See full codes in https://github.com/mitosis-org/protocol-public

contract YourContract {
	IMitosis internal constant mitosis = IMitosis(0x......);

	constructor(address manager) {
		mitosis.setDefaultDelegate(manager);
		mitosis.setDelegationManager(manager);
	}
}

Let's start with the conclusion: All you need to do is add those two lines to the constructors of all contracts in your dApp. This will ensure that everything works as intended. However, be careful not to set an incorrect manager address.

Let's dive into how this magic works internally.
There are three key features powering this functionality:

  • Delegation
  • Default Delegate
  • Delegation Manager

Delegation​

The "delegation" feature allows you to designate a manager who receives all voting power and EOL extra rewards.
Internally, voting power calculation and reward distribution rely on a common feature: miAssets tracking TWAB (Time-Weighted Average Balance).
miAssets perform extra operations to track TWAB whenever the ERC20 transfer() function is called, recording all balance changes.
This implementation also supports TWAB delegation. By delegating your TWAB to another account, you effectively transfer your future voting power and extra rewards to that account.

// See full codes in https://github.com/mitosis-org/protocol-public

interface IEOLVault {
  function delegates(address account) external view returns (address delegatee);
  
  function delegate(address delegatee) external;
}

Note that:

  • Voting power calculation and reward distribution are interlinked. You can't delegate one without the other. When you delegate, it applies to both aspects.
  • Delegation only affects future voting power and extra rewards. It doesn't retroactively impact past allocations.

Default Delegate​

Your contracts should delegate TWAB for all types of miAssets, including those added in the future. To simplify this process, we offer the "default delegate" feature.

Contracts can set a default delegate for all types of miAssets. When miAssets are transferred, it checks if it's the first time the recipient (to) address receives the miAsset. If so, it sets the delegate of the recipient to the default delegate, if one has been set. Note that the default delegate isn't applied if your contract already held miAssets before setting the default delegate. Therefore, the best practice is to set the default delegate properly in your contract's constructor.

Delegation Manager​

To streamline the process of changing delegates for your contracts, we offer the "delegation manager" feature instead of having each contract call delegate() and setDefaultDelegate().

With this feature, contracts can designate a delegation manager that has the authority to change delegates for all the contracts it manages.

// See full codes in https://github.com/mitosis-org/protocol-public

interface IEOLVault {
	// The delegation manager can delegate TWAB of miAssets instead of the account.
  function delegateByManager(address account, address delegatee) external;
}

What's Next After Setting Up Your Voting & Reward Manager?​

After consolidating all voting power and extra rewards under one manager by adding two lines to the constructors of all contracts in your dApp, the next step is to explore ways to utilize this consolidated voting power and extra rewards.

Here are a few hypothetical examples of what could be done, purely for illustrative purposes:

  • Distributing extra rewards to users through a raffle system
  • Buying back dApp tokens by selling the rewards in the market
  • Selling voting power to interested parties

The actual implementation should align with your dApp's specific goals and ecosystem considerations.

If you're unsure how to proceed, consider redistributing voting power and extra rewards to your users in proportion to their liquidity in your dApp. This straightforward approach ensures fair distribution based on the amount of liquidity each user has provided to your dApp.

For more details on redistribution, check out Redistribution of Voting Power & Extra Rewards.