ERC Stateful Fungible Token — Discussion Thread

[cc358]

ERC: Stateful Fungible Token

Discussion thread for the draft ERC: Stateful Fungible Token — an ERC-20 extension that maintains a per-holder, on-chain lineage which updates automatically on every transfer.

TL;DR

An ERC-20 extension where each holder carries a weighted set of ancestor addresses representing the historical sources of their current balance. The lineage updates automatically on every non-exempt transfer, preserves full ERC-20 fungibility and backwards compatibility, and exposes a small read-only interface for other contracts to query.

Motivation

ERC-20 (fully fungible, no history) and ERC-721 (full identity, no fungibility) sit at opposite ends of a spectrum. Many on-chain primitives — reputation systems, sybil-resistant airdrops, on-chain social graphs, lineage-gated access control — need both liquidity and provenance. Prior attempts (ERC-1155, ERC-3525, ERC-404) address related concerns but don't introduce per-holder history into fungible balances.

By attaching provenance to the holder rather than the unit, this proposal preserves full ERC-20 fungibility (pools, swaps, accounting all work unchanged) while making a wallet's history a queryable, composable on-chain property.

Key design choices (open for discussion)

1. Per-holder, not per-unit lineage — preserves fungibility, supports any ERC-20 use case.
2. Weighted blend on transfer, not full transfer log — bounded gas cost.
3. Configurable blendRatio, maxLineageDepth, dustThreshold — exposed as view functions; reference impl uses 30% / 64 / 0.1% on Base.
4. Exemption mechanism for AMM routers, vaults, etc. — prevents lineage pollution by intermediary contracts.
5. Pure ERC-20 backwards compatibility — no signature changes, only added view functions and one new event.

Reference implementation

Full Foundry implementation with property-based tests (weight conservation, depth-cap eviction, dust handling, 1-wei sybil resistance) in this repository.

Looking for feedback on

• Is the per-holder-lineage abstraction useful for use cases beyond the ones listed above?
• Should the standard mandate specific parameter values, or keep them implementation-defined?
• Are there additional view functions the standard should require (e.g. firstHeldAt, cumulativeVolume) to better serve sybil-resistance use cases?
• How should the exemption list be governed — immutable-at-deploy, or allow bounded mutation?

ERC PR will be submitted to ethereum/ercs shortly.