Discuss here the typical flows for someone using Tribute
Let’s analyze this systematically by breaking down the actions users can take that would affect hat proportions and categorize the types of post-action effects that they might intend to achieve.
Actions that users can take that affect hat recipients and proportions:
- Add principal by minting rTokens from underlying asset
- Withdraw principal by redeeming rTokens to underlying asset
- Call payInterest to distribute accrued interest to him/herself (also could be called by 3rd party)
- Change proportions among same recipients in current hat
- Eliminate one or more recipients from current hat
- Add new recipient and allocate a proportion of the new hat
Users will likely have different intentions for different recipient classes as to what they intend to happen after one of the hat-altering events above. These different intentions can be categorized into the following buckets:
- Maintain a recipient’s proportion at the same pre-event percentage of total tribute (constant tithing of a specified %)
- Maintain a recipient’s quantity of allocated tribute, denominated in the underlying asset (fixed asset allocation amount)
- Maintain a recipient’s minimum periodic payment denominated in the underlying asset, regardless of the variable interest rate, requiring a buffer of allocated tribute to account for expected interest rate volatility (annuity)
- Allow recipient’s proportion and/or allocated tribute to decrease or increase to account for the new hat-altering event
Users may also wish to signal prioritization for certain recipients over others (e.g., maintain charity donation annuity over entertainment streaming subscriptions), or may wish to lock certain conditions in place in the event of interest rate decline.
I’ll share some expected user patterns in a follow up post, but thought it made sense to iterate and consider distinct actions and intentions before combining them into typical user flows.
Another major hat-altering action that I left out above:
- Change the underlying asset
Users will likely want to swap out low-yielding underlying assets for high-yielding rToken assets. While at launch only rDAI invested in Compound cDAI will be available, other platform DAI lending (dYdX, Fulcrum, etc) will likely follow, and then other assets beyond stablecoins.
Swapping the underlying asset would involve redeeming the rToken to the underlying asset, trading it for the new rToken-compatible asset, then minting rTokens from the new asset. How should Tribute function in such a case? Would everything reset, requiring tribute flows to be manually restarted? Would tribute flows be able to be “paused” for some finite period of time until the swap is completed, as distinct from turning them off?
Relatedly, users may wish to hold a basket of rToken assets to diversify their interest-bearing portfolios. How should Tribute function with multiple rTokens owned by the same user, with each asset having a different variable interest rate? Would there be a logical and safe way to abstract those distinct interest flows away in a well-designed UI?
Would “hat mirroring” make sense here, such that tribute allocations are split among each of the assets with identical recipients and proportions? Or should allocations be asset-specific? In the latter case, should Tribute “recommend” which asset to make an allocation from based on current interest rates and the amounts of unallocated tribute from each asset?
Cureently I dont think its possible to change the underlying token asset. Only to change the allocation strategy- which can only be done by the admin. To use a different underlying token, you would need to use a new separate instance of the rToken contract.