시큐리타이즈: 규제형 자산을 위한 '볼트 = 투자자' 모델 (Feat. Vault Registrar)

• 디파이의 풀(Pool) 모델은 무허가 토큰을 전제로 발전해 왔다. 이 구조에서는 허가형 자산의 투자자 단위 소유권 추적, 이전 대리인 의무 등의 컴플라이언스 처리를 온체인에서 구현하기 어렵다.

• sToken과 아베 호라이즌(Aave Horizon)은 각각 토큰 레벨과 프로토콜 레벨에서 규제 준수를 부분적으로 통합했지만, 래퍼 의존성과 프로토콜별 구현 부담이라는 확장성 병목을 남겼다.

• 시큐리타이즈의 Vault Registrar는 투자자마다 독립적인 볼트를 배포함으로써, 소유권 귀속과 기록 단위를 “볼트 = 투자자 포지션”으로 표준화한다.

• 나아가 시큐리타이즈는 Vault Registrar ERC를 통해 허가형 토큰과 디파이 프로토콜 간의 통합 지점을 볼트 단위로 표준화한다.

1. 디파이는 크립토 자산을 디폴트로 발전해 왔다

전체 발행된 RWA 중 실제로 디파이에서 활용되고 있는 RWA의 비중은 9% 내외에 불과하다. RWA의 총 자산 규모는 200억 달러를 넘어섰지만, 대부분의 RWA 렌딩 마켓을 보면 유동성이 충분히 확보되지 않거나, 보수적인 리스크 파라미터로 인해 대출 이용률은 한 자릿수 퍼센트에 머무는 케이스가 RWA 디파이의 현주소이다.

RWA 디파이에 병목이 되는 요인은, 디파이 인프라들이 애초에 BTC, ETH 등 무허가 자산을 전제로 설계되어 왔다는 점이다. 디파이는 벌써 10년 가까이되는 시간 동안 발전을 거듭해왔지만, 디폴트는 언제나 크립토 자산을 담보화 하는 것에만 맞춰져 있었다.

이로 인해 RWA 디파이가 본격적으로 확산되기 위해서는 이에 최적화된 인프라 보완이 필요하다. 무엇보다 온체인 유통의 전 라이프사이클에서 완전한 규제 준수가 가능해야 하는 것이 가장 높은 우선순위에 놓여있다. 이는 기관 주도의 차입과 유동성 공급을 가능하게 하고, 사모 크레딧과 미국 주식 같은 우량 자산을 디파이의 담보로 편입시키는 전제 조건이기 때문이다.

이러한 문제를 해결하기 위해 시큐리타이즈는 ‘Vault Registrar’를 새롭게 발표하고 이를 ERC로 제출했다. 이번 글에서는 RWA 디파이가 발전해온 방식과 기존 풀(Pool) 모델의 한계를 짚고, 시큐리타이즈가 풀에서 볼트로의 전환을 어떻게 구현하고 있는지를 살펴본다.

2. 풀은 소유권 귀속을 훼손한다 (Pools Destroy Attribution)

거의 모든 디파이 프로토콜은 ‘풀’을 기반으로 작동한다. 유동성 풀을 중심으로 대출과 차입이 동적으로 이뤄지거나 수익 최적화 알고리즘에 따라 자산이 리밸런싱되는 구조다. 풀 모델은 거래 상대방을 매칭할 필요 없이, 불특정 다수의 유동성을 하나로 집약해 유연하게 작동하게 하는, 온체인에 가장 적합한 방식으로 채택되어 왔다.

그러나 기존 풀 모델이 증권과 동일하게 취급되는 규제형 RWA 토큰에 적용하는 순간, 다음과 같은 문제가 발생한다.

1. 풀 내부의 소유권 귀속 불가

무허가 토큰의 경우, 풀에서 자금을 하나로 합산해도 문제가 없다. 투자자별 보유 상태는 풀 내 지분 비율로 계산할 수 있으며, 개별 자산이 누구의 것인지까지 특정할 필요는 없다. 즉, 풀 내부의 자산은 서로 완전히 대체 가능하고 풀 전체가 하나의 집합적인 유동성 단위로 취급된다.

반면 증권성 토큰은 투자자 단위의 소유권을 항상 추적해야 한다. 예컨대 BUIDL이나 ACRED와 같은 증권성 자산이 풀에 편입될 경우 자산의 이동, 재담보, 리밸런싱 과정에서 법적 소유 상태를 투자자 단위로 일관되게 확정하기 어렵다. 그 결과 배당 지급, 의결권 행사, 세금 보고 등 증권으로서 요구되는 의무를 이행하기 힘들어진다.

1. 이전대리인(Transfer Agent) 의무와 충돌

시큐리타이즈와 같은 SEC 등록 이전대리인은 투자자 단위의 소유권을 실시간으로 유지해야 할 법적 의무를 가진다. 기존 증권에서 배당, 기준일 설정, 분배, 환매와 같은 기업 행위는 모두 이러한 투자자 단위 기록을 전제로 처리된다.

예컨대 2월 27일 기준 보유자에게 배당을 지급하려면, 해당 시점에 확정된 투자자별 보유 수량 정보가 필요하다. 그러나 자산이 풀에 편입되는 순간 풀 주소와 지분 비율만 남게되며, 이것만으로는 규제 요건을 충족하기 어렵다.

1. 청약(Subscription) 주체 추적 불가

매수 → 담보화 → 차입 → 추가 매수 → 담보화로 이어지는 루핑을 고려해보자. 본래 거의 모든 증권에서 루핑에 필요한 ‘추가 매수’는 일반 스왑이 아니라 특정 투자자에게 귀속되는 청약 행위이다.

이에 따라 프로토콜이 자동 매수나 리밸런싱을 수행할 경우, 해당 거래가 누구의 청약인지, 투자자가 적격한지, 투자 한도를 초과하지 않는지 확인해야 한다. 그러나 풀은 전체가 하나의 집합적인 유동성 단위이기에, 개별 스왑을 특정 투자자의 청약으로 귀속시키기는 것이 불가능하다.

ACRED를 담보로 USDC를 차입한 뒤 다시 ACRED를 매수하는 경로를 예로 들면, 풀 모델에서 추가 매수분의 소유권을 특정 투자자에게 귀속시킬 수 없다. 풀은 특정 투자자를 대신해 증권을 청약하는 주체가 될 수 없기 때문이다.

결과적으로 풀 모델은 RWA 토큰을 개별 투자자 단위로, 또 이전대리기관 수준에서 처리해야 하는 순간 증권 규제를 완전히 준수하는 것이 어렵다. 즉 풀 모델은 무허가형 자산을 전제로 설계되었으며, 규제(허가형) 자산은 근본적으로 다른 인프라를 요구한다.

3. 풀 모델에서의 발전 과정: 아베 호라이즌과 sToken

시큐리타이즈가 Vault Registrar를 공개하기 이전까지, 기존 풀 모델을 보완하려는 시도가 없던 것은 아니다. RWA에 최적화된 형태로 규제 준수 장치를 디파이 흐름에 통합하는 방식이 고안되어 왔으며, 이러한 접근방식 또한 RWA 디파이에서 유의미한 대안으로서 자리 잡고 있다.

3.1 아베 호라이즌: RWA의 네이티브 디파이 담보화

먼저 시큐리타이즈가 인프라 파트너로 참여한 아베 호라이즌(Aave Horizon)은 허가형 디파이 프로토콜로 가장 대표적이다. 아베 호라이즌은 기관 및 적격 투자자 전용으로 설계된 RWA 마켓으로, 기존 아베 프로토콜의 별도 인스턴스로 운영된다.

아베 호라이즌의 주된 기능은 허가형 토큰을 담보로 공급하고, 이를 기반으로 스테이블코인을 차입할 수 있도록 하는 것이다. 이 과정에서 시큐리타이즈는 발행, 소유권 추적, 수익 및 권리 관리까지 포함한 컴플라이언스 인프라를 제공함으로써, 규제형 자산이 래퍼 없이도 디파이 프로토콜에서 직접 담보로 활용될 수 있도록 한다.

아베 호라이즌의 설계 주안점은 네 가지로 좁혀진다:

• 허가형 담보: 화이트리스트된 참여자만 RWA를 예치할 수 있다.

• 전송 불가능한 aToken: RWA 예치 시 transfer, approve, permit 등 ERC-20 기능을 비활성화한, 양도 불가능한 aToken을 수령한다. 이는 담보 포지션과 최초 투자자를 일치시킴으로써 각 투자자의 풀 내 지분을 안정적으로 산출하기 위함이다.

• 내장된 안전장치: 분실 키, 제재 대상 지갑 등 발행자의 개입이 필요한 예외 상황을 담보 풀을 훼손하지 않고 처리할 수 있도록 했다.

• 퍼미션리스 유동성: 대출/차입 구조는 기존 디파이와 동일하다. USDC나 GHO와 같은 스테이블코인은 누구나 공급할 수 있으며, RWA를 담보로 제공한 차입자는 이 풍부한 유동성에 접근할 수 있다.

이러한 구조에서 아베 호라이즌 상의 온체인 담보 포지션은 시큐리타이즈의 MSF(Master Securityholder File)와 동기화되어, 수익 발생이나 권리 산정이 담보로 설정된 상태까지 자동으로 반영된다. 또한 분실 주식 처리나 회수 절차와 같은 규제 요구사항 역시 풀 운영을 훼손하지 않는 범위에서 지원된다. 그 결과, 아베 호라이즌은 래퍼 없이도 네이티브 RWA 자산 상태를 유지하면서 컴플라이언스 의무를 충족할 수 있다.

오일러 파이낸스(Euler Finance)도 이와 유사한 접근을 취하고 있다. 오일러는 Vault Kit(EVK)에 시큐리타이즈의 DS 프로토콜을 직접 통합하여, DS 토큰이 격리된 렌딩 마켓에서 네이티브 담보로 활용될 수 있도록 한다. 시큐리타이즈가 이전대리인 자격으로 담보 볼트를 배포하고, 큐레이터가 별도의 차입 볼트를 배포하는 이중 볼트 구조로, 화이트리스트 투자자만 예치와 차입 및 청산에 참여할 수 있으며 볼트 지분 토큰의 전송도 차단된다. 래퍼 없이 실제 DS 토큰이 프로토콜에 직접 편입된다는 점에서 아베 호라이즌 모델과 설계 철학을 공유한다.

3.2 sToken: ERC-4626 기반 RWA 디파이 인터페이스

또 다른 접근으로는 시큐리타이즈가 설계한 sToken 표준이 있다. sToken은 BUIDL이나 ACRED 등 시큐리타이즈가 발행한 RWA 토큰을 디파이에서 활용할 수 있도록 만든 ERC-4626 기반 볼트 래퍼이다.

sToken은 적격 투자자가 RWA 토큰을 sToken 볼트에 예치하면, 디파이에서 사용 가능한 sToken(ex. sBUIDL, sACRED)을 수령한다. 투자자는 이 sToken을 담보로 대출, 루핑, 파생 담보 등 디파이 전략을 실행할 수 있으며, 필요 시 원본 RWA로 상환이 가능하다.

이 과정에서 시큐리타이즈는 투자자가 RWA 토큰을 sToken 볼트에 예치하는 시점에 적격투자자 여부, 관할권, 이전 제한, 리딤 권리 등 모든 규제 요건을 사전에 검증한다. 해당 요건을 충족하지 못한 참여자는 sToken을 발행할 수 없다.

이를 통해 시큐리타이즈는 모포(Morpho), 폴리곤(Polygon), 건틀릿(Gauntlet)과 함께 sACRED 기반 레버리지 RWA 전략을 출시한 바 있다. 사용자는 sACRED를 건틀릿의 볼트에 예치하면, 볼트는 sACRED를 Morpho에 담보로 제공하고 USDC를 차입한다. 이후 차입한 USDC로 추가 ACRED를 매수하고, 이를 다시 담보로 예치하는 과정을 반복함으로써 레버리지 포지션을 형성하는 구조이다.

이러한 sToken 활용에서 중요한 점은 규제 준수와 소유권 관리가 디파이 환경에 진입하기 이전에 이미 확정된다는 것이다. 시큐리타이즈가 투자자의 적격 투자자 여부와 법적 소유권을 sToken 레벨에서 검증 및 확정하고, sToken이 발행된 이후에는 해당 자산이 디파이 환경으로 이동하더라도 컴플라이언스 검증이 다시 이루어질 필요가 없다.

그러나 sToken은 현재 사실상 폐기 수순에 접어들었으며, 아베 호라이즌이나 Vault Registrar 등 다른 솔루션들로 대체되어 가고 있다고 봐도 무방하다. 래퍼 구조가 추가적인 추상화 계층을 요구하고, 소유권·기록일·권리·배당 등의 정보가 디파이 내 토큰과 분리된 형태로 존재할 수밖에 없다는 한계가 이러한 전환의 배경이라 할 수 있다.

3.3 남은 문제: 왜 Vault Registrar가 필요한가

여기까지가 RWA 디파이의 컴플라이언스 문제를 해결하기 위해 발전해온 과정이다.

정리하면 아베 호라이즌과 오일러 파이낸스는 프로토콜 레벨에서 규제 적합성을 확보한 방식이다. 래퍼 없이 네이티브 방식으로 RWA를 수용하며, 아베 호라이즌은 500억 달러 AUM을 넘기며 충분한 마켓 규모를 형성하고 있다. 한편 sToken은 토큰 레벨에서 규제 적합성을 확보하는 방식이었다. 비교적 가장 유연하게 디파이 활용을 가능하게 했다.

그럼에도 불구하고, 이러한 방식들은 다음과 같은 한계를 남겼다.

• sToken: 원본 RWA는 여전히 sToken이라는 중간 계층을 거쳐야 한다. 이는 단순히 추상화 단계가 추가된다는 의미를 넘어, 소유권, 기록일, 권리, 배당, 규제 이벤트 등의 정보가 디파이 내의 토큰과 분리된 형태로 존재할 수밖에 없음을 의미한다.

• 아베 호라이즌 / 오일러: 각 프로토콜에 특화된 설계이기 때문에 확장성이 제한된다. 아베 호라이즌의 aToken 구조와 MSF 연동, 오일러의 EVK 이중 볼트 구조와 DS 프로토콜 통합은 모두 해당 프로토콜의 아키텍처에서 구현된 해결책이다. 모포, 컴파운드, 스파크 등 다른 디파이 프로토콜이 동일한 문제를 해결하려면, 각 프로토콜이 이에 상응하는 수준의 커스텀 설계와 컴플라이언스 통합을 별도로 재구현해야 한다.

결론적으로 sToken은 토큰 레벨에서, 아베 호라이즌과 오일러는 프로토콜 레벨에서 규제 정합성을 확보하지만, 전자는 래퍼 의존성이, 후자는 프로토콜별 재구현 부담이 병목으로 남는다. 이 한계 지점에서 Vault Registrar가 새로운 대안으로 고안된다.

4. Vault Registrar: 볼트 = 투자자

Vault Registrar의 접근은 풀 모델과 근본적으로 다르다. 풀 안에서 소유권을 추적하는 것이 아니라, 아예 투자자별로 독립 볼트를 배포한다. 특정 투자자마다 하나의 스마트 컨트랙트로 구성된 전용 볼트가 배정되는 방식으로, 프로토콜 레벨이나 토큰 레벨에서 컴플라이언스를 처리하는 것이 아니라 투자자별 볼트로 이를 분리한다.

4.1 VaultRegistrar 컨트랙트

4.1.1 Vault Registrar 작동방식: EVM

개별 투자자 단위의 볼트 모델을 위해 시큐리타이즈가 제시한 솔루션이 VaultRegistrar 컨트랙트다. VaultRegistrar는 시큐리타이즈가 직접 관리하며, DS 토큰에 대해 지갑 주소를 등록하고 귀속시키는 권한을 갖는다. 여기서 DS 토큰이란, 시큐리타이즈가 자체 개발한 스마트 컨트랙트 집합인 DS 프로토콜을 통해 발행된 토큰을 의미한다. DS 컨트랙트를 통해 증권 발행사, 투자자, 거래소는 규제를 준수한 상태로 토큰화 증권을 취급할 수 있으며, BUIDL 역시 DS 토큰에 해당한다.

VaultRegistrar 컨트랙트는 이 DS 토큰을 사용자가 디파이 프로토콜에 예치하는 서명과 함께 호출되며, 개별 볼트를 배포하고 등록하는 절차까지 전체 흐름에 개입한다. 자세한 작동 방식은 다음과 같다:

1. 투자자 인가 서명: 투자자는 EIP-712 구조화 메시지(Typed structured data hashing and signing)에 서명하여 특정 프로토콜(Operator)이 자신의 컴플라이언스 신원 하에 볼트를 등록할 수 있도록 명시적으로 권한을 부여한다. 이 서명에는 투자자 주소, 프로토콜 주소, 토큰 범위, 만료 시점 등이 포함된다

2. 투자자 예치 요청: 투자자는 디파이 프로토콜에 DS 토큰 예치를 위해 deposit ()트랜잭션에 서명한다.

3. 전용 볼트 배포: 사전 승인된 파트너 컨트랙트(Operator)는 예치 플로우 중 VaultRegistrar를 호출해 투자자 전용 볼트를 아토믹하게 배포한다. 이때 투자자의 EIP-712 서명도 함께 제출된다.

4. 자격 검증 및 인가 확인: VaultRegistrar는 호출자가 승인된 Operator인지, 투자자의 EIP-712 서명이 유효한지, 투자자가 KYC를 완료했는지, DS 토큰 보유 요건을 충족하는지를 검증한다.

5. 볼트 등록 요청: 검증이 진행되는 동일 트랜잭션 내에서 registerVault가 호출되며, 투자자 지갑 주소와 새로 배포된 볼트 주소가 등록 대상으로 전달된다.

6. 등록 완료: 모든 검증이 통과되면, 해당 볼트 주소가 투자자 신원에 1:1로 귀속된 전용 볼트로 확정된다.

7. 자산 이전: RWA 토큰이 투자자 전용 볼트 주소로 최종 이전된다.

이 모든 과정은 프로토콜의 예치 트랜잭션 안에서 아토믹하게 발생한다. 볼트의 실행 로직은 프로토콜이 정의하고 제어하지만, 컴플라이언스 처리는 프로토콜 레벨이나 토큰 레벨이 아닌 시큐리타이즈의 VaultRegistrar 컨트랙트로 분리되어 실행된다. 또한 자산의 소유권은 항상 투자자에게 귀속된다. 그 결과 볼트 제공자는 규제 부담없이 금융 로직을 구현하는 것에만 집중할 수 있다.

또한 앞서 언급했듯, 이 과정에서 투자자의 인가는 EIP-712 서명을 기반으로 한다. 초기 설계에서는 프로토콜이 VaultRegistrar를 호출하면 투자자의 별도 동의 없이도 볼트가 등록되는 암묵적 신뢰 구조였으나, 실제 통합 과정에서 투자자가 인가를 명시적으로 부여(Explict Vault Authorization)하고 언제든 철회할 수 있도록 개선되었다. 이를 위해 시큐리타이즈는 투자자가 지갑 UI에서 읽을 수 있는 구조화 메시지(투자자 주소, 프로토콜 주소, 토큰 범위, 논스, 만료 시점 포함)에 서명하는 방식으로 전환했다.

이를 통해 투자자는 어떤 프로토콜에 어떤 토큰에 대한 권한을 부여하는지 정확히 인지한 상태에서 승인할 수 있으며, 특정 프로토콜에 부여한 인가를 즉시 무효화할 수도 있다. 또한 한 번의 서명으로 포괄 인가가 부여되기 때문에, 담보 리밸런싱이나 레버리지 루프 등에서 매 단계마다 재인가할 필요가 없다. 결과적으로 VaultRegistrar는 Operator 인가·투자자 서명·컴플라이언스 규칙을 모두 검증한 뒤에만 볼트를 등록하는 정책 집행 레지스트리(policy-enforcing registry)로서 기능한다.

4.1.2 솔라나용 Vault Registrar

VaultRegistrar는 초기에 EVM 기반으로 설계되었으나, 시큐리타이즈는 멀티체인 확장의 첫 단계로 솔라나용 Vault Registrar 프로그램을 출시했다. 기본 설계 목표는 동일하다. 프로토콜이 배포한 볼트가 투자자의 컴플라이언스 신원 하에 등록되어야 하며, 자산의 수탁이나 이전은 수행하지 않고 오직 등록만을 처리한다. 의도적으로 최소한의 기능만을 담은 비수탁형, 결정론적(deterministic) 프로그램이라는 점에서 EVM 구현체와 목적이 같다.

다만 구현 방식은 솔라나의 아키텍처에 맞게 다르다. EVM에서는 EIP-712 서명으로 투자자 인가를 처리하는 반면, 솔라나에서는 트랜잭션 서명자 검증과 CPI(Cross-Program Invocation) 체인을 통해 동일한 보증을 구현한다. 전체 플로우는 다음과 같다:

1. 프로토콜 호출: 프로토콜(Operator)이 투자자의 예치 플로우 중 register_vault를 호출한다.

2. 서명자 검증: Vault Registrar 프로그램은 솔라나의 트랜잭션 모델을 활용해, 투자자가 해당 트랜잭션의 최초 서명자(original signer)인지를 확인한다. 이는 EVM의 EIP-712 서명이 담당하는 '투자자 명시적 동의'에 대응하는 메커니즘이다.

3. CPI 체인을 통한 컴플라이언스 검증: Vault Registrar → rwa-rbac → Identity Registry → System Program으로 이어지는 CPI 체인을 통해, DS 토큰의 아이덴티티 레지스트리를 기준으로 투자자의 KYC 적격성과 컴플라이언스 요건을 검증한다.

   여기서 CPI(Cross-Program Invocation) 체인이란, 솔라나에서 하나의 프로그램이 다른 프로그램을 연쇄적으로 호출하는 메커니즘을 말한다. 즉 볼트 등록 요청이 들어오면 역할 권한 확인(rwa-rbac) → 투자자 신원 확인(Identity Registry) → 온체인 계정 처리(System Program)까지 프로그램 간 호출이 한 트랜잭션 안에서 순차적으로 실행되는 구조다.

4. PDA 기반 볼트 귀속: 모든 검증이 통과되면, PDA(Program Derived Address)를 기반으로 볼트 지갑을 투자자 신원에 1:1로 귀속시킨다.

   PDA란 프로그램 ID와 시드값(예: 투자자 주소, 토큰 주소 등)을 입력하면 항상 동일한 주소가 산출되는 솔라나 고유의 계정 주소 체계다. 일반 지갑 주소와 달리 대응하는 개인키가 존재하지 않기 때문에 외부에서 임의로 서명하거나 조작할 수 없고, 오직 해당 프로그램만이 이 주소에 대한 권한을 행사할 수 있다. 이를 통해 볼트와 투자자 간의 매핑은 온체인에서 검증 가능한 형태로 고정된다.

정리하면, EVM과 솔라나의 인가 메커니즘은 다르지만 보증하는 바는 동일하다. 투자자가 명시적으로 참여한 트랜잭션에서만 볼트가 등록되고, 컴플라이언스가 확인된 투자자에게만 귀속된다. 이를 통해 솔라나 기반 RWA도 EVM과 동일한 수준의 투자자 귀속 볼트 모델을 활용할 수 있다.

4.2 Vault Registrar 유즈케이스

투자자 귀속 볼트는 규제를 준수하면서도, 소유권을 훼손하지 않은 상태에서 다양한 디파이 상호작용에 대한 가능성을 연다.

4.2.1 스마트 에스크로 (조건부 자산 이동)

VaultRegistrar의 아토믹한 트랜잭션 실행은 본래 컴플라이언스 처리를 위한 것이지만 볼트 단위에서 조건부 자산 이전을 프로그래밍 가능하게 하기도 한다. 이를 통해 볼트 내부 로직에 따라 조건이 충족될 때만 자산이 집행되게 하여, RWA에 최적화된 금융 로직을 구현할 수 있다.

• 기관 간 OTC 거래: 투자자 귀속 볼트를 대금 지급/외부 확인 등 사전에 조건이 충족될 때만 자산 이전이 실행되도록 구성할 수 있다. 전통 금융의 조건부 OTC 거래 방식을 온체인에 재현하는 방식이다.

• 구조화 상품: 구조화 상품은 기초자산을 조건에 따라 단계적으로 집행하거나, 성과나 이벤트에 따라 자산 사용 권한과 현금 흐름을 제어한다. 예컨대 사모 크레딧이 연 8% 수익률을 달성할 경우에만 차입이 허용되도록, 볼트 단위의 조건부 실행을 활용할 수 있다.

• 조건부 신용 제공: 담보를 먼저 제공하더라도, 재무 상태가 유지되거나 특정 시점이 도래하는 등 미리 정해진 조건이 충족될 때만 돈을 빌릴 수 있도록 설계할 수 있다. 이때 담보 자산은 계속 투자자 소유로 남아있고, 볼트는 조건이 충족되는 순간에만 차입을 허용하는 역할을 한다.

4.2.2 원클링 루핑

매수 → 담보 설정 → 차입 → 추가 매수를 단일 트랜잭션 흐름으로 실행하는 원클릭 루핑이 가능해진다. 풀 모델에서는 루핑 과정에서 발생한 추가 매수를 특정 투자자에게 직접 귀속할 수 없고, 사후적으로 풀 내 지분 비율을 추산하는 방식에 의존할 수밖에 없다.

반면 볼트 모델에서는 각 루프에서 발생한 추가 매수가 항상 특정 투자자의 전용 볼트로 직접 귀속된다. 이를 통해 추가 매수 주체를 정확히 특정하여 컴플라이언스를 충족하면서도 레버리지 전략을 구현할 수 있다.

4.2.3 온체인 프라임 브로커 계좌

프라임 브로커 계좌는 담보 평가, 레버리지 제공과 차입 실행, 리스크 한도 관리, 마진콜 같은 금융 서비스를 하나의 계좌에서 처리한다. 즉, 투자자별로 자산, 부채, 리스크를 독립적으로 관리하는 운영 단위이다.

투자자 귀속 볼트는 이 프라임 브로커 서비스를 온체인에서 재현할 수 있다. 볼트는 자산 보관 컨테이너뿐만 아니라, 특정 투자자에게 귀속된 스마트 컨트랙트로서 담보 설정, 차입, 리밸런싱, 조건부 집행을 코드로 수행한다. 이를 기반으로 다른 DSApp(DS 프로토콜 기반 금융 앱)과 결합하면 RWA를 담보로 차입한 자금을 자동 재투자하거나 담보 비율이 특정 임계치에 도달할 경우 포지션을 축소하는 식의 신용 흐름도 구현할 수 있다.

4.3 ERC: Vault Registrar 인터페이스

Source: Ethereum Magicians

시큐리타이즈는 이 구조를 자사 프로덕트에 국한하지 않고 이더리움 매지션즈 포럼에 "Vault Registrar Interface for Permissioned ERC-20 Vaults" ERC를 제출했다.

관계를 정리하면, Vault Registrar는 시큐리타이즈가 실제로 운영하는 구현체이고, ERC 상의 Vault Registrar 인터페이스는 이를 범용화하기 위해 제안된 표준이다. 즉 역할과 메커니즘은 동일하지만, 후자는 다수 발행사와 프로토콜이 공통으로 채택할 수 있도록 추상화된 표준이라는 점에서 구분된다.

이러한 범용 표준이 필요한 이유는 다음과 같다:

• 호환성: 호환성 측면에서 여러 디파이 프로토콜이 동일한 볼트 등록 인터페이스를 채택하면, 각 프로토콜이 개별 발행사의 볼트 귀속 로직을 직접 검증할 필요없이 표준 자체를 신뢰할 수 있다.

• 상호결합성: 디파이 상호결합성 측면에서 발행사 마다의 허가형 토큰이 동일한 디파이 흐름에 통합될 수 있다. 이로써 통합 구조가 단일 프로토콜과 개별 발행사의 1:1 구조에서 다중 프로토콜과 다중 발행사의 N:N으로 확장 가능하다.

• 통합 간소화: 프로토콜은 토큰별 컴플라이언스와 전송 로직을 각각 구현할 필요 없이, 표준화된 레지스트리를 한 번 호출하는 것만으로도 규제형 자산을 디파이 흐름에 포함시킬 수 있다.

그리하여, ERC가 정의하는 인터페이스의 핵심은 두 가지 진입점으로 구성된다.

1. 볼트 등록을 수행하는 함수:

registerVault(address vaultAddress, address investorWalletAddress, uint256 deadline, bytes calldata signature)

프로토콜이 배포한 투자자 전용 볼트를 특정 투자자 지갑에 등록하는 함수다. 호출 시 투자자의 EIP-712 서명과 만료 시점이 함께 제출되며, 서명이 무효하거나 만료되었거나 컴플라이언스 검증에 실패하면 트랜잭션이 revert된다. 이 호출은 예치 트랜잭션과 동일한 트랜잭션 내에서 아토믹하게 실행되며, 완료 시 해당 볼트는 투자자 인가 하에서 규제형 자산을 보유 및 활용할 수 있는 상태가 된다.

2. 등록 사실을 기록하는 표준 이벤트:

VaultRegistered(address indexed investor, address indexed vault, address token, string investorId, address indexed sender)

특정 볼트가 어떤 투자자에게 어떤 허가형 토큰에 대해 등록되었는지를 온체인에 기록하는 이벤트다. sender 필드를 통해 등록을 실행한 프로토콜(Operator)까지 추적할 수 있으며, 발행사, 이체대리기관, 감사 및 리포팅 시스템이 투자자 단위 소유권을 추적하는 기준으로 활용된다.

이러한 함수로 실행되는 인터페이스의 설계 원칙은 명확하다. ERC-20 토큰 자체를 확장하지 않는 독립형 보조 컨트랙트 인터페이스(Standalone companion contract interface)로 설계되어, 핵심 함수와 최소한의 이벤트만을 정의한다. 이는 이미 발행된 다수의 RWA 토큰이 업그레이드 불가한 상태이거나, 규제/운영 상의 이유로 컨트랙트 수정이 허용되지 않는 환경을 전제로 한 설계다.

• 토큰 표준의 파편화: 현재 시장에는 ERC-1400, ERC-3643 등 다양한 규제 토큰 표준이 혼재해 있다. 이를 ERC-20 확장 방식으로 통합하려 할 경우 재발행이나 복잡한 마이그레이션이 필요하거나, 현실적으로 적용이 불가능해진다.

• 발행사별 컴플라이언스 구현: KYC 적격성 판단, 이체대리기관 로직과 같은 컴플라이언스 기능은 발행사별로 토큰 외부 시스템이나 별도 온체인 모듈에서 관리되는 경우가 많다. 이 때문에 규제 로직을 ERC-20 확장으로 통합하는 접근도 현실적으로 적용이 어렵다.

따라서 ERC는 토큰 컨트랙트는 그대로 유지하고, Vault Registrar라는 보조 컨트랙트를 통해 투자자 귀속과 인가 여부만을 분리해 처리한다. 이를 통해 규제형 자산을 디파이 플로우에 현실적으로 통합할 수 있는 최소 단위의 표준을 제시하고 있다.

5. 풀 모델에서 볼트 모델로의 전환

크립토 베어마켓이 장기화되는 동안에, RWA 기반 디파이에 대한 관심도 더욱 커질 것으로 보인다. 온체인 머니마켓 APY가 2~4%대에 머물고 미국 국채 수익률도 3~4% 수준을 유지하는 환경에서는, 크립토 자산 담보보다 사모 크레딧, 미국 국채, 주식 등 RWA 담보가 더 합리적인 포지션이기 때문이다. 여기에 인센티브 파밍이나 토큰 인플레이션에 의존하지 않고, 사모 크레딧을 기초 자산으로 연 8% 내외의 이자 수익을 추구할 수 있는 RWA 루핑에 대한 기대감도 관심을 높이고 있다.

그러나 컴플라이언스는 여전히 RWA 디파이의 최대 병목이다. 이에 시큐리타이즈의 Vault Registrar와 이를 범용 인터페이스화한 Vault Registrar ERC는 유의미한 대안이 되어줄 것으로 보인다. 현재 ERC는 초기 단계에 놓여있지만, ERC-4626이 디파이 볼트의 표준으로 자리 잡은 전례를 감안하면, RWA 디파이에서도 유사한 표준화 흐름이 나타날 가능성이 크다.

마치며, 사실 ‘RWA’라는 용어는 다소 어색하다. 크립토 네이티브 자산과 대비되는 실물 자산을 지칭하기 위해 용어를 빌려쓰고 있지만 온체인은 본래 어떤 자산이든 수용할 수 있는 금융 도구이다. 토큰화를 통해 실물 자산이 이미 디폴트 자산군 중 하나로 편입되었으며, 다음 단계는 보다 고맥락의 금융 로직을 온체인에 구현하는 것이다. 이러한 흐름에서 Vault Registrar를 통해 디파이의 기본 단위가 풀 모델에서 볼트 모델로 전환되는 과정은, RWA라는 용어를 무용하게 만드는 중요한 전환점이 될 것이다.