ERC-8063: Groups - Multi-Member Containers

Abstract

---

This proposal specifies a general-purpose "Group" primitive as a first-class, onchain object. Each group is deployed as its own contract (identified by its contract address) and has an owner, an extensible set of members, and optional metadata. The standard defines a minimal interface for direct member management and membership introspection. Unlike token standards (e.g., ERC-20/ERC-721) that model units of transferable ownership, Groups model multi-party membership and coordination. The goal is to enable interoperable social, organizational, and collaborative primitives.

Motivation

---

Tokens typically model ownership and transfer. Many applications instead need an addressable set of accounts with controlled join/leave semantics and shared state—e.g., project teams, DAOs, game parties, channels, or access cohorts. While ERC-7743 (MO-NFT) explores multi-ownership for a single token, it still anchors the abstraction to token semantics. Groups generalize this into a token-agnostic container where members can be added over time, without implying transfer or unitized ownership. Following the ERC-20 design pattern, each group is its own contract identified by its address. External resources (tokens, NFTs, etc.) can be associated with groups through their own contracts, just as they would with any EOA or contract address.

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.

Contracts that implement this standard MUST support ERC-165.

Interface

Semantics

• Group creation: Upon creation or initialization, the contract MUST set the deployer (or initializer) as the group owner and initial member. Implementations SHOULD accept a name and optional metadataURI.
• Adding members: Only the group owner MAY call addMember. The account MUST NOT already be a member. The implementation MUST add them as a member and emit MemberAdded.
• Leaving: Any member MAY call leaveGroup to voluntarily exit. The implementation MUST remove their membership and emit MemberLeft. The current owner address (i.e., owner() at the time of the call) MUST NOT be allowed to leave.
• Membership transfer: Any member (except the owner) MAY call transferMembership to transfer their membership to a non-member address. The caller MUST lose membership, the recipient MUST become a member, and MembershipTransferred MUST be emitted. Member count remains unchanged.
• Introspection: supportsInterface MUST return true for type(IERC165).interfaceId and for type(IERC8063).interfaceId.

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, just as an ERC-20 token is identified by its contract address.
• Deployment: To create a group, deploy a new contract implementing IERC8063. The deployer becomes the owner and initial member.
• Discovery: Applications can discover groups through events, registries, or direct address references, similar to token discovery patterns.
• Naming: Implementations SHOULD accept a human-readable name in the constructor and expose it via name(). Empty names are permitted.

Optional extensions (non-normative)

• Admin roles: Owner-delegated administrators that can add members.
• Multi-signature member addition: Require multiple approvals before adding members.
• Open groups: Allow anyone to join without owner approval.
• Transferable ownership: Allow the owner to transfer ownership to another member.
• Removal by governance: Implement member removal through voting or consensus mechanisms for specific use cases requiring expulsion.
• Factory contracts: A factory pattern for deploying groups with standardized initialization.
• Resource associations: External contracts (e.g., ERC-20, ERC-721) MAY track group ownership or membership-based access using the group's contract address.

Ownership transfer

Some implementations may need standardized ownership handoff for management tooling (e.g., dashboards). Implementations MAY add an ownership transfer extension with the following interface:

If implemented:

• Only the current owner() MUST be allowed to call transferOwnership.
• The newOwner MUST be a member after the transfer completes. Implementations MAY require isMember(newOwner) == true beforehand, or MAY add newOwner as a member during the transfer.
• The leaveGroup() restriction applies to the current owner() address (i.e., after ownership is transferred, the previous owner is no longer restricted by that rule).

ERC-20 compatibility (decimals=0)

Implementations MAY expose an ERC-20 interface for group membership under the following constraints:

• decimals() MUST return 0.
• balanceOf(account) MUST be either 0 (non-member) or 1 (member).
• totalSupply() MUST equal the current member count.
• transfer(to, amount) MUST require amount == 1 and MUST transfer membership of the caller to to.
• approve(spender, amount) and allowance(owner, spender) MAY be implemented with values clamped to {0,1}; transferFrom(from, to, amount) MUST require amount == 1 and, if permitted, MUST transfer membership from from to to.
• All operations MUST preserve the invariant that no account's balance exceeds 1 and MUST NOT allow the owner account to be transferred.

Reference: see the ERC-20 compatibility implementation in the assets directory.

Motivation (non-normative): exposing a constrained ERC-20 view can improve compatibility with existing tooling that already understands ERC-20 interfaces (e.g., wallet/portfolio displays, accounting/distribution utilities, and governance/gating systems that accept an ERC-20 address as a “membership token”). This mode is OPTIONAL and is intended as an adapter; it does not imply fungible-value semantics.

Rationale

---

• One contract per group: Following the ERC-20 model where each token is its own contract creates a simpler, more composable design. The contract address becomes the natural group identifier.
• Token-agnostic: Separates membership from asset ownership/transfer semantics, suitable for social and coordination use cases.
• Direct member management: Owner can add members directly without invitation/acceptance flow, simplifying the interface and reducing transaction costs.
• Voluntary exit only: Members can leave voluntarily via leaveGroup() or transfer their position, but cannot be forcibly removed by the owner. This prevents centralization and ensures membership stability, similar to how ERC-20 token holders cannot have their tokens revoked.
• Minimal surface: Add members, voluntary leave, membership queries, and transfers are sufficient for broad interoperability while allowing richer policies via extensions.
• Transferable membership: Enables members to delegate or reassign their position without owner intervention, supporting use cases like account migration or role handoffs.
• External resource model: Resources (tokens, NFTs) can be associated with groups externally, just as they would with any address, avoiding tight coupling and enabling flexible composition.
• Relationship to ERC-7743: MO-NFT models multi-ownership of a single token; Groups model multi-membership of a container. Implementations MAY associate a Group with tokens, but the standard does not require token interfaces.

Backwards Compatibility

---

No known backward compatibility issues. This is a new interface with ERC-165 detection.

Reference Implementation

---

Reference contracts are provided in the assets/ directory:

• IERC8063.sol — Interface definition
• ERC8063.sol — Minimal reference implementation

Security Considerations

---

• Membership griefing: Implementations SHOULD bound per-tx iterations and avoid unbounded member enumeration onchain.
• Owner privileges: The owner has unilateral power to add members. Applications relying on group membership SHOULD consider this trust assumption.
• Permanent membership: Members cannot be forcibly removed by the owner, only voluntarily leave or transfer. This design choice prioritizes decentralization but means malicious members cannot be expelled without governance extensions.
• Access control: Clearly document who can add members; the baseline implementation grants this power exclusively to the owner.

Copyright

---

Copyright and related rights waived via CC0.