Groups - Membership Tokens | Ethereum Improvement Proposals

Abstract

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.

Motivation

Many applications need addressable groups of accounts with controlled membership and tiered access:

DAOs: Voting power proportional to token holdings
Loyalty programs: Bronze/Silver/Gold tiers based on token balance
Access control: Different features unlocked at different balance thresholds
Partner networks: Minimum token requirements for partnership benefits

The key insight is that any ERC-20 token can represent group membership:

balanceOf(account) == 0 → Not a member
balanceOf(account) >= threshold → Member at that tier

This approach provides:

Zero implementation overhead: Any ERC-20 token can be a Group
Instant tooling compatibility: Wallets, explorers, DEXs work out of the box
Tiered membership: Different balance thresholds unlock different privileges
Transferable membership: Standard ERC-20 transfers allow membership trading/delegation

Specification

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.

Requirements

A compliant Group contract:

MUST implement ERC-20
MUST implement ERC-165
SHOULD implement the optional interface defined below for membership introspection

Membership Semantics

Token balance represents membership level:

balanceOf(account) == 0 → Account is not a member
balanceOf(account) > 0 → Account is a member
balanceOf(account) >= threshold → Account qualifies for that membership tier

Applications define their own thresholds. For example:

Basic membership: balanceOf(account) >= 1
Silver tier: balanceOf(account) >= 100 * 10**decimals
Gold tier: balanceOf(account) >= 500 * 10**decimals
Platinum tier: balanceOf(account) >= 1000 * 10**decimals

Interface (Optional)

Implementations MAY expose a convenience interface for membership checks:

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.20;

/// @title IERC8063 — Optional membership introspection for ERC-20 tokens
interface IERC8063 {
    /// @notice Returns true if `account` holds at least `threshold` tokens
    /// @param account The address to check
    /// @param threshold Minimum balance required for membership at this tier
    function isMember(address account, uint256 threshold) external view returns (bool);
}

If implemented:

isMember(account, threshold) MUST return true if and only if balanceOf(account) >= threshold.
isMember(account, 0) MUST return true for any account.

ERC-165 Introspection

supportsInterface(0x36372b07) (ERC-20) SHOULD return true
If the optional interface is implemented, supportsInterface for it SHOULD return true

Deployment Model

Following the ERC-20 pattern, each group is its own contract deployment:

Group identity: A group is uniquely identified by its contract address.
Deployment: Deploy any ERC-20 token. The token IS the group.
Discovery: Applications can discover groups through Transfer events, registries, or direct address references.
Naming: name() and symbol() follow standard ERC-20 conventions.

Minting and Burning

Minting and burning are implementation-defined. Groups MAY implement minting/burning using any approach:

Standard mint(address, uint256) function
ERC-5679 compliant mint(address, uint256, bytes)
No minting after initial supply (fixed membership)
Governance-controlled minting
Open minting (anyone can join by minting)

The standard does not mandate any specific minting/burning interface.

Tiered Benefits Example

Applications define membership tiers externally:

// Example: Partner contract checking membership tiers
contract PartnerBenefits {
    IERC20 public membershipToken;
    
    uint256 public constant BRONZE = 100 * 10**18;
    uint256 public constant SILVER = 500 * 10**18;
    uint256 public constant GOLD = 1000 * 10**18;
    
    function getDiscount(address user) external view returns (uint256) {
        uint256 balance = membershipToken.balanceOf(user);
        if (balance >= GOLD) return 30;   // 30% off
        if (balance >= SILVER) return 20; // 20% off
        if (balance >= BRONZE) return 10; // 10% off
        return 0;
    }
    
    function isMember(address user) external view returns (bool) {
        return membershipToken.balanceOf(user) > 0;
    }
}

Optional Extensions

Ownership (via ERC-173)

Implementations that want a single-owner governance model MAY use ERC-173 or ERC-8023 for standardized ownership.

Capped Membership (Balance ≤ 1)

For use cases requiring binary membership (member/non-member with no tiers), implementations MAY enforce balanceOf(account) <= 1 for all accounts.

Rationale

Pure ERC-20: A Group is simply an ERC-20 token with membership semantics. No new token standard needed.
No minting/burning mandate: Different use cases need different minting policies. The standard doesn’t prescribe one.
Threshold-based membership: More flexible than binary membership; supports tiered access, loyalty programs, and proportional voting naturally.
Optional interface: The isMember function is a convenience; applications can directly call balanceOf if preferred.
Maximum compatibility: Any existing ERC-20 token can be interpreted as a Group by applications.

Backwards Compatibility

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 Implementation

Reference contracts are provided in the assets/ directory:

IERC8063.sol — Interface definition
ERC8063.sol — Reference implementation with membership helpers

Security Considerations

Token economics: Membership is tied to token balance. Consider the implications of token transfers, trading, and price volatility on membership.
Threshold manipulation: If thresholds are stored onchain, ensure they cannot be manipulated by unauthorized parties.
Transfer implications: Token transfers change membership. Consider whether this is desirable for your use case.
Approval risks: Standard ERC-20 approval risks apply. Approving another address grants them ability to transfer your membership tokens.
Decimal handling: Ensure thresholds account for the token’s decimals.
Minting security: If minting is permitted, carefully control who can mint to prevent unauthorized membership grants.