ERC Non Economic Token Standard

ERCs
,
1

I’m proposing a standard for Non-Economic Tokens (NETs) - fungible tokens designed to resist financialization and speculation.

The goal is to provide a token standard for use cases where traditional ERC-20 tokens create unwanted economic incentives. NETs are designed to be consumed or expire rather than accumulated as assets.

You can find the draft here: Add ERC: Non-Economic Token by sewing848 · Pull Request #1088 · ethereum/ERCs · GitHub

This ERC complements my recently proposed Stateless Encrypted Communication Standard.

A working prototype of a decentralized messaging application has informed the development of these ERCs, as I seek to improve the blockchain-based components of the system. In this particular context, the Non-Economic Token is meant to provide user control over incoming messaging channels, and the Stateless Encrypted Communication contract provides the mechanism for fast, inexpensive, encrypted communication.

The current prototype uses a conventional ERC-20 token for the mechanism that gives users control over incoming messages, but I am in the process of refactoring the code to incorporate this Non-Economic Token standard instead. The app is functional on macOS but not yet production-ready. (More info: https://www.pyrrhoproject.com)

Some of the features of the Non-Economic Token standard include:

  • Built-in decay properties to simulate impermanence and reduce utility as a store of value
  • Naming conventions that explicitly avoid financial semantics
  • Interfaces and contracts without approve() or transferFrom() to prevent decentralized exchange listings
  • Open or permissioned creation and distribution mechanisms not tied to payments or supply limits

While both ERCs are closely related within my project, they address distinct needs - one providing a standard protocol for encrypted communication, and the other a fungible resource that is clearly distinguishable in design, behavior, and intent, from financial blockchain assets. I have therefore created two discussion topics to allow for comments on each one separately.

All feedback and discussion points are welcome. I am particularly interested in thoughts on the decay mechanism implementation, potential circumvention scenarios, and how this might integrate with other applications beyond messaging.

Thanks for your input.

Scott

1 Like
2

I think the same can be achieved by just assigning inflationary properties to ERC20s. This is similar to how governments just increase monetary supply to make it a bad investment and ensure that money is consumed. Decaying properties might require iterating through owners and decreasing balances, or recomputing balances each transfer/balanceOf check, which isn’t efficient. Absence of approve() and transferFrom() might indeed prevent some listings, but it will also prevent “consuming” the tokens, I’m not sure if making it just simply unusable is a way to go when ensuring economic non-viability.