This proposal defines a "Group" as an ERC-20 token where token balance represents membership level. Groups are standard ERC-20 tokens with the semantic interpretation that holding tokens means membership in the group. Unlike binary membership, this supports threshold-based membership: holding more tokens grants higher membership tiers or privileges. By being pure ERC-20, Groups inherit full compatibility with existing wallets, explorers, and tooling with no additional implementation burden.
Many applications need addressable groups of accounts with controlled membership and tiered access:
The key insight is that any ERC-20 token can represent group membership:
balanceOf(account) == 0 → Not a memberbalanceOf(account) >= threshold → Member at that tierThis approach provides:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
A compliant Group contract:
Token balance represents membership level:
balanceOf(account) == 0 → Account is not a memberbalanceOf(account) > 0 → Account is a memberbalanceOf(account) >= threshold → Account qualifies for that membership tierApplications define their own thresholds. For example:
balanceOf(account) >= 1balanceOf(account) >= 100 * 10**decimalsbalanceOf(account) >= 500 * 10**decimalsbalanceOf(account) >= 1000 * 10**decimalsImplementations MAY expose a convenience interface for membership checks:
If implemented:
isMember(account, threshold) MUST return true if and only if balanceOf(account) >= threshold.isMember(account, 0) MUST return true for any account.supportsInterface(0x36372b07) (ERC-20) SHOULD return truesupportsInterface for it SHOULD return trueFollowing the ERC-20 pattern, each group is its own contract deployment:
name() and symbol() follow standard ERC-20 conventions.Minting and burning are implementation-defined. Groups MAY implement minting/burning using any approach:
mint(address, uint256) functionmint(address, uint256, bytes)The standard does not mandate any specific minting/burning interface.
Applications define membership tiers externally:
Implementations that want a single-owner governance model MAY use ERC-173 or ERC-8023 for standardized ownership.
For use cases requiring binary membership (member/non-member with no tiers), implementations MAY enforce balanceOf(account) <= 1 for all accounts.
isMember function is a convenience; applications can directly call balanceOf if preferred.This standard is fully backwards compatible with ERC-20. In fact, any existing ERC-20 token can be used as a Group — the standard simply defines how to interpret token balance as membership.
Reference contracts are provided in the assets/ directory:
IERC8063.sol — Interface definitionERC8063.sol — Reference implementation with membership helpersCopyright and related rights waived via CC0.