Add VIP: VTHO burn mechanism

VIPs
1

This adresses the VTHO issue by introducing a burning mechanism. Allowing users to burn VTHO which directly tackles the VTHO supply challenge.

PR: Add VTHO burn mechanism by VeCorgi · Pull Request #58 · vechain/VIPs · GitHub

5 Likes
2

Looks good. Need to get the technical teams perspective on this.

2 Likes
3

Thanks Brettski! Let me know if there is more input needed :fire:

1 Like
4

Hey,

So having spoken with some of the devs there is a suggestion that instead of extending the functionality of the core VTHO contract through the introduction of the burn and burnFrom function instead the the VTHO circulating supply is calculated as total supply - locked supply. Where locked supply refers to the balance of VTHO in 0x000000000000000000000000000000000000dEaD and 0x0000000000000000000000000000000000000000.

Thoughts?

4 Likes
5

i am not against the dev suggestions as it may potentially allow the possibility of including the blacklisted addresses in thor/blocklist.go to the list of locked supply

would it then be this line 101 including the subtraction of “LockedSupply” from zero and dead addresses & a new function for tracking the VTHO at these addresses?

2 Likes
6

when i saw this suggestion i imediatly thought the same as @tom did.

like this we could take out some of the bigger VTHO generating, blocked ,wallets as well.

2 Likes
7

The key question that the devs are coming back with is why would this need to be on-chain?

A query can be made off-chain for this information with no need to update the protocol.

Some useful information perhaps that arose when discussing with the devs that is worth sharing:

  • The blocklist was created to respond to an attack with stolen funds. Useful articles with more information here and here.
  • The blocklist only applies to mainnet.
  • The addresses on the blocklist still generate VTHO but it is not usable as those addresses are blocked.

When calculating the circulating supply of VTHO it is correct to consider the VTHO at 0x0, 0xdead and all of the addresses on the blocklist as burnt VTHO. This would mean that the VTHO circulating supply can be calculated as:

VTHO circulating supply = VTHO total supply - VTHO trx burned - VTHO @ 0x0 - VTHO @ 0xdead - VTHO @ blocklist addresses

Links:

Perhaps worth reaching out to VechainStats and exploring the definition of the VTHO burned from the first link in the list above. Perhaps the logic could be updated if it doesn’t already reflect the above calculation.

Thoughts?

3 Likes
8

I understand the feedback. However, we cannot trust in third parties to always represent the correct supply if its not baked in in our contract.

i would recommend it being on chain, so we dont need to rely on third parties to show the correct amount. thus decentralising the right amount shown everywhere so there is no room for discussion.

Let me know if i made myself a bit clear about the whole idea behind this :smiley:

1 Like
9

The calculation is verifiable though with the proposed off-chain solution as anyone can check the addresses for the VTHO balance and can deduct it from the VTHO total supply.

Perhaps I am missing some context in terms of why it should be on-chain. Do you have more reasoning that you could provide? What is the use case as such?

2 Likes
10

The general idea was this burnfunction would be the foundation for the future.

With a burn function in place there could be made DApps. This to help burn VTHO. (my main example is a VTHO lottery where you could F.E. buy a ticket for 1000 VTHO, each week there is a lottery held which burns 20 procent of the jackpot and payes out 80 procent to a winner or with multiple winners).

This would be a interactive way to burn VTHO. I agree with a verbal agreement like ‘there you find the burned tokens’ but is not as automated as it could be. People who dont think of the 0xDeAD adress will see the VTHO supply without the dead adress. Also we would need to monitor the supply presented on CMC for example (one of the mayor players) are they correctly and frequently doing the math on both adresses?

its the same principle as a ‘one stop shop’ you cant forget anything in the equation if its already implemented in that same contract.

The most right way would be the original idea, where we add a burn function in the contract. Then the supply is technically right.

i’m not against the dev suggestions to calculate the total supply with total supply - locked supply where locked supply could refer to the dead adresses and perhaps also the blocked ones as Tom suggested.

2 Likes
11

Good point- it does indeed look like VechainStats already tracks the blocked accounts and counts their VTHO as burned.

2 Likes
12

@brettski is this still relevant or do you wish to postpone/close the vip proposal?

1 Like
13

Hey @VeCorgi,

I think the latest state is that the devs don’t see a strong requirement to add a VTHO burn mechanism on-chain as the information is available off-chain.

I believe that the formula below captures how to calculate the circulating supply and I believe this is all queryable on-chain. The VechainStats API or the VORJ API should provide access to the data.

VTHO circulating supply = VTHO total supply - VTHO trx burned - VTHO @ 0x0 - VTHO @ 0xdead - VTHO @ blocklist addresses

So I guess the question comes back to do we need a burn function on the VTHO when there is an existing way to get this information already.

2 Likes
14

Thanks for the info. I think the main goal i want to make clear is now we have the information available offchain…

if we look at this perspective you present, one could even ask why do we even put anything on chain? why do we have blockchain?

I think if we answer this question, ‘why do we have a blockchain and why do we put things on chain?’, is the answer to why a burn should be implemented on chain.

3 Likes