The issuance schedule converges on the 2.1 billion DOT cap along a fixed curve: whatever the protocol burns, the issuance formula mints back, so the burn quietly returns; and if it does not mint back, the cap's math breaks.

One correction (which doesn't make this proposal more or less valuable): this is not how it works today, the issuance curve does not read live total issuance and burn wouldn't be minted back - meaning that a protocol burn could achieve the same net effect of this burn account (I am not saying it's a better or worse approach, just an alternative).

That said, if we go for the approach proposed here with the burn account, a couple of extra tasks an implementation should take into account:

• the DOT in the burn account still counts in the total issuance but should be deactivated (similarly to what we do for DAP buffer) so that they are excluded from active issuance and don't raise the bar for any future referendum to pass
• to make everyone's life easier, we should extend runtime API with a new view function returning the cap, live total issuance, inactive issuance, the permanently frozen balance in the burn account, and maybe the scheduled issuance, so explorers and data providers compute it consistently instead of hardcoding cap and address and we have one single source of truth where to read all issuance-related data.

[UPDATE]: more details / discussions here

Just putting here some extra notes coming from the discussion here.

Today, an explicit extrinsic Balances::burn is not redirected to DAP buffer, so it already reduces TotalIssuance and because the emission curve never reads total issuance there is no re-mint. Since every other sink on the chain (dust, slashes, fees, ...) is routed to the DAP, nothing else moves total issuance either. So a burn that permanently reduces issuance, leaves the schedule untouched and is never minted back is available right now with no code changes. Issuance simply ends up at 2.1B minus whatever is burned.

Before the current discussion in #1926 and #1939, I would have imagined that Balances::burn would have been eventually made configurable to route to DAP (for Polkadot) or to actually burn (for other chains like Kusama), but if now the intention is to actually allow voluntary burns reducing total issuance without re-minting , we are already good with no further changes in code (again, assuming that we are fine with emission curve ignoring live issuance).

#1926 asks for the JAKMB revenue to be burned "automatically and at protocol level, with no discretionary step in between", and one way to get that is one line at the revenue hook of whatever pallet sells JAMKB, dropping the credit rather than depositing it to a given account. There is no need to introduce a burn account to achieve that (Kusama runtime configures slashes, dust, fees, etc to do exactly this - we can do exactly the same on Polkadot for the specific JAMKB case leaving the rest routed to DAP) . This is not a new pattern in the code and doesn't require any new account to be involved.

So to summarize, assuming we are fine with the current emission curve ignoring live total issuance, and the current semantics of Balances::burn, the following would work without the need of a burn account:

• JAMKB revenue: we burn at revenue hook once we implement that. Will be automatic, no discretionary step, will reduce total issuance.
• Voluntary burns: keep using Balances::burn, total issuance decreased, no re-minting because of how issuance curve works

To improve UX / explorers / everyone's life, it would be beneficial to expose a TotalBurned counter or equivalent, together with live issuance, hard cap etc.

Again, this is an alternative to what #1939 suggests if we want to consider that. A burn account where we send automatically JAMKB revenues and where voluntary burns end also achieves a similar result. The main difference is that total issuance would be unchanged, so again to improve UX, we could expose via a single runtime API all info needed at once (live issuance, total burn freezed in the burn account, cap, etc) so e.g. an explorer doesn't have fetch info in multiple places or hard-code anything.

I also believe there is no rush in deciding the strategy now - we will have to be compliant with what #1926 asks but we are not so close to have JAMKB revenue mechanism implemented so we don't have to necessarily agree now on what I believe is mostly an implementation detail at this point.