EOL Delegate

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.

// You can check an example about it in https://github.com/mitosis-org/uniswap-v2-core

contract YourContract {
	constructor(IMitosis mitosis, address eolDelegate) {
		mitosis.setDefaultDelegatee(address(this), eolDelegate);
		mitosis.setDelegationManager(address(this), eolDelegate);
	}
}

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 eol delegate address.

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

• Delegation
• Default Delegatee
• Delegation Manager

Delegation

The "delegation" feature allows you to designate a delegate 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 code: https://github.com/mitosis-org/protocol-public

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

  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 does not retroactively impact past allocations.

Default Delegatee

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

Contracts can set a default delegatee 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 delegatee, if one has been set. Note that the default delegatee isn't applied if your contract already held miAssets before setting the default delegatee. Therefore, the best practice is to set the default delegatee 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 code: 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 EOL Delegate?

After consolidating all voting power and extra rewards under one delegate 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.