본문으로 건너뛰기

ERC-3643이란 무엇인가요?

업데이트 날짜:
2025년 11월 21일
샤키르 이슬람
전체
이더리움
EVM
RWA
토큰화

읽는 데 10분 소요

개요​

ERC-3643은 허가형 토큰을 위한 이더리움 토큰 표준으로, KYC/AML, 투자자 자격 요건, 관할권 요건 등 미리 정의된 규정 준수 규칙을 충족하는 신원 소유자만이 보유 및 양도할 수 있는 토큰을 의미합니다. 이 표준은 규제 대상 자산에 맞춰 설계되었으며, 이러한 자산의 경우 누가 자산을 보유하고 있는지, 그리고 해당 보유자가 자산을 보유하거나 거래할 권한이 있는지 여부를 반드시 파악해야 합니다.

원래 T-REX(Token for Regulated EXchanges) 로 알려졌으며 Tokeny가 처음 시작한 이 프로젝트는 현재 ERC-3643 로 정식화되었으며, 실물 자산(RWA)에 대한 허가형 토큰화의 표준화를 주된 목표로 하는 ERC-3643 협회가 이를 관리하고 있습니다.

실제로 ERC-3643은 다음과 같은 기능을 통합적으로 구현하는 일련의 스마트 계약입니다:


  • 온체인 신원 및 클레임 (출처: ONCHAINID)
  • 자격 요건을 갖춘 보유자를 위한 신원 등록부
  • 모듈식 규정 준수 규칙
  • 이전 시점에 규정 준수를 강제하면서도 ERC-20 호환성을 유지하는 토큰 계약

ERC-3643은 신원 확인 및 규정 준수 규칙을 토큰 표준에 직접 통합하고 있으므로, 증권, 부동산, 펀드 및 기타 규제 대상 금융상품과 같은 실물자산(RWA)을 토큰화하는 데 탁월한 선택지입니다.

주요 업무​


  • 일반 ERC-20과 비교했을 때 ERC-3643이 어떤 문제를 해결하는지 이해하기
  • 고수준 아키텍처 (핵심 계약, 레지스트리, 역할)를 익히세요
  • 온체인에서 신원 확인 및 규정 준수가 어떻게 적용되는지 확인해 보세요
  • ERC-3643 시스템에서 전송이 어떻게 이루어지는지 단계별로 살펴보겠습니다.
  • 배포, 역할 및 일반적인 RWA 사용 사례에 대한 개요를 확인하세요

준비물​


  • Solidity 에 대한 기본적인 이해와 ERC-20
  • 다음에 대한 이해: EVM에 대한 이해
  • KYC/AML 및 규제 개념에 대한 심도 있는 지식
  • 다음에 대한 인식 EIP-173 (계약 소유권) 및 역할 기반 접근 제어 패턴에 대한 인식
경고

이 가이드에 수록된 코드 예제는 검토를 거치지 않았으며, 오로지 개념을 이해하기 위한 목적으로만 제공됩니다. 철저한 검토, 테스트 및 독립적인 보안 감사를 거치지 않은 상태에서는 실제 운영 환경에서 이 코드 예제를 사용하지 마십시오.

ERC-3643이 해결하는 문제​

본격적으로 들어가기 전에 먼저 배경을 살펴보겠습니다. 표준 ERC-20 토큰은 허가 없이 누구나 사용할 수 있습니다. 누구나 보낼 수 있고, 누구나 받을 수 있으며, 어떤 주소든 보유할 수 있습니다. 이는 다음과 같은 자산의 특징으로, DAI 또는 UNI.

그러나 토큰화된 증권(기업 주식)이나 분할 소유 부동산과 같은 실물 자산을 다룰 때는 문제가 발생합니다. 실물 자산에 적용되는 규정에 따라 자산 보유자를 파악해야 하며, 다음 사항을 근거로 양도를 제한해야 합니다:


  • 신원: 소유자가 KYC 심사를 통과했습니까?
  • 관할권: 수취인이 제재 대상 국가에 거주하고 있습니까?
  • 자격 요건: 해당 보유자는 이 유가증권을 매수할 수 있는 “적격 투자자”에 해당합니까?
  • 락업: 해당 자산이 매각할 수 없는 “락업” 기간에 있습니까?

원래 T-REX(Token for Regulated EXchanges)로 알려졌던 ERC-3643은 이러한 규정을 온체인에 반영하기 위해 개발되었습니다. 이는 ERC-20 호환 토큰이 “규정 준수 기능을 갖도록” 하는 일련의 스마트 계약입니다.

표준 요구 사항​

대략적으로 말하자면, ERC-3643 구현체는 다음을 제공해야 합니다:

  • 호환성 및 표면

    • ERC-20 호환성을 유지합니다
    • 이체에 대한 표준 사전 확인 절차를 마련하십시오 (canTransfer)
    • 규제 대상 흐름에 필요한 일괄 처리 작업 및 관리 기능을 지원합니다.

  • 신원 확인 및 규정 준수

    • 온체인 신원 확인 시스템(예: ONCHAINID)을 통합한다
    • 이체, 발행 및 소각 시 컴플라이언스 레이어를 사용하십시오

  • 조작 및 사용법

    • 일시 중지 및 정지 기능 지원 (전체 정지, 주소 단위 정지, 부분 정지)
    • 민감한 작업(강제 이체, 복구, 발행/소각)에는 EIP-173 소유권과 에이전트 역할을 함께 사용하십시오.

ERC-3643 아키텍처​

ERC-3643은 의도적으로 모듈식 구조를 채택하고 있습니다. 모든 기능을 하나의 거대한 토큰 계약에 통합하는 대신, 여러 계약에 걸쳐 기능을 분산시켜 관리합니다.

한눈에 볼 때, 핵심 구성 요소는 다음과 같습니다:

구성 요소요약
ONCHAINID신뢰할 수 있는 발행자가 발행한, 사용자에 대한 검증 가능한 청구권을 보유하는 별도의 신원 계약(ERC-734/735 기반).
신뢰할 수 있는 발행자 등록부사용자의 신원에 대한 주장을 추가할 수 있도록 신뢰되는 주소 목록(예: KYC 제공업체)
청구 주제 등록부필수 청구 유형 목록 (예: KYC 인증 완료, 공인 투자자).
신원 등록부지갑을 ONCHAINID 및 국가에 매핑하고, 다음과 같은 인증 정보를 노출합니다. isVerified.
준수 계약서이체 전후에 참조되는 제공 및 이체 규칙을 정의합니다.
허가형 토큰 (T-REX)ERC-20 호환 토큰입니다. 이 토큰은 신원 등록소(Identity Registry) 및 규정 준수(Compliance) 계약에 대한 참조 정보를 보유하고 있으며, 양도 시마다 해당 계약들을 참조합니다.

ONCHAINID​

ONCHAINID는 키와 검증 가능한 클레임을 기록하는 범용 신원 계약입니다.

청구항의 예로는 다음과 같은 것들이 있습니다:


  • 주소 X가 제공업체 Y의 KYC 심사를 통과했습니다.
  • 이 투자자는 Z 관할권에서 공인 투자자로 인정받았습니다.

이러한 클레임은 신뢰할 수 있는 발행자(KYC 제공업체나 규제 대상 기관 등)가 발행합니다. 이 계약서는 개인정보(PII)를 직접 저장하지 않고, 개인정보 보호를 위해 참조 정보와 해시값만을 저장합니다.

하나의 기본 신원에 여러 개의 지갑을 연결할 수 있으며, 코드에서는 이 신원을 일반적으로 다음과 같이 참조합니다. 정체성. ONCHAINID는 규정 준수 관련 사실에 대한 근거.

신뢰할 수 있는 발행자 등록부​

‘신뢰할 수 있는 발행자 등록부’는 특정 토큰에 대해 어떤 클레임 발행자가 신뢰 대상인지, 그리고 각 발행자가 어떤 클레임 주제에 대해 서명할 수 있는지를 추적합니다.

예를 들어, 다음과 같은 것을 신뢰할 수 있습니다:


  • ~에 특화된 KYC 서비스 제공업체 KYC_검증됨 주제.
  • 다음에 대한 규제 대상 기관 인증된_투자자.

해당 토큰의 규정 준수 점검에 있어서는 오직 이러한 발행자가 제기한 청구만 유효한 것으로 간주됩니다.

청구 주제 등록부​

청구 항목 레지스트리는 토큰 보유에 있어 중요한 청구 유형을 정의하며, 그 예는 다음과 같습니다:


  • KYC_검증됨
  • 인증된_투자자
  • NOT_IN_RESTRICTED_COUNTRY
  • 제재 대상 목록에 없음

~와 함께 신뢰할 수 있는 발행자 등록부, 이는 다음을 정의합니다 어떤 청구항이 필요한가 그리고 누가 이를 발급할 수 있는가.

신원 등록부​

아이덴티티 레지스트리는 토큰 보유자들을 위한 관문 역할을 합니다:

  • 화이트리스트에 등록된 각 지갑의 ONCHAINID를 저장합니다.
  • 폭로하다 isVerified(주소)
  • 인증된 신원만 등록 상태로 유지되도록 강제합니다

일반적으로 다음을 기반으로 합니다. IdentityRegistryStorage 따라서 여러 토큰이 토큰별 등록 정보를 유지하면서 하나의 화이트리스트를 공유할 수 있습니다. KYC 절차를 마친 후, 투자자는 ONCHAINID를 연결하거나 배포하고, 신뢰할 수 있는 발행자로부터 필요한 클레임을 수령하며, 해당 지갑은 국가 코드(ISO-3166 숫자 형식)로 등록됩니다.

준수 계약서​

준수 계약서에는 공모 규칙 및 양도 제한 사항이 명시되어 있습니다. 예시:


  • 국가별 투자자 최대 인원.
  • 투자자당 최대 포지션 규모.
  • 관할권 허용/거부 목록.
  • 락업 및 베스팅과 같은 기간 기반 규정.

표준 인터페이스 표면:

함수 canTransfercanTransfer (주소 from, 주소 수신지, uint256 amount) external 뷰 반환값 (bool);
함수 transferred(주소 from, 주소 수신지, uint256 amount) external;
함수 생성됨(address to, uint256 금액) external;
함수 파괴됨(주소 from, uint256 금액) external;

토큰 계약은 컴플라이언스 계약을 사용하여 다음을 수행합니다:


  • 이체가 허용되는지 미리 확인하십시오 (canTransfer).
  • 이체, 발행 및 소각이 발생한 후 컴플라이언스 로직에 이를 알리십시오 (이관됨, 생성됨, 파괴된) 이를 통해 내부 상태(대소문자, 카운터 등)를 동기화 상태로 유지할 수 있습니다.

허가형 토큰 (T-REX)​

이 토큰은 표준 ERC-20 기능을 구현하며 다음 항목에 대한 참조를 보유하고 있습니다. IdentityRegistry 그리고 규정 준수 계약. 토큰을 무분별하게 전송하는 대신, 각 전송에 대해 몇 가지 추가 검증을 거쳐 해당 전송이 허용되는지 확인합니다. 이 계약은 전송을 다음과 같이 감싸서 처리합니다:


  1. 일시 정지/정지 확인
  2. 규정 준수 점검
  3. 전송 후 후크 (이관됨)

일반적인 확장자에는 다음이 포함됩니다:


  • 강제 이전 및 토큰 복구
  • 일시 중지/정지 (전역 및 주소별)
  • 부분 동결 (일부 잔액만 이체 가능)
  • 일괄 처리

RWA 토큰 전송 방식​

그럼 이제 ERC-3643 토큰 전송이 어떻게 이루어지는지 단계별로 살펴보겠습니다.

1단계: 사용자가 송금을 요청합니다​

사용자(앨리스)가 토큰의 이체 또는 transferFrom 평소와 같이 토큰을 새 주소(Bob)로 전송하려면 다음과 같이 하세요:

토큰.이체(bob.주소, 금액);
토큰.transferFrom(from, bob.주소, 금액); // 수당이 사용된 경우

2단계: 자격 요건 확인​

그 토큰 이 계약은 토큰을 이동시키지 않습니다. 먼저 다음을 통해 자격 요건 검사를 수행합니다. 신원 등록부. 그 논리는 대개 다음과 같습니다:


  1. 토큰이 일시 중지된 상태인지, 또는 두 주소 중 하나라도 동결된 상태인지 확인합니다.
  2. 수신기가 다음 조건을 충족하는지 확인합니다. 등록됨 그리고 다음의 [ ]에 필요한 청구항을 포함하고 있으며, IdentityRegistry ~를 호출하여 isVerified() 함수

많은 구현에서 토큰은 다음을 호출합니다. identityRegistry.isVerified(...) 직접 호출한 다음 compliance.canTransfer(...). 다른 경우에는 자격 확인 기능이 내부에 통합되어 있습니다. canTransfer 그 자체. 중요한 점은 둘 다 자격 요건 그리고 준수 규정 잔액이 이동하기 전에 적용됩니다.

3단계: 규정 준수 평가​

자격 심사 후, 토큰 계약이 두 번째 확인 단계로 넘어갑니다: compliance.canTransfer(alice.address, bob.address, amount). 그 규정 준수 계약은 모듈식 논리를 확인하여 해당 전송이 허용되는지, 그리고 어떤 규칙도 위반하지 않는지를 판단합니다.

준수 계약에서는 다음 규칙들을 평가할 수 있습니다:

  • 전반적인 상한선 (예: 관할 구역별 보유자 수)
  • 투자자별 및 국가별 포지션 한도
  • 시간대, 매도 제한 기간, 행사 조건
  • 해당 토큰에 대해 구성된 사용자 정의 모듈

어떤 규칙이라도 위반될 경우, canTransfer 반환값 false 그러면 토큰이 원래 상태로 되돌아가야 합니다.

4단계: 전송​

모든 검사가 통과되면, 이 전송은 일반적인 ERC-20 전송과 마찬가지로 실행됩니다. 그런 다음, 토큰 통화 compliance.transferred(from, to, amount) 향후 점검을 위해 규정 준수 상태를 업데이트하기 위해.

민트에서는, 토큰 통화 compliance.created(to, amount), 그리고 실행 시 다음을 호출합니다. compliance.destroyed(from, amount) 따라서 규정 준수 엔진은 공급 현황의 변화도 추적합니다.

감사 가능성

청구서는 신뢰할 수 있는 발행자가 서명하고 ONCHAINID를 통해 저장되므로, 귀하는 자격 요건에 대한 검증 가능한 감사 추적을 유지할 수 있습니다.

다음과 같은 감사 가능한 기록이 있습니다:

  • 누가 언제 무엇을 가지고 있었는가
  • 어떤 청구항과 규칙에 따라 양도가 허용되었는가
  • 등록 기관 및 규정 준수 모듈에 대한 거버넌스 변경 사항의 시간적 추이

역할 및 권한​

ERC-3643은 (EIP-173에 따른) 소유자 ( Owner )와 민감한 기능을 수행할 수 있는 에이전트 (Agent) 주소를 구분합니다. 에이전트 역할은 다음과 같이 표준화되어 있습니다:

interface IAgentRole {
  event AgentAdded(address indexed agent);
  event AgentRemoved(address indexed agent);
  function addAgent(address agent) external;
  function removeAgent(address agent) external;
  function isAgent(address agent) external view returns (bool);
}

소유자는 에이전트와 상위 수준 구성을 관리합니다. 에이전트는 구현 방식에 따라 동결, 강제 이체, 발행/소각, 일괄 처리 등의 작업을 수행합니다.

개발자를 위한 핵심 인터페이스​

ERC-3643 구현을 통해 드러난 주요 표준화된 인터페이스:

interface IERC3643 is IERC20 {
  // getters
  function onchainID() external view returns (address);
  function identityRegistry() external view returns (IIdentityRegistry);
  function compliance() external view returns (ICompliance);
  function paused() external view returns (bool);
  function isFrozen(address user) external view returns (bool);
  function getFrozenTokens(address user) external view returns (uint256);

  // admin
  function pause() external;
  function unpause() external;
  function setAddressFrozen(address user, bool freeze) external;
  function freezePartialTokens(address user, uint256 amount) external;
  function unfreezePartialTokens(address user, uint256 amount) external;
  function setIdentityRegistry(address identityRegistry) external;
  function setCompliance(address compliance) external;

  // lifecycle
  function forcedTransfer(address from, address to, uint256 amount) external returns (bool);
  function mint(address to, uint256 amount) external;
  function burn(address user, uint256 amount) external;
  function recoveryAddress(address lostWallet, address newWallet, address investorOnchainID) external returns (bool);

  // batch helpers
  function batchTransfer(address[] calldata toList, uint256[] calldata amounts) external;
}

디자인 요약​

ERC-3643 토큰 배포에는 최소한 다음이 포함됩니다:


  • 레지스트리 배포: 청구항 주제 등록부, 신뢰할 수 있는 발행자 등록부, IdentityRegistryStorage, IdentityRegistry.
  • 토픽 및 발행자 구성: 클레임 토픽과 신뢰할 수 있는 발행자를 해당 토픽과 함께 추가합니다.
  • 저장소를 ID 레지스트리에 바인딩하고, ID 레지스트리에 레지스트리를 설정합니다.
  • 배포 규정 준수 배포가 완료되면 이를 토큰에 바인딩합니다.
  • 다음에 대한 참조를 포함하여 토큰을 배포하십시오. IdentityRegistry 그리고 규정 준수.
  • ‘소유자’ 및 ‘대리인’ 역할을 설정하고, 민감한 기능에 대한 접근 권한을 대리인으로 제한하십시오.
  • 투자자 신원 등록 (주소, ONCHAINID, 국가) 신원 등록부에.
  • 사용법 민트 공급을 배분하고 발행/소각 결정을 보장하기 위해 생성/삭제.

일반적인 사용 사례​


  • 토큰화된 사모펀드 / 벤처캐피털(VC) / 사모펀드(PE): 인증 투자자 또는 기관 투자자로만 제한
  • 보안 토큰 공개(STO): 관할권 제한, 최대 보유자 수, 락업 기간 등을 적용합니다.
  • 토큰화된 부동산: 자격을 갖춘 투자자만이 부동산의 지분을 보유할 수 있도록 보장
  • 규제 대상 거래소: 모든 매수 및 매도 주문이 온체인에서 검증되는 규정 준수 2차 시장을 구축합니다

ERC-3643 토큰은 ERC-20 호환성을 유지하기 때문에, 해당 플랫폼이 자산의 허가형 특성을 처리할 준비가 되어 있는 한(예: 규정 준수로 인한 전송 취소 처리 등), 지갑, 수탁 업체, 거래소(허용되는 경우 중앙화 또는 탈중앙화 거래소 모두 포함) 및 포트폴리오·분석 도구와 연동될 수 있습니다.

다음은 무엇일까요?​

여기에서 다음을 수행할 수 있습니다:

  • ERC-3643 백서 및 사양 전문을 읽어보세요

    이 개요에서 다루지 않은 ‘배송 대 배송(DvD)’, 거래소 연동, 업그레이드 가능성 패턴과 같은 특수한 사례에 대해 자세히 알아보세요.

  • 참조 구현을 살펴보세요

    ERC-3643 / T-REX 저장소를 클론하고, 레지스트리와 토큰을 로컬 또는 테스트넷 환경에 배포한 다음, 규정을 준수하는 전송과 준수하지 않는 전송을 비교해 보세요.

  • 간단한 RWA 사용 사례의 프로토타입 제작

    예를 들어:

    • 특정 관할권의 적격 투자자만 토큰을 보유할 수 있는 토큰화된 사모 펀드
    • 락업 기간과 양도 가능 기간이 설정된 토큰화된 부동산 자산

    ERC-3643을 사용하여 해당 규칙을 토큰에 직접 인코딩하십시오.

  • 모니터링 및 규정 준수 도구 구축

    Quicknode Streams를 사용하여 다음을 구독하세요:

    • 이체 ERC-3643 토큰의 이벤트
    • 컴플라이언스 모듈의 사용자 정의 이벤트(예: 규정 위반, 강제 이관)
      그런 다음 해당 데이터를 대시보드, 알림 시스템 또는 내부 컴플라이언스 도구에 반영합니다.

다음 단계들을 살펴보시면, ERC-3643이 여러분의 RWA 또는 보안 토큰 로드맵에 어떻게 부합하는지 훨씬 더 명확하게 파악하실 수 있을 것입니다.

결론​

이 가이드에서는 ERC-3643이 익숙한 ERC-20 모델 위에 온체인 신원 정보, 적격성 확인 및 모듈식 규정 준수 규칙을 어떻게 적용하여 규제 대상인 허가형 자산을 지원하는지 알아보았습니다.

이더리움이나 기타 EVM 체인에서 RWA 또는 보안 토큰 인프라를 구축하고 있다면, ERC-3643을 통해 규정 준수를 처음부터 새로 구축할 필요 없이 오픈소스 기반(T-REX)을 활용할 수 있습니다. Quicknode의 신뢰할 수 있는 인프라와 결합하면, 실제 규제 프레임워크에 부합하는 허가형 토큰을 설계, 배포 및 모니터링할 수 있습니다.

더 많은 기사와 가이드를 받아보시려면 뉴스레터를 구독해 주세요. 트위터를 통해 의견을 보내주시거나 디스코드 커뮤니티 서버에 가입해 주세요.

여러분의 피드백을 ❤️ 환영합니다!

의견이나 다루었으면 하는 새로운 주제가 있다면 알려주세요. 여러분의 의견을 기다리고 있습니다.

최종 업데이트 ~에
이 가이드를 공유하세요