[Proposal] Partially refund accidental burns

Two seemingly unrelated pieces of background:

1: There is a large supply of unallocated incentive TRU. There is ongoing debate on whether some of it should be burned.

2: People frequently ‘burn’ TRU by accident. So far, as is the default in the crypto world, those folks have just been out of luck.

So I’m not sure of the exact details, but I propose that we use unallocated incentive TRU to partially reimburse people who accidentally burn their TRU. Effectively, whenever someone burns by accident, we would shoulder some of the burn. The unfortunate person who actually did the burn comes out happy (or rather, less sad - we would not be reimbursing them fully), and yet it arguably costs us nothing if we wanted to burn some tokens anyway.

If we completely ignore perception/optics for a moment, I think this is simply a moral thing to do. People are accidentally losing their money, and while it is true that it’s “their own problem” and crypto comes with no guardrails, that doesn’t mean it’s actually a good thing that people are losing their money. And assuming token burns are good for the protocol, then these poor fools who do so by accident are actually providing us a service; their actions have positive externalities. We’d simply now be allowing them to charge the protocol something for the service they’re providing - giving them a way to capture some (but not all) of the externalities they produced. Again, we are allowed to grab all these externalities for free (and that’s how everyone else does it), but that doesn’t mean it’s the right thing to do.

Now for meta-level stuff - perception, optics, precedent: …I’m not sure. I definitely have an instinctual “sounds like a dangerous precedent”, but I can’t really justify it. And for people who don’t yet know what’s going on, it might look bad for the incentive pool to be doing transfers to random-looking individual users. But there are surely optics upsides too. For one thing, to the extent that others agree with the object-level “it’s the right thing to do”, we then get the optics boost for doing the right thing. Also we probably get some positive attention simply for doing something that hasn’t (as far as I know) been done before. Ultimately, I don’t want to put too much weight here anyway; if we believe it’s the right thing overall and the right thing for the protocol, then I’d expect everything else to follow eventually.

Here’s a first draft at concrete implementation details; I’m not attached to any of these specifics but just wanted to give an idea of how it could work:

1- We allocate some amount of TRU (2mm?) from the unallocated incentives to a new ‘Guardrails Pool’

2- We whitelist certain specific transaction types that count as burning TRU. For example,

  • actually calling burn() on your TRU
  • sending your TRU to the TRU contract address

3- Someone who has accidentally burned TRU in one of these ways alerts us of this fact (google form? forum?), providing a tx hash.

4- We (the company?) review the tx, then send the address which originated the tx 50% as much TRU, paid from the Guardrails Pool. (There would also be a minimum deduction to cover the cost of our gas and our review time. So sufficiently small burns would end up reimbursed at a lower rate or not at all.)

The goal is to make this not gameable in any way - you can’t get a reimbursement without first losing significantly more than you will get back. Or if someone believes that burning their tokens one-for-one with incentive tokens will be more than compensated by the rising price of their remaining tokens, then… go ahead and try gaming it like that? I won’t join in but will happily accept the price boost.

Benjamin,

Please inform us as to how some people accidentally burn their TRU.

George

@benjamincosman thank you for this proposal. I think this makes a lot of sense and would help our community to sustain and grow.

I think the most common way is accidentally sending to the contract address. This isn’t exactly the same thing as burning since the tokens nominally still exist, but they are trapped in the contract forever so they’re as good as burned. (And in any analytics we have control over, we could choose to subtract them out from the total supply.)

Thanks for getting back to me Benjamin…what does it mean to send coins to the contract address?

I want to make sure I don’t do this!

George

Let’s say your friend is at address 0x1a, and the code which defines the TrueFi token is at address 0x4c. (Because both people and smart contracts have addresses in Ethereum. Also note in reality all these addresses are far longer.) You try to send your friend some TRU, but instead of pasting 0x1a into the “to” field, you paste 0x4c (possibly because you recently had it in your copy-paste buffer when looking up what token to send). So now the contract gets the TRU instead of your friend (and just holds on to it forever, since it doesn’t ‘know’ what to do with it; it’s just a piece of code.)

As I understand it this would be a ~2M TRU pool for reimbursing people who made a typo and accidentally sent to the TRU contract address? At present USD value that would be about $800k.

I would love to understand further why this is a major problem and why it’s the best use of 2M TRU instead of putting it towards other options such as marketing incentives, SAFU, or developer incentive grants, liquidity providers incentives.

How will this program be managed so that it is properly reimbursing users and not allowing funds to flow to users who should not be getting reimbursed?

Who will handle reading the Google forms, checking the block explorer for validity, and submitting the refund? Will the receiver understand that in many jurisdictions this would be considered a taxable event and they would need to report it in their taxes?

Thanks, I look forward to learning more about the topic!

Edit -

Would also like to understand how money laundering concerns could be addressed.

Last, it seems a bit weird to create a financial benefit to support people who make typos.

1 Like

There are 240mm TRU that are currently unallocated, so this proposal appears to be competing not with uses such as marketing and SAFU, but with “continue to sit unallocated”. And given the size of that pool, this would remain true even if some new proposals for tens of millions of dollars of marketing etc appeared. So it does not have to be the best use to be worth doing; I simply claim it is a good use.

I would propose that we authorize the company to review and approve individual requests. I don’t think “checking the block explorer for validity” is a real concern - isn’t Etherscan widely accepted to be trustworthy? And as long as refunds are processed only to the sender of the original tx, I don’t see how they would flow to the wrong users.

First of all, I’m not a tax attorney but I’m not sure this is actually true - after all when in normal life you make a mistaken purchase and get a refund, that isn’t a taxable event, is it? But even if it is true, I don’t think it’s our problem - isn’t the standard that it’s on them to get their taxes right? I don’t see us worrying that farmers get their taxes right, or rather maybe we do worry but it doesn’t stop us from providing farming rewards.

What do you mean? In particular, what’s the money laundering concern that appears here but not in say farming?

Ultimately I am making mostly a moral case here, and you don’t have to agree with the values or the weights I assign to them. But some values that are going in to this are:

  • I believe that it is a bad thing when people get hurt, even if no one else is at fault.
  • I believe that people should be paid for services they provide and positive externalities they produce.

There are also multiple ways to frame the same setup. For example, there is currently a line in the smart contracts which prevents users from sending to the zero address. So there are people who send to 0x0, and then by reverting the tx we refund to them not just 50% but the full 100%! Do you support removing this financial benefit for people who make typos? Just think, we could delete that line, and then there would be more accidental burns pumping up our token price, and as an added bonus we’d pay (a little) less gas on every transfer since there is one less line of code! But I think it’s reasonable for that line to remain as a guardrail against people hurting themselves by accident. And ultimately, I view this proposal as just a more complicated version of that line - people are hurting themselves, and instead of saying “sorry there’s nothing we can do” while pocketing the burn externalities, we have the power to make them not hurt themselves quite so much.

1 Like

Hi Benjamin,

Thank you for explaining!

I am a neophyte with crypto, though I’ve been studying a lot, and dipping in my toes.

You must be related to our founder Rafael, and I am very impressed with the transparency and honesty with which my investment in TrueFi has been handled. And it seems the way of the blockchain is very democratic.

But even in a democracy we need leaders, hopefully benevolent. I’m concerned when I see votes and discussions that just a handful of people respond. Am I missing something?

If most of the people are as uninformed as I, perhaps they don’t feel comfortable. In which case, we need some direction and discussion – as you have suggested here with the accidentally burned TRU tokens.

I just have this feeling I don’t know where TRU is headed, who is the driving force behind taking us there, and what the future is for TRU. I’ve been glad to have held on to my original $5000 (which was surprisingly offered back to me before final token issuance), because at today’s prices the tokens are worth roughly $18,000.

But I don’t know if I should swap for Ethereum (or even if I can). I just feel lost.

Any advice? I may not be the only investor with this feeling.

Thanks,
George

Yes I’m Rafael’s brother, though here I’m wearing my just-another-token-holder hat.

Are you on the Discord? because discussion happens there too. Also some people don’t choose to join the discussion part but then still participate when it comes down to a vote. So overall participation is a lot higher than e.g. just this thread would make it look.

I think the rest of your post is veering far enough from the original topic that it should be made a separate post (or brought to Discord instead). Also no one here can give you investment advice; you certainly can swap your TRU for ETH (e.g. here) but you will have to decide for yourself.

1 Like

Hi Benjamin,

Thank you for the thoughtful and well-written reply.

I learned a lot from your post and, upon further reflection, now understand the merit of the proposal. I’ll add a few thoughts inline.

There are 240mm TRU that are currently unallocated, so this proposal appears to be competing not with uses such as marketing and SAFU, but with “continue to sit unallocated”. And given the size of that pool, this would remain true even if some new proposals for tens of millions of dollars of marketing etc appeared. So it does not have to be the best use to be worth doing; I simply claim it is a good use.

This is a good point. Though it would be great to see that unallocated TRU deployed for activities that enhance the protocol (SAFU, marketing, etc.), it is a separate topic from this proposal.

I would propose that we authorize the company to review and approve individual requests. I don’t think “checking the block explorer for validity” is a real concern - isn’t Etherscan widely accepted to be trustworthy? And as long as refunds are processed only to the sender of the original tx, I don’t see how they would flow to the wrong users.

What is meant by ‘checking the block explorer for validity’ is that when someone fills out a Google form that user may report that they sent transaction X to the TRU smart contract. Someone needs to open Etherscan to confirm that transaction X exists, it was sent to the TRU contract, and that transaction X succeeded with a sufficient number of block confirmations. Then that person needs to send a refund transaction at 50%, subtracting out the estimated gas cost and review cost. For transparency, it would be great to have an Etherscan link that shows all of the refunds sent from the Guardrail Pool.

First of all, I’m not a tax attorney but I’m not sure this is actually true - after all when in normal life you make a mistaken purchase and get a refund, that isn’t a taxable event, is it? But even if it is true, I don’t think it’s our problem - isn’t the standard that it’s on them to get their taxes right? I don’t see us worrying that farmers get their taxes right, or rather maybe we do worry but it doesn’t stop us from providing farming rewards.

I would agree that handling taxes are not TRU’s problem.

Taxes depend on the user’s jurisdiction. I am also not a tax lawyer and this is not tax advice but just my personal understanding - In the US, cryptocurrency is classified as property so it is not given the same tax treatment as fiat currency (USD). So, in the US, purchasing a product with fiat is not a taxable event. Returning that product is also not a taxable event. However, purchasing a product with cryptocurrency is a taxable event (capital gains on the value change of the cryptocurrency above cost basis). The most unintuitive thing is that ‘purchasing a product’ for 100 token and ‘returning that product’ for 100 token can also be a taxable event. When we think in crypto terms there ought to be no change since it’s -100 token / +100 token for a net of 0 token. However, crypto is recorded in cost basis on fiat currency (USD) terms. So if those 100 tokens were worth $5000 USD at the time the ‘purchase’ was made and worth $10000 USD at the time the 100 tokens are returned, this can be treated as a taxable event of capital gains $10k - $5k = $5000 USD. Note this does not happen when transferring cryptocurrency between personal accounts (say from your wallet to Coinbase). But when interacting with a smart contract belonging to a different entity, it is likely to apply. See https://tokentax.co/guides/how-bitcoin-and-cryptocurrency-is-taxed/ for more details.

What do you mean? In particular, what’s the money laundering concern that appears here but not in say farming?

I should clarify, there is increasing scrutiny regarding Anti Money Laundering for DeFi. I think with this proposal there is no additional risk, it’s just one more thing that’ll require AML compliance, if TRU needs to take on an AML implementation in future years.

https://www.coindesk.com/fatfs-new-guidance

And ultimately, I view this proposal as just a more complicated version of that line - people are hurting themselves, and instead of saying “sorry there’s nothing we can do” while pocketing the burn externalities, we have the power to make them not hurt themselves quite so much.

Fair enough, it is true that when these mistakes happen it’s an unintentional burn at the expense of that user and to the benefit of TRU holders. Giving a partial refund would be a nice and generous action on the part of TRU.

I’d vote to support this if the team is willing to take on the logistics and there is transparency for all the refunds that are processed from the Guardrail Pool.

Hi Ben,
I understand your arguments and am leaning towards agreeing with you. I think the only concerns I have are what probably many token projects have which is repatriation of mistakes like this must be ad-hoc by nature. As the platform grows, and perhaps as the ETH ecosystem grows, more and more people will be interacting with smart contracts and make mistakes due to carelessness or lack of technical know-how.

As long as the company does not take on too much of a burden (in terms of cost of reviewing versus guardrail penalty), I do not see this being an issue.

Hi.

I hope this proposal will be available in the future. I have just send my token from exchange into smart contract (instead my wallet).

Please someone can help me? :disappointed_relieved:

It’s me, Geogre.

I have just send my token from exchange into smart contract (instead my wallet) when I don’t fucus on what I am doing.

Big mistake! :disappointed_relieved:

@tylerw @MG-TT Can we vote on this? how does one add a poll to the thread?

I’ll get you permission to create a poll here. Will follow up shortly

In my opinion, there are more important things to focus on that this issue. As for preventing accidental burns, having better documentation and educating the folks with TrueFi usage can make more impact than having a fund to reimburse accidental sends. The latter can also be easily abused. More important issues the team/community should be looking at.

1 Like

@benjamincosman are you able to create a poll?

You should be able to see a ‘Build Poll’ option like in the screenshot

I agree this isn’t highest priority. However it also seems like it would take very little time/focus, so it still seems like a win to me. re “The latter can also be easily abused”: how? It seems like with a few simple procedures which I’ve included above, like only sending to the tx originator and only allowing certain whitelisted tx types (like a transfer to the TRU address), we could make it not abusable, but if I’m wrong I’d love to know!

  • YES in current form (including 2mm TRU for the pool, 50% refund rate)
  • YES to something similar (please add comment below)
  • NO

0 voters