XRP 레저, XLS 토큰 차단 기능 제안

핵심 요약

• XRPL 개발자들은 발급자가 제어하는 ​​토큰 차단 권한을 제안합니다.
• XLS-87은 TokenPreauth 및 TokenBlock 트랜잭션 유형을 도입했습니다.
• 시행 절차가 아직 완료되지 않았으며 메인넷 활성화도 확정되지 않았습니다.

XRP Ledger 개발자들은 발행자가 특정 계정의 디지털 자산 취득을 차단할 수 있도록 하는 새로운 토큰 승인 및 차단 제어 기능을 개발 중이며, 이는 XRPL 기반 시스템을 구축하는 기관에 또 다른 잠재적인 규정 준수 기능을 제공할 수 있습니다.10월 16일에

제출된 코드 제안은 XLS-87 표준에 TokenPreauth와 TokenBlock이라는 두 가지 거래 유형을 도입합니다. 이러한 변경 사항은 일반적인 XRP 전송보다는 다목적 토큰(MPT)에 초점을 맞추고 있습니다.

해당 제안은 아직 초안 개발 단계에 있습니다. 현재 구현 방식은 권한 기록을 생성 및 관리하지만, 계정이 토큰을 획득하려고 할 때 제한 사항을 적용하는 기능은 아직 제공하지 않습니다.
XRPL 개발자들이 TokenPreauth와 TokenBlock을 소개합니다

개정된 XLS-87 규격 에 따라 토큰 발행자는 자산을 보유할 수 있는 사람을 관리하는 두 가지 상호 보완적인 방법을 얻게 됩니다.

TokenPreauth를 사용하면 발급자가 승인이 필요한 MPT 발행에 대해 특정 계정을 사전에 승인할 수 있습니다. 이를 통해 해당 계정이 토큰 보유를 승인할 때 별도의 발급자 승인 거래가 필요 없어질 수 있습니다.

TokenBlock은 그 반대 방향으로 작동하여 발행자가 특정 계정의 토큰 획득을 금지할 수 있도록 합니다.

제안된 제한 사항은 직접적인 자금 이체에만 국한되지 않습니다. 향후 시행될 규정은 결제, 분산형 거래소 거래, 수표, 에스크로, 자동 시장 조성자 및 금고를 통한 토큰 획득까지 포괄하도록 설계되었습니다.

중요한 점은 기존 보유자를 차단한다고 해서 현재 잔액이 자동으로 동결되는 것은 아니라는 것입니다. 해당 사양은 추가 토큰 획득을 방지하는 것과 이미 보유한 토큰을 제한하는 것을 구분합니다.
이번 제안은 XRPL이 개발 중인 제도적 통제 시스템 에 또 다른 계층을 추가하는 것으로 , 여기에는 거래 및 유동성 인프라에 대한 자격 증명 기반 접근 방식이 포함됩니다.
기관 자산에 토큰 블로킹이 중요한 이유

은행과 토큰화된 자산 발행자는 무제한 블록체인 전송 모델이 제공하는 것보다 규제 대상 금융 상품을 누가 받을 수 있는지에 대해 더 많은 통제권을 필요로 하는 경우가 많습니다.

XRPL 개발자들이 은행 및 기관을 위한 KYC 전용 유동성 풀을 모색하고 있습니다.

새로운 XRPL 표준 아이디어는 허가형 도메인을 AMM(대체 시장 조성자)으로 확장하여 은행이 검증되지 않은 지갑과의 거래 없이 온체인 유동성을 제공할 수 있도록 합니다.

9월 5일
XRPL 표준 논의에서 XRPL의 기존 자격 증명 및 권한 도메인 아키텍처를 네이티브 유동성 풀로 확장하는 권한 기반 AMM(대체 시장 조성자)이 제안되었습니다. 이 개념은 현재 XLS 아이디어 단계이며 승인된 수정안이 아니며 XRP 원장에 활성화되지 않았습니다.

이번 제안은 XRPL의 기관용 DeFi 인프라의 특정 공백을 해결하는 것을 목표로 합니다. XRPL의 허가형 DEX는 승인된 자격 증명을 보유한 지갑으로 주문장 거래를 제한할 수 있지만, XRPL 공식 문서에 따르면 허가형 거래는 AMM을 사용할 수 없으며, 현재 허가형 도메인을 통해 기존 AMM에 대한 접근을 제한할 수도 없습니다.

은행은 허가된 주문장은 사용할 수 있지만 허가된 주문 풀은 사용할 수 없습니다.

주문장 시장과 자동시장조작기(AMM)가 유동성을 제공하는 방식이 다르기 때문에 이러한 구분이 중요합니다.

XRPL의 기존 허가형 거래소는 도메인 소유자가 허용 가능한 자격 증명을 지정할 수 있도록 합니다. 이러한 요건을 충족하는 계정만 적격 제안을 게시하거나 상호 작용할 수 있습니다. 이는 KYC 또는 기타 자격 검증 절차를 거래 환경에 직접 통합하는 것입니다.

코인페이퍼는 앞서 XRPL의 광범위한 기관 인프라 구축 사업의 일환으로 허가형 탈중앙화 거래소(Permissioned DEX) 가 출시될 것이라고 보도한 바 있습니다 . 리플의 초기 기관 대상 DeFi 로드맵 에서도 허가형 거래는 대출 및 토큰화 인프라와 함께 언급되었습니다.

AMM은 다릅니다. 구매자와 판매자가 일치하는 주문을 제출하는 대신, 사용자는 두 자산을 유동성 풀에 제공하고 거래는 해당 풀의 가격 결정 메커니즘에 따라 실행됩니다.

하지만 현행 아키텍처에서는 KYC 인증을 완료한 지갑에서 일반 XRPL AMM에 자산을 투입하더라도 해당 풀이 KYC 전용으로 전환되지 않습니다 . 다른 지갑에서도 여전히 해당 풀과 상호 작용할 수 있습니다. 바로 이 문제를 해결하기 위해 새로운 제안이 나온 것입니다.
예를 들어, 토큰화된 증권을 발행하는 기관은 적격 투자자를 승인하거나 지정된 주소가 추가 보유량을 취득하는 것을 방지해야 할 수 있습니다.

XLS-87은 발급자가 애플리케이션 수준의 검사에만 의존하는 대신, 이러한 제한 사항 중 일부를 원장 항목을 통해 직접 표현할 수 있는 방법을 제공합니다.이 설계는 계정의 마스터 키를 공유하지 않고도 운영 책임을 분리할 수 있도록 지원하는 XRPL의 기존

권한 위임 아키텍처를 기반으로 합니다.

제안에 따르면, 토큰 발행자는 토큰 관리 거래를 위임할 수 있습니다. 특히 ‘토큰 블록 생성(TokenBlockCreate)’이라는 제한적인 권한을 통해 승인된 운영자는 계정을 차단할 수 있지만, 해당 제한을 해제할 수 있는 권한은 부여할 수 없습니다.

하지만 이러한 통제 조치만으로는 증권법이나 고객 식별 요건을 자동으로 준수할 수 없습니다. 금융기관은 여전히 ​​적절한 온보딩, 모니터링 및 법적 보호 장치를 마련해야 합니다.XLS-87은 여전히 ​​시행 코드 및 유효성 검사기 승인이 필요합니다.

10월 16일자 풀 리퀘스트는 구현 과정의 한 단계만을 나타냅니다.

개발자들은 필요한 원장 항목을 별도로 제안했으며, 이후 변경 사항에서는 차단된 계정이 다른 토큰 획득 메커니즘을 통해 제한을 우회할 수 없도록 해야 합니다.

현재 코드는 아직 강제 적용이 구현되지 않았기 때문에 차단된 계정이 스스로 인증하는 것을 명시적으로 허용하고 있습니다.

이러한 점이 XLS-87을 10월 23 일로 예정된 XRPL 업그레이드와 차별화하는 요소입니다 . XRPL 업그레이드는 기존 기능에 대한 수정 사항을 다루며 이미 수정 활성화 기간에 들어갔습니다.

XLS-87은 아직 확정된 메인넷 활성화 날짜나 검증자 승인 절차가 없습니다.

이러한 개발은 별도의 대출 수정안 과 함께 진행되며 , 해당 수정안의 제안된 기능이 실제로 작동하기 위해서는 검증자의 지원이 필요합니다.

투자자들에게 있어 이러한 구분은 중요합니다. 왜냐하면 프로토콜 개발 활동이 곧 XRP 수요 증가로 이어지는 것은 아니기 때문입니다.

그럼에도 불구하고, 제안된 기관 대출 및 발행자 제어 권한을 포함한 XRPL의 확장되는 토큰 인프라는 규제된 금융 애플리케이션을 수용하기 위한 보다 광범위한 노력의 일환임을 시사합니다.