Add ERC-8098: Non-increasing supply ERC-20

[ten-io-meta]

This proposal introduces ERC-8098, an ERC-20 behavioral profile with a strictly non-increasing total supply.

A conformant implementation:

• cannot increase totalSupply() after deployment,
• permanently removes burned units,
• exposes a single canonical ERC-20 balance and supply state,
• and cannot use upgrades, privileged roles, or internal alternate accounting mechanisms to reintroduce supply-increasing behavior.

ERC-8098 does not introduce a new token interface. It standardizes observable supply invariants on top of ERC-20 compatibility so that auditors, integrators, and applications can reason consistently about irreversible supply semantics.

External wrappers, third-party representations, and application-layer abstractions are explicitly out of scope.

Discussion thread (Ethereum Magicians):
https://ethereum-magicians.org/t/erc-8098-zw-token-irreversible-supply-erc-20/26685

[eip-review-bot]

File erc-8098.md

Requires 2 more reviews from Editors: @g11tech, @jochem-brouwer, @lightclient, @samwilsn, @xinbenlv

[ten-io-meta]

Thanks everyone for the previous guidance — especially @abcoathup.

As suggested, the earlier PR was closed and the proposal has now been correctly submitted to the ERCs repository.

This PR (#1390) contains the cleaned-up ERC draft, aligned with the required format and category, and it now links to the updated discussion thread on Ethereum Magicians:

🔗 https://ethereum-magicians.org/t/erc-9999-zw-token-irreversible-supply-erc-20/26685

I’ll continue refining the draft based on any feedback from reviewers.
Thanks for your time and support.

[abcoathup]

@ten-io-meta please note, ERCs are not for marketing or promotional purposes.
Recommend removing any brand specific names and only use generic terms in the ERC. (Note: I am not an editor).

[ten-io-meta]

Thanks @abcoathup — all suggested changes have now been applied.

The ERC number, filename and discussion link are updated, and the draft follows the required neutral format.

Let me know if anything else is needed. I appreciate the guidance.

[ten-io-meta]

Hi all,

Just a quick note to mention that the draft has been updated to address the previous feedback and is now aligned with the required neutral ERC format.

There are no open questions on my side at this point.
Happy to make any further adjustments if reviewers have additional comments.

Thanks for your time.

[SamWilsn]

Woops, sorry, forgot to rename the file for you.

[github-actions]

The commit 9014fe6 (as a parent of 4e44ee6) contains errors.
Please inspect the Run Summary for details.

[ten-io-meta]

Hi @SamWilsn,

Thanks again for your earlier feedback.

All requested changes have now been addressed:

• clarified terminology in the abstract
• added high-level technical explanation
• refined motivation and rationale sections
• clarified scope of internal vs external representations
• aligned wording with EIP editorial standards

Could you please take another look when convenient?

Thank you for your time.

[ten-io-meta]

Hi @SamWilsn,

Thank you again for the previous review and feedback.

After revisiting the proposal, I believe the central question is not whether ERC-8098 introduces a new ERC-20 interface.

It does not.

The question is whether irreversibility itself is a property that external systems may safely rely upon.

ERC-8098 attempts to standardize a behavioral invariant:

Burned supply can never be restored.

The value of this invariant is not primarily for wallets or end users. It is for third-party systems that must determine whether supply reduction is reversible or irreversible.

Without a standard, every integration must independently analyze token logic, governance controls, upgrade paths, and mint authorities to determine whether a burn is truly final.

With a standard, external systems can treat irreversibility as a declared and verifiable property rather than a token-by-token audit exercise.

In that sense, the proposal is less about introducing new ERC-20 methods and more about standardizing a property that external systems may choose to rely upon.

The key question becomes:

Is irreversibility a sufficiently useful interoperable property to justify standardization?

I believe that is the core claim ERC-8098 is attempting to make, and I would appreciate your thoughts on that specific point.

Thank you for your time.

[ten-io-meta]

Hi @SamWilsn,

I revisited ERC-8098 again with your earlier review and, in particular, your concern about whether a proposal that introduces no new interface belongs as an ERC.

The current draft has now been narrowed further:

the prescribed burn function signature has been removed,
burn requirements are defined purely as behavioral invariants,
the optional privacy layer has been removed,
the motivation now focuses on supply guarantees that ERC-20 itself does not specify,
external wrappers and third-party representations are explicitly out of scope,
and upgradeability is constrained so that an implementation capable of introducing future supply increases is not conformant.

All of the specific points from your previous review have been addressed in the current draft.

When convenient, could you please take another look? I would especially appreciate your view on whether this narrower framing — a standardized, externally reviewable ERC-20 supply invariant rather than a new interface — addresses your earlier concern.

Thank you again for your time and feedback.