HTS Community Burn Address #804
Replies: 8 comments 25 replies
-
|
Hi Cooper, here are my 2 cents. I suggest dividing the problems into more pieces. You can
It seems to me the first option satisfies your user story, so your main current options are:
I prefer using a generic and public smart contract for every token. And this smart contract is also, incidentally, an HBAR sink. // SPDX-License-Identifier: GPL-3.0
pragma solidity 0.8.18;
interface IHederaTokenService {
function associateToken(address account, address token) external returns (int responseCode);
}
contract TheSink {
address constant precompileAddress = address(0x167);
function associateToken(address token) public {
precompileAddress.call(abi.encodeWithSelector(IHederaTokenService.associateToken.selector, this, token));
}
} |
Beta Was this translation helpful? Give feedback.
-
|
I'll be honest, I'm a bit confused.. But thoughts as follows --
|
Beta Was this translation helpful? Give feedback.
-
|
Would such a burn address work for regulatory purposes (ie: loss harvesting)? Does anyone know of any precedence/rule supporting this notion? |
Beta Was this translation helpful? Give feedback.
-
|
In practice, this makes sense, I'm just wondering if there would be any tweaks necessary to keep people out of jeopardy (including the original 50 key generators) |
Beta Was this translation helpful? Give feedback.
-
|
Depends! I'm not a lawyer, accountant, or otherwise. Would ask them & one that's specifically in your local jurisdiction! Generally I think tokens in this address would be considered unrecoverable similar to losing keys on a "boating accident"... But actually far, far, far more provable than trying to prove you lost your own keys. I don't see how it's less strong of a guarantee than other arguments that would be made 🤷 |
Beta Was this translation helpful? Give feedback.
-
|
Oh, there is one way this breaks down. The burn address must be funded with enough hbars such that staking provides enough income to rent for all time, if the account goes away, the current hedera implementation returns the token assets to the respective token treasuries. |
Beta Was this translation helpful? Give feedback.
-
|
It would be nice if there were a native ledger burn account. A keyless account can be created (0.0.800 is an example) |
Beta Was this translation helpful? Give feedback.
-
|
I'm not worried about this. e.g. I'll donate $100+ of HBAR to the community burn address at the start, and more as necessary. Rent shouldn't be that crazy. |
Beta Was this translation helpful? Give feedback.
-
|
Theoretically as the amount of tokens grow at the burn address the more will be required to pay for the rent, no? Is there some point, if even in the distant future that there will needs to be a boat load of HBAR just to pay the rent? |
Beta Was this translation helpful? Give feedback.
-
|
I think this is more than a passing concern. Somebody has to put enough money in to support whatever the number of tokens and associations is. This proposal isn't a burn. It is a "hold as long as you can". Maybe there will be a willingness from people in the community to pay for it. Maybe not. Time will tell! |
Beta Was this translation helpful? Give feedback.
-
|
Isn't one of the network's features predictably stable fees? With rent, what is my cost to store this for 100 years? or 1,000 years? Can you tell me so that we can donate enough to make that happen? Cause i'm the target user here and openly saying I will donate whatever it takes (and don't forget i worked at hedera for 3 years so have quite a bit of hbar to give away or donate to practical uses). This proposal is a practical burn given the network's existing feature set. If implemented properly, and people donate, which I am saying myself that I will, it works -- and you + the council don't have to do anything! |
Beta Was this translation helpful? Give feedback.
-
|
Throwing this out there as an alternative idea - I came up with it on the back of a napkin, so feel free to shoot it down in flames. What if the network had a dedicated burn address that anybody could send fungible and non-fungible tokens to. This would not be a normal account, it would be a "system" account that's sole purpose is to exist as an address to send tokens to for burning. Tokens sent to this burn address would be deleted from the network; that is, wiped from state. There would be no mapping of burn address -> token id : balance in memory. Instead, the consensus nodes would deduct the token amount from the balance of the user sending tokens to be burned, and then reduce the token's supply by the amount of tokens burned. A record of this burn transaction taking place would be available for transparency (audits, provability, etc). It would essentially allow anybody to burn tokens, similar to how tokens are burned with a supply key, even if that token has no supply key. One potential issue may be if a token issuer does not want this to be possible, for whatever reason. Perhaps when creating a token there could be an optional flag to enable or disable this burn mechanism. If enabled, anybody will be able to burn tokens by sending the tokens to the burn address, thus reducing the supply. If disabled, tokens cannot be burned through this mechanism; if an attempt is made to send tokens to the burn address, and the token has this mechanism disabled, the transaction would fail. Pros:
Cons:
|
Beta Was this translation helpful? Give feedback.
-
|
Perhaps I should add "smart contract sink" to my rejected ideas category 🤔 lol |
Beta Was this translation helpful? Give feedback.
-
|
Apologies, I should've linked to a page that links to the source code: https://davincigraph.io/devs/burns/contracts/0.0.3158042 IMO it's easier for people to understand the idea of a burn contract vs an account with threshold keys, a wallet burning ceremony and people deleting their keys. Besides that, contract vs account is similar in that both need hbar for rent/renewal, associations, and potential risks (contract vulnerabilities vs not enough people deleting their keys). If contracts are out of the question then your idea seems sensible. 😃 |
Beta Was this translation helpful? Give feedback.
-
|
No worries or need to apologize! I'm not looking for smart contract solutions. It's a HTS Community Burn Address, intentionally. Personally I find these trust assumptions far easier to understand/rationalize & generally think Hedera's account system is more secure &/or stable than the smart contracts. The community should setup or standardize a "Smart Contract Community Burn Address" if they're interested in doing so! |
Beta Was this translation helpful? Give feedback.
-
|
I like the thought, in that it actually burns and doesn't accrue costs the more it is used. However:
Some very good real world use cases have regulatory requirements, and not allowing somebody to burn a token is one of those. All current tokens would have to have "magic burn" disabled, and future ones could enable "magic burn". So basically I think the idea with a magic burn address is that tokens could either be burned by burn key or magic burn, either or neither or both, as options. Maybe that makes sense (I don't know, I don't really get the use case for users burning so I'm not a good one to ask). |
Beta Was this translation helpful? Give feedback.
-
Sorry but this seems to be a bit handwavy & unrelated? I'm specifically writing a proposal for immutable tokens. So, once tokens are immutably created and in a users wallet, they should permisonlessly be able to do whatever they want with them (otherwise the token would not have been made immutably)... I'm not targeting any type of compliance use cases here. They simply shouldn't use this!
What is magic burn? i've never heard that phrase before & again i'd reiterate I'm not interested in proposing a HIP that changes the protocol for this fundamentally basic use case that I believe & would argue can be achieved by the existing feature set. I'd actually be kinda sad if this ended up in a protocol change 😞 im of the opinion that we should be building tools that support the existing features (e.g. why would it be hard to setup this multisig wallet right now? why does no one use threshold signatures on hedera when they're really nice?) rather than continuously changing things to marginally improve the network's feature set. My use case is that I hold $CLXY tokens and want to remove (some) from total supply and circulating supply. |
Beta Was this translation helpful? Give feedback.
-
|
Howdy folks. Appreciate the discussion, feedback, and suggestions. Wanted to let everyone know I have updated the discussion to clarify that "Smart contract sinks" or "smart contract based burn addresses" are now rejected ideas. I am specifically looking for a burn address that does not use smart contracts and leverages community/social trust. Hopefully this helps 😄 |
Beta Was this translation helpful? Give feedback.
-
|
& a meme for good measure
|
Beta Was this translation helpful? Give feedback.
-
|
Another option is to use the hollow-account feature -- just use some special ethereum-account compatible address, like 0xFFFFFF....FFF, and send tokens to it. Nobody will ever have the keys, so you don't kneed any "social trust". You just send stuff to that address and you're done. If the associated account expires for lack of hbar funds, then everything still gets sent back to their respective treasuries, so that problem is the same as in this proposal. But no need to trust anybody at all. |
Beta Was this translation helpful? Give feedback.
-
|
This is interesting! Didn't know it existed. Thank you for mentioning it. After some googling and searching your docs I found this 
What is to prevent myself, or whoever set it up, from later adding the key and gaining control of all the assets in the burn account? |
Beta Was this translation helpful? Give feedback.
-
|
You would need to know the private key to that address. How could you come to know it? |
Beta Was this translation helpful? Give feedback.
-
|
@Cooper-Kunz it looks like this has gotten enough discussion and is an interesting idea, what do you think about formalizing this into a PR with the hip template? |
Beta Was this translation helpful? Give feedback.
-
|
Here's some possible burn addresses i created on Hedera by sending the EVM address a HTS token, thus ensuring the address would have unlimited auto association:
A dead address with a more memorable account ID would be good however, something like 0.0.666 with the EVM address 0x0000000000000000000000000000000000000000 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Abstract
I'd like to propose that we create a community burn address, specifically for immutable HTS assets. This would be a publicly known address that leverages Hedera's native threshold signatures so users can send their (immutable) fungible, and non-fungible Hedera Token Service (HTS) based assets to, in order to permanently remove them from circulation (i.e. burning them).
Motivation
Being able to burn immutable tokens is good, and necessary, for a lot of projects.
How it works
We make a wallet on Hedera, which has auto-associate turned on, configured with the highest key/signature schema possible, e.g. 50 out of 50 signers are required, and get 50 different well known, reputable Hedera community members to be signers. After creation of the account, the signers delete their keys. It's that simple!
If properly implemented with diverse stakeholders & toolchains, the community gets a get a 1/N honesty assumption that these funds will never move, e.g. it would take all 50's keys being compromised, or all 50 signers colluding to sign a tranasaction, for tokens in this wallet to move back into circulation. These are reasonable enough assumptions, and high enough security guarantees,that it can be a practical solution for projects or users wanting deflationary, but importantly immutable, HTS assets.
These community members would also be sophisitcated enough to use different key generation tools, transaction signing tools, SDKs, etc. to ensure that the toolchain is sufficiently diverse as well, to hedge underlying security assumptions/risk.
Implementing in practice
We would coordinate a "burn wallet setup ceremony" in which N appointed community members would have to coordinate the setup of the burn wallet, which is a publicly known wallet on Hedera that has N/N signers, and auto-association turned on. As outlined above, they should use different software toolchains to participate. N would be the maximum size threshold key supported on the network at the time of the setup ceremony. This would be a one time event, lasting maybe an hour or so, which results in the account being created & all N keys attached. After that, the community burn address can be added to public facing documentation and shared broadly. It is a one time setup & after completed, everyone can (& should) intentionally delete their private keys. All it takes is one of the signers being honest and ensuring they are deleted for the setup to work, and this to be a viable proposal.
Pros
Cons
User stories
I, Cooper, hold $CLXY tokens. I want to be able to burn my $CLXY tokens, which are immutable. I cannot right now. Sad. 😞
Specification
hedera.createAccount.addSigner(1).addSigner(2).(...).addSigner(N).sendTx();Backwards compatible
Yes, this is backwards compatible.
Security implications
No, there are no new security implications.
How to teach this
If you send your assets to account
0.0.Xthey will be gone forever! Yay!Reference implementation
Not really relevant here, but you could see Account 0.0.2 & imagine you change the threshold from 1of2, then 14of27, to simply 27/27. Or see the specification section.
Rejected ideas
Alternative ideas
Hedera could make a well known address provide this functionality, i.e. folks can send unlimited fungible & non-fungible assets to it, and have equal guarantees that these funds won't move as any other assets on the network. This again has explicit downsides of a protocol change, which takes more time to implement, and thorough code review than implementing using existing protocol functionality, however they can coexist in the future & neither break any sort of backwards compatability.
Open issues
N/A
References
Copyright
This document is licensed under the Apache License, Version 2.0 -- see LICENSE
or (https://www.apache.org/licenses/LICENSE-2.0)
Beta Was this translation helpful? Give feedback.
All reactions