MIP#: 44 Title: Reward Join Adapter (`RewardJoin`) Author(s): Alexis Contributors: n/a Type: Technical Status: withdrawn Date Proposed: 2021-01-24 Date Ratified: <yyyy-mm-dd> Dependencies: n/a Replaces: n/a License: AGPL3+
- The proposed RewardJoin implementation
MIP44 proposes a generic vault solution for all tokens with reward.
MIP44 is a generic vault solution which can by applied to any tokens with reward.
At the difference of cropJoin, the interface is generic and work exactly as a normal join.
It is less specific but it works with any vault independently of the reward.
Therefore, It can be applied to any uniswap pair as we don’t know which one will be the next rewarded pool.
If we want to use the current cropJoin implementation as far as I am aware of, Maker will be forced to deploy a specific vault everytime the uniswap vote a new rewarded pool and stop it when the reward end.
I am not too sure how to formalize it but I believe this is not a proper MIP but a complement to the uniswap vault creation.
###How does it work?
Instead of redistributing UNI to share holder (Which is the difficult part that cropJoin deal with) we trade in UNI with fees.
The contract allows the withdrawal of the bonus token, which is sent to a delegator.
Governance can turn the fees to 0% and sell UNI instead.
As said this solution is probably less specific than cropJoin but allow more flexibility.
The delegator can be built after as the UNI will be inside the contract.
MIP44c2: Reward Join:
MIP44c2: Parameter: list of parameter for the contract
MIP44c2: Funtions: list of function accessible from the contract
MIP44c2: join(): list of function accessible from the contract
MIP44c2: exit(): list of function accessible from the contract
MIP44c2: harvest(): list of function accessible from the contract
MIP44c1: Proposed code: contains snippet of proposed implementation.
MIP44c2: Test cases: lists existing test cases, including integration tests
MIP44c3: Security considerations: comments on the security implications.
MIP44c6: Licensing: states the license under which the proposal and code are distributed.
Currently we use a normal join, for all uniswap tokens. for example UNI-V2-ETH-USDT
-Can use existing MCD collateral type adapter? Partially, the standard GemJoin adapter 1 works if you ignore rewards. A custom gem join adapter is required to distribute UNI rewards.
Here is the issue if we don’t allow the join contract to withdraw UNI right now, all uni token will be lost for ever.
While it is probably less interesting for user than deploying a cropJoin contract, it allows a rapid and effort-less management for makerdao.
My understanding is that both contracts have a different value while the normal uniswap vault can stay up with this join, a new cropjoin for the same pair can be deployed.
The join is 100% compatible with the existing system and it is also as gas efficient for the holder as a normal join.
It can be deploying before the UNI reward is voted, doesn’t need any switch from the user.
the Join and the exit are exactly the same as a normal join
join(address guy, uint256 wad)
exit(address guy, uint256 wad)
it is exactly the normal join
it is exactly the normal exit
- harvest is behind an auth
- harvest can be called from an authenticated contract
- harvest will stop if no delegator contrat (0 address) is set up.
- harvest will move the UNI/Bonus token to delegator contract which will sell/store/whatever we want to do with the token.
The join is a sensible part of maker as it hold the token, however the harvest is behind an auth and manipulate only UNI.
The risky part will be when we deploy the contract that call harvest and the delegator.