Proposal: Introduce a Permanent Burn Account for Polkadot

Ecosystem
1

Summary

With the ongoing discussion around Wish For Change #1926, which proposes burning the DOT revenue generated by JAMKB, I would like to propose a way to implement this burn mechanism that better aligns with Polkadot’s long-term monetary model.

Instead of implementing a protocol-level burn that reduces Polkadot’s total issuance, Polkadot should introduce a permanent, cryptographically inaccessible burn account where DOT intended for burning can be sent irreversibly.

Motivation

Under Polkadot’s updated monetary model, the network targets a maximum issuance of approximately 2.1 billion DOT. If protocol-level burns reduce the total issuance, future issuance may compensate for those reductions as the system converges toward its target supply.

As a result, a protocol burn may not produce the intended permanent reduction in the amount of DOT available over the long term.

A permanent burn account avoids this issue.

DOT transferred to this account would:

  • Be permanently removed from circulation.
  • Never be spendable again.
  • Leave the protocol’s total issuance unchanged, avoiding any compensating future issuance.
  • Achieve the same economic objective as a burn while remaining fully compatible with the current monetary policy.

Additional Benefits

Beyond the implementation of Wish For Change #1926, a permanent burn account would provide lasting value to the Polkadot ecosystem.

It would enable:

  • Voluntary burns by any community member.
  • Projects to permanently remove treasury funds or unused allocations.
  • DAOs and parachains to implement transparent burn mechanisms.
  • Community campaigns aimed at reducing the effective circulating supply.
  • A standardized and verifiable destination for all irreversible token removals.

Instead of creating multiple unofficial “burn addresses”, Polkadot would have a single canonical burn account recognized by the protocol and the community.

Technical Considerations

The burn account should be designed so that no valid private key can ever authorize a transaction from it, making any transferred DOT permanently inaccessible.

The exact implementation should be determined by the core developers to ensure that the account is cryptographically impossible to control while remaining publicly verifiable.

Conclusion

Wish For Change #1926 highlights the community’s desire to permanently remove DOT acquired with JAMKB revenue from circulation.

Creating a canonical burn account would achieve this objective without conflicting with the monetary model while also providing a permanent public utility for voluntary burns across the entire ecosystem.

This would be a simple, transparent and future-proof mechanism that could benefit Polkadot long after the implementation of WFC #1926.

2

+1
I would come visit the address on a daily basis.

3

As the author of 1926, I fully endorse this suggestion. I have not fully thought through the technical implementation of such a burn mechanism, but this here seems like a very sensible idea.

4

I nominate my address as the official burn location :smiley:

Assuming we move forward with the JAMKB token, then it makes sense in my mind to place system resource management and procurement on a system chain. Likely an upgrade to the Coretime chain with an update to the pallet_broker.

Polkadot doesn’t have a dedicated burn account, but instead can drop an amount from the available supply.

We don’t have to send burned tokens anywhere. We vaporize them from existence.

6

Using a burning account is the only way to avoid affecting the current emissions reduction mechanism, since it does not change the supply.

Here’s the formula for reference:

per_era_payout = 0.1314 * (cap - issue_at_step) / eras_per_year

7

Ah, I see. So the emission system continues until the total issuance is met. A normal burn drop from available supply would re-emit later?

That would still cap to a maximum supply, but would distribute JAMKB sales to continued block production once the emission rate falls to insignificant amounts, right? How would that play out in 20-30 years when ‘new’ tokens cease to mint?

Personally, I think light pressure to use DOT via translative emission in the long term may be a more sustainable model than expecting value accrual by pure burning. I accept that I’m likely in the minority on that thought, though.

9

One of the advantages of this approach is that exchanges often like to burn tokens, so providing them with a trusted and transparent way to do so would be beneficial for the ecosystem.

I believe the best way to implement this would be through a smart contract on Polkadot Hub, as it offers strong guarantees of immutability and transparency.

10

As we can not burn tokens anymore, providing an account that can be used to make funds unmovable, sounds like a reasonable proposal.

11

As extra note, today burns/slashes/dust removal is all redirected to the DAP buffer (so nothing is really burned post cap hard limit).
Parking in the DAP buffer leaves total issuance unchanged and also deactivates these DOTs (meaning they drop out from active issuance and stop counting for governance for example - which is what we want here as well).

What it doesn’t give us is irreversibility: even if today it’s not possible to move funds out of the DAP buffer without a runtime upgrade, the DAP is about dynamic allocation so the DOTs in the buffer are meant to be eventually re-allocated in the future.

So if we strongly want to keep a segregate address just for this specific JAMKB “burns”, then probably we could add a sub-account in the DAP (the pallet already has subaccounts for staging for different purposes), we could add a distinct address there, still keyless as required, still inside DAP accounting which is probably nice for general accounting/bookkeping, and with no need of extra pallets or smart contracts or so.

I would like to hear also @jonas 's opinion on this whole topic

12

Referendum 1710 put the protocol on a predictable issuance path with a clear cap, and there are two reasons burning any revenue does not fit into the picture.

First, it’s incompatible with 1710 itself. Burning in the naive sense violates inherently what the community decided in that WFC: either we hold the cap and dynamically remint what we burn, which breaks the issuance schedule, or we burn without reminting, which breaks the cap. Neither is acceptable.

Second, and just as important, it doesn’t fit the current plan of using the issuance buffer (DAP) to fund protocol expenses. The declining issuance schedule means the DAP has to start generating revenue to cover its own expenses in the future, with less and less carried by issuance over time. That’s the whole point. Any form of burning works against that, because it would mean that the income stream both from issuance and revenue dries up.

None of this rules out the underlying idea. A mechanism that “freezes” DOT and makes it permanently unusable could be worthwhile, and there may be use cases that benefit from it.

13

I asked @OliverTaleYazde, and he said the best way to do this isn’t with a contract, but with an account that doesn’t have a private key.

14

The decision on whether the revenue generated by JAMKB should be burned or redirected to the DAP is currently being voted on in WFC 1926.

I’m simply providing a solution for a proposal whose objective is to burn tokens. This proposal makes the burn action verifiable; otherwise, it would be more accurate to describe it as simply moving funds into the future.

Furthermore, preventing someone from burning their own tokens takes away their freedom to do whatever they want with them. This does not affect the current mechanism. It would be like claiming that tokens unintentionally lost due to lost private keys also affect the current mechanism. And for precisely that reason, the total supply will never actually reach 2.1 billion tokens.

15

Yeah. We would not do anything different from the runtime side. So, yeah just deciding on what to hash to get the account sounds like a solution. E.g. blake_256("POLKADOT_BURN_ACCOUNT") == 16Xvw6oiEcn1GWAU61WheW3xn6jA4aNQTk1nqpPDPWuwTg4q . Anyone can get this and send there its funds.

17

That sounds good!

18

If anyone would like to present the WFC, please feel free to use the proposal text.
Bastian, since you came up with the technical design, would you be interested in submitting the WFC?

19

Why would we need an extra WFC on top of 1926 though? My 2c is that we should wait for the outcome there. The direction (pre 1926) has been clearly set to redirect any burns to DAP buffer to fund future protocol expenses as a way to compensate declining issuance (as @jonas has mentioned above).
If the same approach is confirmed and 1926 doesn’t pass, then I don’t see by the same principle why we should add a way to burn my own / any tokens rather than redirect to DAP buffer as well.
Technically, adding support for this burn account is trivial, but the main point remains if we should do it - and again, this would be against the general direction we have set so far with DAP and related WFC and referenda.

20

The intention is to present this as a standalone proposal.

While it provides a solution that is useful for WFC 1926, its scope is not limited to that specific use case. Also it is independent of the DAP and introduces a generic mechanism that can be applied in a variety of scenarios, as I mentioned previously.

For example, it could be used by an exchange to burn tokens, or by any individual account or project that needs this functionality.