We propose two methods of integration, each used for different purposes. If you think of an integration method that is more ideal, we are open to accepting it.
Partners deploy the Wrapper contract for each vault utilized.
- User deposits into partner Wrapper
- Wrapper deposits into Yearn Vault
- Vault issues vault tokens to Wrapper
- Wrapper issues wrapper tokens to User
See the template available on Github with tests
- Contributed TVLs are easily tracked with precision
- Vault tokens are not fungible with other partner tokens or with Yearn's vanilla vault tokens
- Each vault requires its own wrapper
- Solution and testing are comparatively complex
Partners deploy a routing contract for each vault utilized.
- User deposits to the routing contract
- Routing contract routes the deposit into the Yearn Vault
- Vault issues vault tokens to the User
The v2 vault's deposit() function has a recipient parameter that defaults to msg.sender, but can also take any other address, effectively allowing a contract or EOA to delegate a deposit on behalf of another intended recipient. You can see the function #24 here.
If funds are deposit using this delegated method from an address already known to Yearn, the TVL can be attributed to the address and profit will be shared based on that data.
A single routing contract can handle multiple vaults, but can also be deployed on a per vault basis. The design is very flexible as long as a defined set of addresses are provided to keep track of the partner's contributed TVL.
Users will need to keep the issued vault token in the recipient address in order for TVL to be tracked. Tokens tend to stay in the end user's wallet, but this is an obvious tradeoff vs using the partner Wrapper.
- User gets credited regular vanilla yearn vault tokens for a better user experience
- Loss of TVL attributed if users transfer the vault tokens
- Simpler implementation and testing