Elastic Hat Problem

Named “Elastic” because a hat’s proportion-value can grow/shrink depending on a change in rDAI balance. Hats are not static in v1 rDAI

Copying Victor’s comment from another post:
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?

Based on Brian and Ethan’s research, changing the contracts themselves is the only way to solve this problem. How can we fix it with minimal changes to the contracts? Is this a task we should take on ourselves, or just put together an argument why it’s necessary?

I believe I have a framework for a potential solution to the elastic hat problem.

Instead of trying to maintain the one-wallet/one-hat/multiple-tribute-recipients format, what if we were to build a system that made each instance of Tribute an atomic event with a unique hat and 100% of the interest flowing to the recipient?

Here’s how it would work. If I have 1000 DAI and want to send Tribute of 50 to a charity, when I click Send Tribute, the app 1) creates a new HD ethereum wallet address, 2) transfers 50 DAI and enough ETH to pay for gas to the newly created address, 3) approves 50 DAI spend allowance and mints 50 rDAI from the new address, 4) creates a new hat with only the address of the recipient and 100% proportion value. Tribute would then recognize that the newly created wallet is controlled by the user that created it and keep track of and manage that amount in the dashboard.

Downsides are the additional steps in transferring DAI and ETH and the switching/checking balances from multiple addresses.

I like this idea a lot. But it does present more technical challenges, and although they have all been solved, it would be a massive undertaking to put everything together and expect it to work smoothly.

Creating additional external accounts requires the user’s master (private) key. I’m not sure if external accounts would even be possible given the current abilities of metamask. And even if we were able to use a Metamask Snap to accomplish this (they give each dapp their own private key to do crypto stuff), we would be restricting customers to only using Metamask (and no mobile Snaps available atm).

The alternative is to deploy contract wallets. This would also give the ability to wrap mutli-step functions in a single transaction. Pair this with meta-transactions paid for by a single “master” Tribute wallet per-user and you could have a very user-friendly process.

Howver, this huge technical hurdles could be easily accomplished by making a change to the rDAI contracts. Rather than change functionality to the hats, you could add an additional mapping to the way accounts are handled internal to the cobtracts. For instance, address -> balance could become address -> accounts[ ] -> balance