ERC-8063: Groups - Membership Tokens

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:

1. MUST implement ERC-20
2. MUST implement ERC-165
3. 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:

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:

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.

Copyright

---

Copyright and related rights waived via CC0.