ERC-8063 그룹 멤버십 토큰 (Groups - Membership Tokens)

Final · 토큰 · 2025-10-28 작성

ERC-20 토큰의 잔액을 그룹 멤버십 수준으로 해석하는 표준입니다. 잔액이 0이면 비구성원, 정해진 임계값 이상이면 해당 등급 구성원으로 보아 기존 토큰 그대로 등급제 멤버십을 만들 수 있습니다.

왜 필요한가

온체인에는 다오(DAO)의 투표권, 등급별 고객 보상, 잔액 기준 기능 잠금 해제, 파트너 혜택처럼 누가 어느 수준의 구성원인지 판별해야 하는 응용이 많습니다. 이를 위해 새 토큰 형식이나 전용 멤버십 컨트랙트를 따로 만들면 지갑과 블록 탐색기 같은 기존 도구가 바로 지원하지 못하고 구현 부담도 생깁니다. 또 구성원 여부를 가입과 비가입 둘로만 나누면 보유량에 따라 혜택을 달리 주는 등급제나 보유량에 비례하는 투표권을 자연스럽게 표현하기 어렵습니다. 이 표준은 이미 어디서나 지원되는 ERC-20 토큰의 잔액을 멤버십 수준으로 해석하는 규칙만 정의합니다. 그래서 추가 구현 없이도 어떤 ERC-20 토큰이든 그룹으로 쓸 수 있고 임계값을 달리 두는 것만으로 여러 등급을 만들 수 있으며 표준 전송으로 멤버십을 거래하거나 넘길 수도 있습니다.

구현해야 하는 것

심층 설명

필수 요건은 ERC-20과 ERC-165 둘뿐입니다

규격을 따르는 그룹 컨트랙트는 ERC-20을 반드시(MUST) 구현하고 ERC-165도 반드시(MUST) 구현해야 합니다. 멤버십 조회용 선택 인터페이스는 구현이 권장(SHOULD)될 뿐 의무가 아닙니다. 새 함수나 저장 구조를 강제하지 않고 표준 ERC-20 토큰에 잔액을 멤버십으로 해석한다는 의미 규칙을 더한 것이 전부이므로, 기존 지갑, 탐색기, 거래 도구와의 호환성을 그대로 물려받습니다.

잔액이 곧 멤버십 수준입니다

balanceOf(account) == 0이면 구성원이 아니고 balanceOf(account) > 0이면 구성원입니다. balanceOf(account) >= threshold이면 그 임계값에 해당하는 등급의 자격을 갖습니다. 임계값은 각 응용이 스스로 정합니다. 원문은 기본 멤버십 1 이상, 실버 100 * 10**decimals 이상, 골드 500 * 10**decimals 이상, 플래티넘 1000 * 10**decimals 이상을 예로 듭니다. 원문의 PartnerBenefits 예제처럼 외부 컨트랙트가 잔액을 읽어 등급별 할인율을 돌려주는 식으로 혜택을 붙일 수 있습니다.

선택 인터페이스 isMember와 ERC-165 조회

선택 인터페이스 IERC8063의 isMember(account, threshold)를 구현한다면 balanceOf(account) >= threshold일 때 그리고 그때만 true를 반환해야 합니다(MUST). isMember(account, 0)은 어떤 계정에 대해서도 true를 반환해야 합니다. ERC-165 조회에서는 ERC-20 식별자인 supportsInterface(0x36372b07)가 true를 반환하는 것이 권장되고(SHOULD) 선택 인터페이스를 구현했다면 그 인터페이스에 대해서도 true 반환이 권장됩니다. isMember는 편의 기능일 뿐이며 응용은 balanceOf를 직접 호출해도 됩니다.

그룹의 정체성과 발견, 하위 호환

그룹은 컨트랙트 주소로 유일하게 식별되며 ERC-20 토큰을 배포하면 그 토큰이 곧 그룹입니다. 응용은 Transfer 이벤트, 레지스트리, 직접 주소 참조로 그룹을 발견할 수 있고 이름과 기호는 표준 ERC-20의 name()과 symbol() 관례를 따릅니다. 이 표준은 ERC-20과 완전히 하위 호환되므로, 이미 배포된 어떤 ERC-20 토큰이라도 응용이 잔액을 멤버십으로 해석하기만 하면 그룹으로 쓸 수 있습니다.

발행과 소각은 구현이 정합니다

발행(민팅)과 소각 방식은 구현에 맡깁니다. 표준 mint(address, uint256) 함수, ERC-5679를 따르는 mint(address, uint256, bytes), 초기 공급 이후 발행이 없는 고정 멤버십, 거버넌스가 통제하는 발행, 누구나 발행해 가입하는 공개 발행 모두 허용됩니다. 표준은 특정 발행·소각 인터페이스를 강제하지 않는데, 사용 사례마다 필요한 발행 정책이 다르기 때문이라고 설명합니다.

선택 확장: 소유권과 이진 멤버십

단일 소유자 거버넌스 모델이 필요한 구현은 ERC-173이나 ERC-8023으로 표준화된 소유권을 쓸 수 있습니다(MAY). 등급 없이 구성원 여부만 가리는 이진 멤버십이 필요하면 모든 계정에 대해 balanceOf(account) <= 1을 강제하는 방식도 허용됩니다. 두 가지 모두 선택 확장이며 규격 준수의 필수 조건이 아닙니다. 이 표준은 상태가 Final로 확정된 제안입니다.

쓸 때 주의할 점

ERC 원문 · ← ERCs