How can we prevent misdirected funds?

Given that rTokens are unfamiliar to all but a few users and that the continuous delivery of payable interest which must be redeemed is unlike other Ethereum value transfers, it is likely that a lack of guardrails may lead to a number of frustrations for both senders and recipients.
For example, a regular user of rDAI may decide to use Tribute to send a fixed payment amount over a period of time to someone who does not know to look for the accumulating interest, and does not know how to redeem it. This recipient may believe that no payment has been made leading to conflict that we should seek to preempt with design features.
One possible solution would be for Tribute to perform a check on each attempt to send tribute to see whether the recipient address has ever interacted with an rToken contract before. If not, a cautionary notification would alert the sender that it is possible the recipient may not know how to handle incoming tribute, requiring a second acceptance to send the tribute.
This would also suggest that recipients who install a Tribute widget on their sites should perform some interaction with an rToken contract so that they would not trigger the notification to senders if they had not yet received any tribute. Alternately, Tribute could maintain a database of recipients who had initialized widgets, obviating the need to interact with an rToken contract to begin using Tribute without obstacle.

I agree with the warning message for sending to an address not on a whitelist. Lets lock that in for v2 features.

On the receiving side, I would prefer forcing an interaction with the smart contract to remove these alerts.

  1. It is dummy-proof in that you cant accidently set the receiving wallet to an address you don’t control.
  2. It doesnt require a central database for a whitelist.

To address the issue of usability. I think once you install the widget, you are locked into an ‘initialization’ screen until you call the function. It just has a big button thats like, click here to initialize, and calls changeHat or something on the rToken contract. Easy, simple, dummy-proof.

I was referring to the widget in the above comment. I dont think it would be necessary to place on the dashboard, simply b/c if you’re on the dashboard, it means you have already interacted with an rToken contract

One alternative to my idea is to have a whitelist, but its a registry contract tied to ENS. each provider who registers gets a subdomain myDapp.tribute.eth and this provides a lookup to their website, receving wallet, and a short description. Could be pretty nifty

I like the mandatory receiver interaction plan. I think the ENS subdomain idea could work well as a non-mandatory service offering to help onboard people.

However we wouldn’t want to dissuade people from using Tribute because they might have DAI in an existing wallet and don’t want to have to move it to a new ENS-based wallet address.

Yeah we should put the ENS integration as a non-requirement for now