Representing Value in Tribute

Many people have expressed its unclear what Tribute represents. Is it the token, the interest?What does sending Tribute mean you are sending?

I’d like to propose that we consider representing Tribute as buying power per unit of time. One reason we wanted to avoid this in the beginning was to disassociate Tribute with value, so that people don’t hoard the value for themselves. I think that this might just be a necessary/unavoidable fact of simplifying things. There’s no real intuitive way to express value, without actually expressing… the real value.

Another concern is making sure things are in whole numbers, and not ridiculous fractions of cents, like 0.000001 etc. To solve this I suggest changing the unit of time depending on the overall value. For example:

$1 Tribute / hour
$1 Tribute / day
$5 Tribute / month
$100 Tribute / year

Each time Tribute is requested, it will be shown in the appropriate denomination (hours, days, months…) with “remaining buying power” in the same denomination.

Tribute requested:
$5 Tribute / month
$23 Tribute /month will still be available after activating.

One additional problem this solves is the issue of having multiple rTokens, with different interest rates. They can all be calculated into value/time, whereas in the current way, this would be difficult to represent multiple types of rtokens in terms of a single Tribute unit.

Here is how I imagine showing the “Mint Finance” or “Bifrost” idea for showing where funds are being spent. I think for simplicity’s sake we must also show the unused portion in the graph. Yes- this will mean that users feel less inclined to spend their wad…

Say you only have 100 DAI, then we only show your account (like in above picture) in terms of $7 Tribute / year

If you try to access content in a higher tier then the prompt would look like this:

$1 Tribute / month
But you only have $7 Tribute / Year
$200 DAI more is needed
(Button - “Add DAI”)

Now this raises another question- how do we differentiate between principal and buying power.

$100 DAI balance
$1 Tribute / month

$100 Tribute balance
$1 / month

$100 Balance
$1 Tribute / month

$100 DAI Balance
$1 DAI “tributing” / month

Personally I do not like the idea of denominating in DAI. I wilL always argue for the fewest terms, e.g. $1 rather than $1 DAI or 1 DAI.

1 Like

These are excellent points that raise the fundamental question of what we want users to do with Tribute and how best to communicate those options.

Before weighing in on some of the particular solutions you offered, I think it makes sense to step back for a moment here and scope out the design space that we are working with as well as its challenges. Let’s start with the challenges first.


  1. Education - Tribute and rDAI present new financial tools that no user is already familiar with. People might have a conceptual grasp of paying with interest, but they don’t have any experience actually doing so. Once we have a clear design, we should plan to build an interactive tutorial to explain the underlying concept and show how it functions, but this begs the question of what we are explaining.

  2. Variable Interest Rates - Currently the only savings strategy in rDAI involves Compound’s variable interest rate. Not only is this another unfamiliar financial concept to most users, it has the almost certain potential to create expectations of future buying power that will be dashed by variability. In the event of increasing interest rates, users may feel irrationally optimistic and “overspend” when compared with what they would do with a fixed interest rate. With falling interest rates, users may experience the unpleasant sensation of “loss” of buying power, which could be as psychologically discouraging as investment losses even though the users’ principal balance never goes down.

  3. Multiple Underlying Assets - Soon rDAI will be joined by other rTokens that have the same characteristics when supported by interest-bearing liquidity pools. Managing multiple assets in unified Tribute dashboard will be a challenge, even with similar assets such as an rDAI variant that is invested in the Dai Savings Rate. How would Tribute display the buying power of a wallet containing half Compound-invested rDAI (variable interest rate generally fluctuating between DSR and SF) and half DSR-invested rDAI (periodically adjusted fixed rate)? And while that two-stablecoin portfolio example is tricky enough, rTokens will likely include non-stablecoins such as synthetic “staked” ETH once proof of stake is live. With volatile assets invested in variable interest rate liquidity pools, displaying useful buying power information to a user is a delicate task. It is possible that those two metrics may reinforce each other, with a surging ETH price driving up the lending rates for ETH and vice versa in the falling ETH price scenario.

  4. Hat Proportions - Non-users can increase a wallet’s rDAI balance without any action by the wallet owner, either by calling payInterest on behalf of someone else or by sending rDAI directly. This will increase the amounts going to the recipients proportionally, circumventing our integer-based fixed Tribute amount framework. How can we design such that user decisions about how much to send as Tribute don’t get out of whack due to external actions?

Design Questions

  1. Display Choices - Before analyzing what we should show users to help them utilize Tribute, let’s lay out everything we could show them to figure out what combination makes sense.
  • Underlying asset balance - e.g. 1000 DAI (all other figures are based on this wallet balance)

  • Mirrored Tribute metatoken - status quo option, e.g. 1000 Tribute balance, decremented by amounts sent to other addresses

  • Annual buying power in underlying asset - e.g. at 7% APR on Compound, buying power = 70 DAI OR if wallet held 6 ETH @$175 that were invested at 4% APR, buying power = 0.24 ETH

  • Annual buying power in DAI - same as above for DAI but for ETH, buying power = 42 DAI - we could also use USD instead

  • Variable period buying power - same as two examples above, but user could elect to view buying power on hourly, daily, weekly, monthly, etc. basis.

  1. User Profile - What type of user are we designing for? How much underlying asset value should we be thinking about constructing reasonable use cases for? We should probably rule out designing for a 1 DAI balance and a 10,000,000 DAI balance but where should we set our initial utility range minimum? I suspect that those people familiar enough with DeFi to experiment with Tribute are not like regular consumers with strict budgets, so perhaps we should design around a user profile with a 1000 DAI balance to demo primary use cases. CDPs may be instructive here - there are nearly 1,500 open CDPs with DAI debt >= 1,000 DAI and the 1,000th highest DAI balance on etherscan held 4,000 DAI, so this may be the audience we should target initially.
1 Like

In response to Design 2. User Profile

I understand the need to cater to a defi-savvy audience for the purposes of gaining immediate traction. However I think now is a good time to take another step even further back and start attempting to answer the most important question:

What specific real-world problem(s) are we trying to solve?

Edit: This post quickly grew into its own topic, so I created one here Real-world problems Tribute can solve