---
eip: 8063
title: Groups - Membership Tokens
description: ERC-20 tokens representing group membership with threshold-based access control.
author: Cheng Qian (@jamesavechives) <contact@deakee.com>
discussions-to: https://ethereum-magicians.org/t/erc-8063-groups-multi-member-onchain-containers-for-shared-resources/25999
status: Final
type: Standards Track
category: ERC
created: 2025-10-28
requires: 20, 165
---

## Abstract

This proposal defines a "Group" as an [ERC-20](./eip-20.md) 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](./eip-20.md)
2. **MUST** implement [ERC-165](./eip-165.md)
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:

```solidity
// 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](./eip-20.md) 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](./eip-5679.md) 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:

```solidity
// 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](./eip-173.md))

Implementations that want a single-owner governance model MAY use [ERC-173](./eip-173.md) or [ERC-8023](./eip-8023.md) 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](./eip-20.md). 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`](../assets/eip-8063/IERC8063.sol) — Interface definition
- [`ERC8063.sol`](../assets/eip-8063/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](../LICENSE.md).