시큐리타이즈는 현 $3B 이상의 자산을 토큰화하며 TVL 측면에서 RWA 토큰화 프로토콜 중 독보적인 선두주자이며, 블랙록 BUIDL, 반에크 VBILL 등을 토큰화한 것으로 커뮤니티 내에 잘 알려져있다.
RWA를 토큰화할 때 현실 세계에서의 법적 구조를 설계하는 것 만큼이나, 온체인상에서의 디지털 증권의 스마트 컨트랙트 구조를 설계하는 것이 굉장히 중요하다. 디지털 증권도 증권인 만큼, 온체인 상에서 발행사가 설정한 규칙과 국가의 규제를 준수하며 거래되어야하기 때문이다.
시큐리타이즈는 자회사를 통해 SEC에 정식 등록된 transfer agent이자, SEC 및 FINRA에 등록된 broker-dealer이며, 펀드 어드민(fund administrator)이고, 동시에 SEC 규제를 받는 ATS 플랫폼 운영권을 확보했다. 이는 시큐리타이즈가 블록체인 상에서 디지털 증권을 규제에 맞게 발행·관리하고, 거래 및 유통까지 지원할 수 있는 법적 기반이 된다. 시큐리타이즈는 비슷한 라이센스를 EU에서도 가지고 있으며, 이는 미국 및 EU에서 규제를 준수하며 토큰의 발행, 유통을 담당할 수 있는 유일한 플랫폼이다.
시큐리타이즈의 기술적 뼈대는 DS 프로토콜이다. DS 프로토콜은 DS 토큰, DS 서비스(트러스트 서비스, 레지스트리 서비스, 컴플라이언스 서비스), DS 앱을 통해 디지털 증권을 규제를 준수하면서도 개방형 생태계에서 거래할 수 있도록 한다.
본 글은 DS 프로토콜이 실제로 어떻게 구현되어있는지 BUIDL의 사례를 통해 알아보며, 시큐리타이즈가 기술적으로 어떻게 작동하는지 완전 분석해본다. 코드를 잘 모르는 사람도 해당 글을 통해 시큐리타이즈의 기술적 구조에 대해 파악하는 것을 목표로 한다.
트럼프 정부 이후로 블록체인 산업에 대한 규제들이 빠르게 명확해져가고 있고, 이에 따라 수 많은 기업들과 금융기관들이 블록체인에 관심을 가지고 있다. 특히 스테이블코인을 비롯한 RWA는 실물 자산을 온체인의 장점과 결합하여 전통 금융 시스템과 비교하여 더 높은 효율성, 접근성을 살릴 수 있음에 따라, 현재 가장 많은 관심을 받고 있고, 빠르게 성장하고 있는 분야 중 하나이다.
스테이블코인을 제외하여도 RWA 시장의 성장은 가속화되고 있다. 가장 큰 비중을 차지하고 있는 자산은 프라이빗 크레딧이며, 이를 이어 미국 채권이 두 번째로 큰 비중을 차지하고 있다. RWA에는 프라이빗 크레딧, 미국 채권 이외에도 기관 펀드, 주식, 기업채 등 다양한 종류의 자산들이 있다.
토큰화할 수 있는 자산이 다양한 만큼, 자산들을 토큰화하는 프로토콜들도 다양한데, RWA 시장에서 독보적 1위를 차지하고 있는 프로토콜이 있다. 바로 시큐리타이즈(Securitize)이다.
Source: Securitize
일반 투자자들에게 시큐리타이즈는 블랙록의 BUIDL 펀드를 토큰화한 프로토콜로 잘 알려져 있을 것이다. 시큐리타이즈는 RWA 시장에서 대표적인 토큰화 프로토콜로 채권, 프라이빗 크레딧, 재보험, VC 펀드 등 다양한 자산을 온체인에 토큰화하는 서비스를 제공한다. 시큐리타이즈는 SEC에 정식 등록된 Transfer Agent이며, SEC 및 FINRA에 등록된 Broker-Dealer이고, 동시에 ATS 플랫폼 운영권을 확보했기 대문에 증권형 토큰의 발행, 거래가 모두 가능하다.
이는 시큐리타이즈가 미국에서 규제를 준수하며 디지털 증권의 완전한 라이프사이클을 수행할 수 있는 법적 기반을 마련한다. 미국에서 다양한 종류의 RWA를 규제를 준수하며 발행부터 유통까지 완전한 라이프사이클을 처리할 수 있는 토큰화 플랫폼은 시큐리타이즈가 유일하다.
시큐리타이즈는 기술적/규제적 강점을 갖춘 미국 내 유일한 토큰화 플랫폼이기에, 이는 수 많은 기관들의 선택을 받았으며, 블랙록과의 협업이 가장 대표적인 사례이다. 블랙록은 첫 번째 토큰화 펀드인 BUIDL의 발행, 관리, 거래를 위해 시큐리타이즈와 파트너십을 맺었다는 점에서 상징성이 매우 크다. 특히, 블랙록은 단순히 시큐리타이즈를 통해 디지털 증권을 발행하는 것 뿐만 아니라 2024년 5월 시큐리타이즈에 $47M이라는 어마어마한 규모를 투자하며, 시큐리타이즈와의 파트너십 강화를 공고히 했다.
Source: rwa.xyz
시큐리타이즈는 단연코 RWA 시장의 선두주자라고 할 수 있는데, 무려 $3.1B 규모의 자산을 토큰화하여 20%에 가까운 마켓쉐어를 가지고 있다. 대표적인 RWA 상품으로는 BlackRock USD Institutional Digital Liquidity Fund (BUIDL), VanEck Treasury Fund (VBILL), Blockchain Capital III Digital Liquid Venture Fund (BCAP), Mantl Index Four Fund (MI4) 등이 있다.
재미있는 것은 이 서로 다른 종류의 모든 RWA 토큰들이 시큐리타이즈의 DS 프로토콜을 통해 토큰화되었다는 것이다. 토큰화를 위해선 1) 현실 세계에서 법적 구조를 어떻게 설계할지와 2) 온체인에서 스마트 컨트랙트 구조를 어떻게 설계할지가 모두 중요한데, 이번 글에선 2번에 대해 자세히 살펴볼 것이다.
디지털 증권 토큰은 일반 토큰과 다르게 규제 준수를 위한 여러 장치가 필요하다. 예를 들어 BUIDL의 발행과 전송은 KYC가 완료된 Qualified Purchaser만 가능하다. 따라서 증권 토큰은 일반 토큰과 같이 아무렇게나 발행하지 못하며, 발행사(issuer), 투자자(investor), 거래소(exchange)가 규제를 준수하면서 발행, 투자, 거래지원할 수 있도록 하는 것이 중요하다. 이것이 시큐리타이즈 DS 프로토콜의 역할이다.
DS 프로토콜은 디지털 증권의 전체 생애 주기를 관리할 수 있는 툴을 발행사에게 제공하며, 발행사, 투자자, 거래소를 위한 스마트 컨트랙트 인프라를 제공한다. 이는 발행뿐만 아니라, 그 이후의 배당금 지급, 의결권 행사, 양도, 거래 등 모든 행위를 포괄한다.
DS 프로토콜의 주요 구성 요소는 아래와 같다:
DS 토큰: ERC-20 호환 토큰으로, ERC-20의 기본 기능들뿐만 아니라 증권형 토큰에 필요한 다양한 확장 기능들이 추가되어있다. BUIDL, VBILL 같은 토큰들이 전부 DS 토큰이다.
DS 앱: 디지털 증권 토큰의 생애 주기에서 발행, 거래 지원, 의결권 행사, 배당금 지급 등 다양한 이벤트를 담당하는 앱이다.
DS 서비스: DS 토큰 및 DS 앱이 작동하기 위한 기반 인프라로, 트러스트 서비스, 레지스트리 서비스, 컴플라이언스 서비스로 구성된다.
이외에도 DS 프로토콜은 거래소와의 연동을 용이하게 하는 오프체인 RFE(Ready For Exchange) API나 시큐리타이즈 자체 발행 플랫폼인 DS Issuing Platform을 제공한다.
DS 프로토콜은 DS 토큰 및 DS 서비스를 통해 발행사, 투자자, 거래소가 규제를 준수하면서 디지털 증권을 다룰 수 있도록 한다. 이를 이해하기 위해선 먼저 전체적인 그림을 이해하고 세부 요소를 살펴보는 것이 도움이된다.
DS 토큰은 일반 ERC-20 토큰의 기능이 확장되었다고 이해하면 쉽다. DS 토큰은 아무한테나 아무 조건 없이 전송되면 안되고, 발행사의 따라서 전송 기능에 DS 서비스 중 하나인 컴플라이언스 서비스가 개입한다. DS 토큰은 전송이 이루어질 때 컴플라이언스 서비스를 통해 아래와 같은 사항들을 확인한다:
이 거래가 규제에 맞는지?
받는 사람이 허용된 투자자인지?
전송 금액이 제한을 초과하는지?
발행사가 특정 지갑에 토큰을 발행해줄 때에도 컴플라이언스 서비스를 통해 적격 여부를 확인하며, 단순 발행에 더해 베스팅 조건을 부과하거나, 투자자의 토큰을 소각하거나, 강제 회수할 수 있는 고급 기능이 제공된다.
그렇다면 특정 지갑이 발행사인지, 투자자인지, 거래소인지 어떻게 구분할까? 이는 DS 서비스의 트러스트 서비스가 담당한다. 트러스트 서비스는 특정 지갑 주소가 어떤 역할을 가지는지 관리하는 권한 관리자의 역할을 한다.
DS 토큰을 보유할 수 있는 투자자 명단은 어떻게 관리할까? 이는 DS 서비스의 레지스트리 서비스가 담당한다. 레지스트리 서비스는 지갑 주소에 해당하는 투자자 속성 정보를 저장한다. 이는 국적, 적격 투자자 여부, 투자자 ID 등을 포함한다.
위의 요소들을 하나씩 살펴보며 BUIDL과 같은 토큰들이 실제로 온체인에서 어떻게 작동하는지 살펴보자. 참고로 코드가 좀 등장할텐데, 아래 글을 천천히 읽으며 따라온다면 이해하는데 큰 무리가 없을 것이다.
DS 토큰의 핵심 기능들은 어떻게 구현되어있을까?
2.4.1 전송 가능 여부
첫 번째로 적격 지갑간의 전송이다. DS 토큰은 transfer() 혹은 transferFrom() 이 실행되기 전에 컴플라이언스 서비스에 토큰의 전송이 규제 기준을 만족하는지 체크한다.
DS 토큰에는 canTransfer 라는 모디파이어(modifier)가 존재하는데, 이는 모든 토큰 전송 시마다 아래에서 살펴볼 컴플라이언스 서비스의 validateTransfer() 를 실행하여 전송 가능 여부를 검사한다.
만약 적격하지 않을 경우 트랜잭션이 실패하는데, 이는 가스비를 낭비할 수 있기 때문에, DS 토큰과 컴플라이언스는 전송 전에 미리 가능 여부를 확인할 수 있는 preTransferCheck() 기능을 제공하기도 한다. 이 또한 아래 컴플라이언스 서비스에서 자세히 살펴보자.
2.4.2 발행
DS 토큰의 발행에는 크게 세 가지 주요 함수가 있다. 아래 기능을 통해 적격 지갑에 베스팅같은 기능까지 자동화하여 토큰을 발행할 수 있다.
issueTokens(address _to, uint256 _value) : 특정 지갑에 새 토큰을 발행해주는 기능이다.
issueTokenWithLocking(address _to, uint256 _value, uint256 _valueLocked, string _reason, uint64 _releaseTime) : 특정 지갑에 새 토큰을 발행하는 것 뿐만 아니라 토큰을 잠금할 수량과 잠금 해제 시각을 함께 입력함으로써 베스팅을 구현할 수 있다.
totalIssued() : 지금까지 발행된 토큰의 총량을 확인한다.
2.4.3 지갑 주소 확인
보통 ERC-20 토큰은 어떤 지갑이 토큰을 얼마나 가지고 있는지 전체 목록을 직접 뽑아내는 기능이 없다. 즉, 특정 지갑 잔액을 확인할 수 있지만, 모든 지갑 주소를 한 번에 가져오는 것은 불가능하다. DS 토큰은 아래와 같은 함수를 추가하여 이를 가능케 한다:
getWalletAt(uint256 _index) : 보유자 목록에서 특정 위치에 있는 지갑 주소를 반환한다.
walletCount() : DS 토큰을 보유하고 있는 지갑 개수를 반환한다.
지갑 주소를 쉽게 불러올 수 있는 기능은 배당금 지급이나 규제 준수를 위한 감사, 보고를 용이하게 할 수 있다.
2.4.4 투자자 전용 함수(Investor-centric Management Functions)
디지털 증권의 경우 법규 때문에 투자자의 수를 기준으로 보유자 목록을 관리해야하는 경우가 많다. 예를 들어 특정 규제에서는 한 발행사가 최대 200명의 투자자만 가질 수 있도록 강제할 수 있다. 하지만 블록체인의 경우 한 투자자가 여러 개의 지갑을 보유할 수 있는데, 만약 이 지갑이 모두 투자자 수로 집계될 경우 규제를 위반하는 것처럼 보일 수 있다. 따라서 특정 투자자가 어떤 지갑들을 보유하고 있는지는 DS 서비스 중 레지스트리 서비스가 관리하며, DS 토큰 컨트랙트에서는 특정 투자자가 얼만큼의 DS 토큰을 보유하고 있는지 확인할 수 있는 함수를 제공한다:
balanceOfInvestor(string _id) : 투자자 ID로 전체 보유 토큰 수를 조회할 수 있다. 이는 투자자가 가진 모든 지갑의 잔액을 합산하여 보여준다.
2.4.5 발행사 고유 함수(Issuer Control Functions)
트러스트 서비스에 의해 발행사 역할이 부여된 지갑 주소는 아래와 같은 함수들을 추가로 활용할 수 있다:
burn(address _who, uint256 _value, string _reason) : 특정 지갑이 보유하고 있는 토큰을 소각한다. 이는 자사주 매입 같은 개념에 활용할 수 있다.
seize(address _from, address _to, uint256 _value, string _reason) : 특정 지갑이 보유하고 있는 토큰을 다른 지갑으로 강제 이전한다. 이는 투자자가 만약 지갑에 대한 접근 권한을 잃어버린 경우, 강제로 회수하여 새 지갑에 재발행해줄 수 있다.
isPaused() : 토큰 전송의 일시정지 여부를 확인하는 함수이다. 참고로 발행사는 규제 위반 의심 상황, 시스템 보안 사고, 법적 명령 시 DS 토큰의 전송을 전면 중지시킬 수 있다.
트러스트 서비스는 DS 프로토콜 내에 어떤 지갑들이 어떤 역할을 가지는지 관리하는 스마트 컨트랙트이다. 역할의 종류로는 None, Master, Issuer, Exchange 총 4개가 존재하며, 이는 온체인에서 각각 0, 1, 2, 4라는 정수 값으로 표현된다.
트러스트 서비스에서 지갑 주소에 역할을 할당하는 함수는 setRole() 으로, 지갑 주소와, 역할 종류에 맞는 정수를 입력 받아 특정 지갑 주소의 역할을 정의한다. 예를 들어 발행사가 0x123... 의 주소에 거래소(exchange) 역할을 부여하고 싶다면, 발행사는 트러스트 서비스에 setRole(0x123..., 4) 를 호출하면된다.
레지스트리 서비스는 DS 토큰을 보유할 수 있는 투자자 명단을 블록체인에 기록하는 역할을 한다. 이는 투자자 명단 뿐만 아니라 투자자의 속성까지 기록하는데, 이름, 주민번호, 여권번호 같은 직접적인 신원 정보는 저장하지 않으며, 국적, 적격 투자자 여부 등과 같은 속성 정보만 기록한다.
위에서도 언급했듯이 한 투자자가 여러 지갑 주소를 보유하고 있을 수 있기 때문에, 각 투자자는 고유한 ID를 가지며, 해당 투자자가 어떤 지갑 주소를 보유하고 있는지 또한 레지스트리 서비스에 저장된다. 레지스트리에 저장된 투자자의 속성 같은 경우 아래에서 살펴볼 컴플라이언스 서비스가 규제 검사하는데 도움을 준다.
투자자 등록 및 속성 부여는 레지스트리 서비스에 존재하는 아래와 같은 함수를 통해 이루어진다:
registerInvestor(string _id, string _collision_hash) : 투자자의 고유 식별자(_id)를 통해 시스템에 투자자를 등록하는 과정으로, _collision_hash는 중복 방지를 위한 해시값이다.
setCountry(string _id, string _country) : 국가 코드를 활용해 투자자의 국적을 설정한다.
setAttribute(string _id, uint8 _attributeId, uint256 _value, uint256 _expiry, string _proofHash) : 투자자의 속성을 부여하는 기능이다. _attributeId에는 0, 1, 2, 4, 8을 부여하여 각각 none, kyc-approved, accredited, qualified, professional의 속성을 부여할 수 있다. _value에는 0, 1, 2를 부여하여 속성의 세 가지 상태(pending, approved, rejected)를 나타낼 수 있으며, 속성의 만료일은 _expiry를 통해 표현된다. 마지막으로 _proofHash에는 오프체인 문서(여권 사진, KYC 보고서) 등의 해시값이 들어가 규제기관 요청 시 해시값을 통해 원본 문서를 확인 가능하다.
addWallet(address _address, string _id) : 한 투자자가 여러 개의 지갑을 보유하고 있을 수 있기 때문에 지갑 주소를 투자자 ID에 연결하는 기능이다.
컴플라이언스 서비스는 디지털 증권의 발행, 소각, 전송 등 모든 라이프사이클 이벤트에서, 발행사가 설정한 규칙과 법규를 준수하도록 모든 토큰 거래를 감독하는 기능을한다.
2.7.1 주요 검사 메소드
validateIssuance(_to, _value) : 새 토큰 발행 가능 여부 확인
validateBurn(_who, _value) : 토큰 소각 가능 여부 확인
validateSeize(_from, _to, _value) : 토큰 강제 회수 가능 여부 확인
validate(_from, _to, _value) : 일반 전송 가능 여부 확인
위 함수들은 DS 토큰에서 트랜잭션이 발생할 때 자동으로 호출된다. 즉, DS 토큰의 발행, 소각, 회수(seize), 전송이 이루어질 때 컴플라이언스 서비스의 위 함수들이 자동으로 호출되며, 만약 해당 트랜잭션이 규칙이나 법규에 위반되면 트랜잭션은 자동으로 실패(revert)된다.
예를 들어 위 코드는 토큰 전송 가능 여부를 판단하는 validateTransfer() 함수인데 (validate 가 validateTransfer 라는 이름으로 구현이 되어있는 것이다), 내부 로직을 보면 preTransfercheck() 을 호출하여 전송 가능한 상태인지 확인을 한다.
preTransfercheck() 은 토큰이 paused 상태인지, 보내는 사람의 잔고는 충분한지, 베스팅 락이 걸린 토큰은 아닌지 등을 확인하며, 이외에도 checkTransfer() 을 통해 추가 규제 로직을 검사한다. 여기서 두 가지 방식으로 나뉘는데:
화이트리스트 방식에선 checkTransfer() 은 단순히 지갑이 레지스트리 서비스에 등록된 투자자인지 확인하고,
규제형 방식에선 checkTransfer() 을 사용하지 않고, 아예 ComplianceServiceLibrary에 있는 복잡한 규제로직을 불러와서 전송 가능 여부를 확인하게 된다.
2.7.2 사전 확인 메소드
트랜잭션을 전송하고 부적격이 떠 트랜잭션이 실패하게되면 가스비가 낭비될 수 있기 때문에, 컴플라이언스 서비스는 트랜잭션을 전송하기 전 미리 해당 거래가 가능한지에 대한 여부를 나타내는 사전 확인 메소드 함수들을 제공한다.
preIssuanceCheck(_to, _value) : 발행 전, 미리 발행 가능 여부 확인
preTransferCheck(_from, _to, _value) : 거래 전, 미리 전송 가능 여부 확인
이들 또한 위에서 살펴보았듯이 레지스트리 서비스를 참고하여 가능 여부를 판단하여 반환한다.
2.7.3 국가별 규제 관리
컴플라이언스 서비스에선 국가별로 투자 가능 여부를 설정할 수도 있다.
setCountryCompliance(_country, _value) : 특정 국가 투자자 거래 허용/차단 설정
getCountryCompliance(_country) : 해당 국가의 거래 허용 상태 조회
이 기능을 활용하여 미국 외 투자자는 발행에 참여 불가하다거나, 특정 국가 투자자만 2차 거래가 가능한다거나 등의 규칙을 온체인에서 강제시킬 수 있다.
갑자기 스마트 컨트랙트 코드와 함수들이 쏟아져서 정신이 없었을 것이다. 실제로 시큐리타이즈의 가장 대표적인 DS 토큰인 BUIDL을 분석하며, DS 프로토콜이 실제로 어떻게 구현되는지 사례를 통해 살펴보자.
우선 BUIDL의 스마트 컨트랙트 주소는 0x77...2aec 이다. BUIDL의 트러스트 서비스, 레지스트리 서비스, 컴플라이언스 서비스는 어떻게 검색할 수 있을까? 이는 DS 프로토콜이 제공하는 getDSService() 함수를 통해 검색할 수 있다.
getDSService(uint _serviceId) 는 _serviceId에 찾고 싶은 서비스에 해당하는 정수를 입력하면 스마트 컨트랙트 주소를 찾아준다. 트러스트 서비스, 레지스트리 서비스, 컴플라이언스 서비스의 서비스 ID는 각각 1, 4, 8으로 이를 이더스캔에 직접 입력하여 검색하면 BUIDL에 해당하는 DS 서비스들의 주소는 아래와 같다:
트러스트 서비스: 0x3a...6c60
레지스트리 서비스: 0x0D...1a5B
컴플라이언스 서비스: 0x07...E3a9
BUIDL의 트러스트 서비스를 이더스캔을 통해 확인해보면 특정 지갑 주소의 역할 부여 트랜잭션을 확인해볼 수 있다.
예를 들어 트랜잭션 0xa4...1680 을 확인해보면, 트러스트 서비스의 Set Role 함수가 호출된 것을 볼 수 있으며, 0xFC...5644 주소가 role 2로 설정되었다. 참고로 트러스트 서비스에서 role 2는 발행사(issuer)에 해당한다.
실제로 트러스트 서비스의 getRole() 함수에 0xFC....5644 을 입력해보면 role 2가 반환되는 것을 확인할 수 있다.
BUIDL의 레지스트리 서비스를 이더스캔을 통해 확인해보면 이벤트 리스트에서 특정 지갑을 레지스트리에 등록한 트랜잭션을 확인해볼 수 있다.
예를 들어 트랜잭션 0x35...ef29 을 확인해보면, Register Wallet 함수가 0x00...6cab 에서 호출된 것을 볼 수 있다. 잠시만, 레지스트리 서비스의 주소는 0x0D...1a5B 인데, 0x00...6cab 는 무엇일까? 이는 해당 트랜잭션의 인터널 트랜잭션 내역을 보면 더 명확히 알 수 있다.
위는 특정 지갑이 레지스트리 서비스에 등록되는 내부 과정인데, 특정 지갑의 역할을 트러스트 서비스(0x3a…6c60)에 확인하는 과정도 포함되어있으며, 결정적으로 아래와 같이 0x00...6cab 가 레지스트리 서비스(0x0D…1a5B)에 addWallet() 함수를 호출하는 내부 트랜잭션이 포함되어있다.
실제로 해당 트랜잭션이 등록한 지갑주소 0x8e...Ef45 를 레지스트리 서비스의 getInvestorDetails() 함수를 통해 읽어보면 아래와 같이 투자자 ID: 1b09…2251과 미국 국적을 확인해볼 수 있다.
컴플라이언스의 주 역할은 DS 토큰 관련된 트랜잭션의 적격 여부를 판단하는 것이다. 실제로 BUIDL 토큰 전송 트랜잭션의 인터널 트랜잭션 목록을 보면, 아래와 같은 인터널 트랜잭션들을 확인할 수 있다:
Validate Transfer: BUIDL 토큰 → 컴플라이언스 서비스: ****토큰 전송이 가능한지 확인하기 위해 자동으로 컴플라이언스 서비스의 validateTransfer() 함수가 호출된다.
Get Investor, Get Country: 컴플라이언스 서비스 → 레지스트리 서비스: 컴플라이언스 서비스는 레지스트리 서비스에 해당 지갑에 대한 속성을 알아내기 위해 getInvestor() 및 getCountry() 함수를 호출한다.
시큐리타이즈는 TVL 측면에서 역시 RWA 시장의 선두주자답게 증권이 블록체인 상에서 규제를 준수하며 잘 거래될 수 있도록 스마트 컨트랙트를 통해 다양한 장치를 마련해두었다. 이를 달성하기 위해 1) 역할을 부여하는 트러스트 서비스, 2) 투자자 정보가 등록되는 레지스트리 서비스, 3) 적격 여부를 확인하는 컴플라이언스 서비스와 같은 DS 서비스들이 유기적으로 상호작용하며, DS 토큰의 발행, 거래는 이를 기반으로 안전하게 이루어진다. 이뿐만 아니라 시큐리타이즈는 DS 토큰이 다양한 스마트 컨트랙트에 활용될 수 있도록 DS 앱을 선보인다. 배당금 지급, 의결권 부여와 같은 DS 앱은 필요하다면 기본적으로 제공된다.
정리하면, 시큐리타이즈의 DS 프로토콜은 디지털 증권의 전체 라이프사이클을 고려하여 설계되었으며, 다른 플랫폼들과 같이 폐쇄형 시스템이 아닌, 발행사, 투자자, 앱 개발자, 거래소 등이 누구나 참여할 수 있는 개방형 생태계를 지향한다. 이러한 기술적 뼈대는 현재 시큐리타이즈가 RWA 시장의 선두주자가 될 수 있는 근간을 제공했다.
이번 글에서는 시큐리타이즈가 디지털 증권을 구체적으로 온체인 상에 어떻게 구현했는지에 집중했다면, 다음에 기회가 된다면 시큐리타이즈가 실제로 어떤 서비스들을 제공하고, 토큰화의 법적 구조는 어떻게 되는지 살펴볼 예정이다.
Securitize
Bitcoin
Arch
OVERTAKE
