ERC-8063 Group membership token (Groups - Membership Tokens)
Final · Tokens · created 2025-10-28
A standard that interprets an ERC-20 token's balance as a group membership level. A balance of zero means non-member, and a balance at or above a set threshold means membership at that tier, allowing tiered membership to be built on top of an existing token as is.
Why it is needed
On-chain there are many applications, such as DAO voting rights, tiered customer rewards, balance-based feature unlocks, and partner benefits, that need to determine who is a member at what level. Building a separate new token format or dedicated membership contract for this means existing tools like wallets and block explorers cannot support it right away, creating an implementation burden. Also, if membership is split only into member and non-member, it is hard to naturally express tiered benefits that vary with holdings or voting power proportional to holdings. This standard defines only the rule for interpreting the balance of an already universally supported ERC-20 token as a membership level. As a result, any ERC-20 token can be used as a group without additional implementation, multiple tiers can be created simply by setting different thresholds, and membership can be traded or transferred via standard transfers.
What to implement
function isMember(address account, uint256 threshold) external view returns (bool);: Returns true if an account's token balance is at or above the threshold. It is an optional convenience function for checking eligibility for a specific tier at once.
In depth
The only required requirements are ERC-20 and ERC-165
A compliant group contract MUST implement ERC-20 and MUST also implement ERC-165. The optional interface for membership lookup is only RECOMMENDED (SHOULD) to implement, not required. Since it does not mandate any new functions or storage structures but only adds a semantic rule interpreting balance as membership on top of a standard ERC-20 token, it fully inherits compatibility with existing wallets, explorers, and trading tools.
Balance is itself the membership level
If balanceOf(account) == 0, the account is not a member; if balanceOf(account) > 0, it is a member. If balanceOf(account) >= threshold, it qualifies for the tier corresponding to that threshold. Each application sets its own thresholds. The source text gives as examples a base membership of at least 1, silver at least 100 * 10**decimals, gold at least 500 * 10**decimals, and platinum at least 1000 * 10**decimals. As in the source's PartnerBenefits example, an external contract can attach benefits by reading the balance and returning a tier-based discount rate.
The optional isMember interface and ERC-165 lookup
If the optional interface IERC8063's isMember(account, threshold) is implemented, it MUST return true if and only if balanceOf(account) >= threshold. isMember(account, 0) MUST return true for any account. For ERC-165 lookups, it is RECOMMENDED (SHOULD) that supportsInterface(0x36372b07), the ERC-20 identifier, return true, and if the optional interface is implemented, it is also RECOMMENDED that it return true for that interface. isMember is merely a convenience, and applications may call balanceOf directly instead.
Group identity, discovery, and backwards compatibility
A group is uniquely identified by its contract address, and once an ERC-20 token is deployed, that token is itself the group. Applications can discover groups via Transfer events, registries, or direct address references, and names and symbols follow the standard ERC-20 conventions of name() and symbol(). This standard is fully backwards compatible with ERC-20, so any already-deployed ERC-20 token can be used as a group simply by having an application interpret its balance as membership.
Minting and burning are left to the implementation
Minting and burning methods are left to the implementation. A standard mint(address, uint256) function, a mint(address, uint256, bytes) following ERC-5679, fixed membership with no further minting after initial supply, governance-controlled minting, and open minting where anyone can mint to join are all permitted. The standard does not mandate a specific minting or burning interface, explaining that the required issuance policy differs by use case.
Optional extensions: ownership and binary membership
Implementations requiring a single-owner governance model MAY use ownership standardized by ERC-173 or ERC-8023. If binary membership distinguishing only member versus non-member without tiers is needed, enforcing balanceOf(account) <= 1 for all accounts is also permitted. Both are optional extensions and are not required conditions for spec compliance. This standard is a proposal whose status has been finalized as Final.
Things to watch out for
- Token economics and the impact of transfers: Since membership is tied to token balance, the effects of token transfers, trading, and price fluctuations on membership must be considered. Sending the token also changes membership, so whether this is desirable for the given use case must be examined.
- Approval risk: The approval risk of standard ERC-20 applies as-is. Approving another address allows that address to move your membership tokens.
- Minting control: In implementations that allow minting, who is permitted to mint must be carefully controlled to prevent membership from being granted without authorization.
- Threshold manipulation: If tier thresholds are stored on-chain, it must be ensured that unauthorized parties cannot manipulate the values.
- Handling decimal places: When setting thresholds, it must be confirmed that the token's decimals have been properly accounted for.