이 글은 파로스(Pharos) 생태계 개발자들에게 실물자산(RWA) 통합에 대한 보다 실용적이고 심층적인 참고 자료를 제공하는 것을 목표로 합니다. 업무 로직과 위험 관리 아키텍처의 관점에서 실물자산을 온체인에 구현할 때 직면하는 복잡한 문제와 해결책을 재구성하고자 합니다.
소개
파로스(Pharos) 생태계는 전통적인 금융 자산과 웹3 세계를 연결하는 인프라가 되는 것을 목표로 합니다. 기존 암호화 자산과 달리 실물 자산(RWA)은 오프체인 물리적 권리 와 온체인 거래 속성을 모두 보유합니다. 이러한 이중적 특성으로 인해 보안 경계는 스마트 계약 수준에만 머물러서는 안 되며, 자산 소유권 검증, 데이터 동기화, 규정 준수 등 모든 측면으로 확장되어야 합니다.
주류 RWA 프로젝트에 대한 심층 분석[1]을 바탕으로, 우리는 Pharos 개발자가 아키텍처 패턴, 핵심 리스크 영역, 통합 전략의 세 가지 차원에서 견고한 RWA 애플리케이션을 구축하기 위한 주요 경로를 설명할 것입니다.
I. 파로스가 RWA에 적합한 이유는 무엇입니까?
파로스는 인터넷 규모 배포를 위해 설계된 레이어 1 애플리케이션입니다. RWA 개발자는 기본 합의 메커니즘에 대해 자세히 알아볼 필요 없이 자산 정산과 복잡한 계산이라는 두 가지 핵심 문제 해결에만 집중하면 됩니다.
병렬 실행 및 1초 미만 확정 속도(Block-STM): 기존 EVM은 트랜잭션을 순차적으로 처리하므로 대규모 RWA 지급이나 리밸런싱 시 쉽게 병목 현상이 발생할 수 있습니다. 파로스는 Block-STM 병렬 실행 엔진을 도입하여 1초 미만 확정 속도를 구현합니다.
이는 오프체인 자금을 수령하고 온체인 결제를 거의 동시에 완료할 수 있음을 의미하며, "T+1" 방식에서 발생하는 환율 변동 및 슬리피지 리스크 제거합니다.
Pharos는 EVM과 WASM 실행 환경을 모두 지원하는 듀얼 VM 아키텍처(EVM + WASM)를 기본적으로 지원합니다.
EVM 레이어: 연결을 담당합니다. 기존 솔리디티 대출 프로토콜 및 DEX 코드를 직접 배포하여 RWA 자산을 지원할 수 있습니다.
WASM 레이어: 연산 처리를 담당합니다. RWA는 복잡한 이자 과세, 계층형 위험 관리, 규정 준수 화이트리스트 로직을 포함하는데, 이는 EVM에서 매우 높은 가스 소모를 유발하고 비효율적입니다. 이러한 연산 집약적인 로직을 WASM 모듈 로 마이그레이션하면 고성능 저비용 온체인 위험 관리를 구현할 수 있습니다.
https://docs.pharosnetwork.xyz
II. RWA의 두 가지 운영 논리
파로스(Pharos)에서 RWA 프로토콜을 설계하기 전에 개발자는 두 가지 주요 자산 이전 모델과 자금 조달 루프를 명확히 해야 합니다.
온체인 에서 오프체인 모드로
현재 가장 일반적인 모델은 온체인 자금 조달과 오프체인 자산 관리를 결합한 방식입니다. 투자자는 온체인 스테이블코인(예: USDC)을 스테이킹, 프로젝트 팀은 이를 수집하여 법정화폐(USD)로 전환한 후, 유동성이 높은 오프체인 자산(예: 미국 국채)에 투자합니다. 이렇게 발생한 이자는 온체인 다시 유입되어 토큰 보유자에게 분배됩니다.
사례 연구: Matrixdock의 $STBT. 공인 투자자들은 $STBT(단기 미국국채 와 1:1로 연동) 민트 , 프로젝트 팀은 이 자금을 사용하여 국채를 매입합니다. 온체인 보유자는 연평균 약 4.8%의 수익률을 누립니다.
자산 온체인 모델
이 모델은 특정 자산의 증권화 및 분산에 초점을 맞춥니다. 프로젝트 팀은 특정 오프체인 자산(예: 부동산)을 예치하고 가치를 평가한 후, 이에 상응하는 ERC-20 점유율 을 발행합니다. 투자자들은 스테이블코인으로 투자에 참여하고, 프로젝트 팀은 오프체인 자산의 유지 및 운영을 담당합니다. 이렇게 발생한 현금 흐름(예: 임대료)은 정기적으로 온체인 배당금으로 분배됩니다.
사례 연구: RealT의 부동산 토큰화. 예를 들어, 디트로이트에 있는 65,900달러 상당의 부동산은 1,300개의 토큰으로 분할될 수 있으며, 토큰을 구매한 투자자는 해당 부동산에서 발생하는 임대 수익의 일부를 받을 권리가 있습니다.
III. 리스크 지도 작성 및 파로스 통합 전략
RWA의 치명적인 리스크 코드 자체에 있는 것이 아니라 오프체인과 온체인 메커니즘 간의 연결에 있는 경우가 많습니다. 기존 RWA 프로젝트들은 인증, 자산 고정, 데이터 투명성 측면에서 심각한 구조적 결함을 가지고 있습니다. 파로스(Pharos)에서 애플리케이션을 개발하는 개발자는 다음과 같은 회색 코뿔소 리스크 에 대한 방어에 집중해야 합니다.
https://dl.acm.org/doi/epdf/10.1145/3689931.3694913
신원 정보 규정 준수 침투
규정 준수를 주장하는 프로젝트들은 형식적인 절차에 그치는 경우가 많습니다. 통계에 따르면 효과적인 KYC(고객 신원 확인) 절차를 시행하는 프로젝트는 절반에도 미치지 못하며, RealT와 같은 유명 프로젝트조차도 영상 인증 절차가 사진 한 장만으로 쉽게 우회되는 사례가 있습니다. 일부 프로젝트는 백서 에서 AML(악성코드 방지 및 클라우드 컴퓨팅)을 강조하지만, 실제로는 지갑 연결만으로 거래가 완료되어 자금 출처 추적이 완전히 불가능한 경우가 많습니다.
https://dl.acm.org/doi/epdf/10.1145/3689931.3694913
파로스 개발 권장 사항:
웹페이지 프런트엔드에서만 신원 확인을 수행해서는 안 됩니다. 스마트 계약 계층에 화이트리스트 메커니즘을 통합하여 DID(탈중앙화 신원) 또는 오프체인 KYC를 통해 검증된 주소만 발행 또는 이체 기능을 호출할 수 있도록 해야 합니다. 예를 들어 $STBT를 사용할 경우, ERC-20 이체 및 transferFrom 함수를 재작성하여 인증된 화이트리스트 주소만 호출할 수 있도록 해야 합니다.
https://etherscan.io/address/0x530824da86689c9c17cdc2871ff29b058345b44a#code
고액 자산 거래의 경우, 개인 키 유출로 인한 자산 도난을 방지하기 위해 2단계 인증(2FA) 메커니즘을 도입해야 합니다. 연구에 따르면 현재까지 이를 구현한 프로젝트는 소수에 불과합니다.
스테이블코인과 서킷 브레이커에 대한 의존성
스테이블코인은 RWA의 생명줄이며, 거의 90%의 프로젝트가 결제에 스테이블코인을 사용하고 있습니다. 그러나 개발자는 SVB 사건으로 인한 USDC 리스크 이나 USDe [2]와 같은 스테이블코인에 내재된 디커플링 리스크 간과하는 경우가 많습니다. 디커플링이 발생할 경우, 프로젝트는 위기를 처리하기 위한 전용 리스크 준비금을 보유하고 있습니까?
https://x.com/ethena_labs/status/1976773136294224071
파로스 개발 권장 사항:
오라클 가격 정보 제공뿐만 아니라 위험 관리 트리거로도 사용되어야 합니다. 결제 통화로 사용되는 스테이블코인(예: USDC/USDT)의 가격이 고정 가격에서 임계값(예: 5%) 이상 벗어나면, 계약은 자동으로 민트 및 상환을 중단하여 프로토콜이 차익거래 공격을 받는 것을 방지해야 합니다.
유동성 풀을 설계할 때는 단일 자산으로 인한 시스템 리스크 의 영향을 완화하기 위해 여러 스테이블코인 또는 통화 바스켓을 지원하는 방안을 고려해야 합니다. 동시에 복잡한 메커니즘을 가진 알고리즘 스테이블코인은 분리될 가능성이 가장 높으므로 피해야 합니다.
데이터 연결 및 진위 검증
RWA를 둘러싼 가장 큰 블랙박스는 온체인 자산이 오프체인 물리적 자산과 실제로 일치하는지 여부입니다. 많은 프로젝트들이 소위 정보 공개라고 하는 것은 웹사이트에 게시된 몇 개의 PDF 파일에 불과하며, 심지어 실시간 모니터링인 것처럼 가장하기 위해 반복 재생되는 비디오 녹화물을 사용하는 황당한 사례도 있었습니다. 오픈에덴의 순자산가치 보고서 또한 최대 한 달까지 지연되었습니다.
https://dl.acm.org/doi/epdf/10.1145/3689931.3694913
파로스 개발 권장 사항:
체인링크와 같은 오라클 네트워크를 활용하여 오프체인 수탁 은행이나 감사 법인의 API에 직접 연결하십시오. 파로스 개발자는 프로젝트 팀의 월별 또는 분기별 보고서에 의존하기보다는 순자산가치(NAV)를 분 단위로 온체인에 기록하는 데 집중해야 합니다.
프로젝트 가치 평가 불일치는 반복적으로 발생하는 리스크 입니다. 개발 단계에서는 온체인 가격이 오프체인 시장 상황을 최대한 정확하게 반영하도록 여러 소스의 오라클 가격 피드를 도입해야 합니다.
법인격의 분리와 투명성
오프체인 자산 디폴트는 RWA가 무시할 수 없는 리스크 입니다. 예를 들어, Goldfinch는 한때 590만 달러의 신용 디폴트를 겪었습니다.[4] 리스크 분리하는 핵심은 SPV에 있지만, SPV 구조를 사용한다고 공개적으로 밝힌 프로젝트는 소수에 불과하며, 대부분은 구체적인 등록 법인명을 공개하지 않았습니다. Goldfinch 사태를 예로 들면, 이는 토큰 가격을 20% 하락시켜 투자자들이 아무 이유 없이 심각한 손실을 입게 했습니다.
파로스 개발 권장 사항:
자산을 보유하는 특수목적법인(SPV)의 법적 명칭과 등록지는 프로젝트 메타데이터 또는 문서에 공개되어야 합니다.
각 자산 풀이 독립적인 특수목적법인(SPV)에 대응하도록 해야 합니다. 파로스(Pharos) 계약 설계에서, 서로 다른 자산 풀에 있는 자금은 논리적으로 완전히 분리되어야 단일 자산의 디폴트로 인해 전체 프로토콜의 유동성이 고갈되는 사태를 방지할 수 있습니다.
허황된 호황 이후 유동성 고갈
유동성은 RWA 프로젝트에서 가장 쉽게 조작할 수 있는 거래상황 이지만, 동시에 가장 쉽게 붕괴되는 측면이기도 합니다[2]. 많은 RWA 프로젝트는 출시 초기 단계에서 MM (Market Making) 보조금에 크게 의존합니다. 시장 조성자 계약이 만료되거나 보조금이 중단되면 유통시장 깊이가 급격히 감소하고 매수 주문이 즉시 사라지는 경우가 많습니다. 또한, 오프체인 자산 평가 빈도(일반적으로 월별 또는 분기별 순자산가치)가 낮은 반면 온체인 거래 빈도(2차 블록 생성)는 높은 자연스러운 시간 불일치가 존재합니다. 온체인 대량 매도가 발생하면 실시간 공정 가치 지침 부족으로 인해 AMM 풀이 빠르게 보충되지 못하여 가격이 순가치에서 크게 벗어나 유동성 블랙홀이 형성됩니다. 예를 들어, 아래 그림에서와 같이 급락으로 인해 토큰 가격이 몇 시간 만에 1달러에서 0.5달러로 급락했습니다[5].
https://www.blocktempo.com/not-so-tangible-usdr-stablecoin-collapses/
파로스 개발 권장 사항:
탈중앙화 거래소(DEX)나 중앙화 거래소(CEX)의 유통시장 에 모든 유동성을 걸고 도박을 하지 마세요. 개발자는 스마트 계약에 환매/매수 대기열을 구축할 수 있습니다. 유통시장 가격이 순자산가치(NAV)보다 현저히 낮을 경우(예: 3% 이상 할인), 보유자는 유통시장 거치지 않고 SPV의 기초 자산에 대한 환매 요청을 프로토콜에 직접 제출할 수 있으며, 스마트 계약이 환매 대기열 관리 및 자금 분배를 담당합니다.
전통적인 은행의 준비금 제도를 따라, 스테이블코인 발행 과정에서 일정 비율(예: 5~10%)이 온체인 유동성 완충 장치로 강제로 적립됩니다. 이 자금은 오프체인 자산을 매입하는 데 사용되지 않고, 유통시장 유동성이 고갈될 때 가격 하한선을 유지하기 위해 스마트 계약을 통해 즉시 매입을 자동 실행하는 데 사용됩니다.
EVM 고유 리스크
Pharos는 EVM과 완벽하게 호환되므로 개발자는 Solidity 생태계의 편리함을 누리면서도 기존의 공격 벡터를 그대로 계승할 수 있습니다. 규제 요건으로 인해 RWA 계약에는 일반적으로 블랙리스트, 강제 전송, 일시 중지 등과 같은 높은 권한이 필요한 기능이 대량 포함되어 있어 권한 관리 및 프록시 상승이 DeFi 프로토콜보다 훨씬 더 민감하고 치명적인 취약점이 됩니다.
https://owasp.org/www-project-smart-contract-top-10/
파로스 개발 권장 사항:
표준 라이브러리를 엄격히 준수하십시오. 불필요한 자체 개발은 피해야 합니다. 접근 제어는 OpenZeppelin의 AccessControl 또는 Ownable2Step을 사용해야 합니다. 사용자 정의 로직의 취약점으로 인해 RWA 관리자 개인 키가 도난당할 경우, 오프체인 물리적 자산의 소유권과 관련된 법적 분쟁이 발생할 수 있습니다.
에이전트 업그레이드 위험 관리: RWA 계약은 대부분 업그레이드 가능합니다(UUPS/Transparent). 업데이트를 배포할 때 종속 변수 덮어쓰기로 인한 자산 매핑 오류를 방지하기 위해 스토리지 슬롯 충돌을 엄격하게 확인해야 합니다.
재진입 공격 방어: 분배 수익 또는 상환 로직을 처리할 때, 화이트리스트에 등록된 사용자라 하더라도 악의적인 계약이 콜백 함수를 이용하여 자금 풀을 고갈시키는 것을 방지하기 위해 모든 외부 호출에 ReentrancyGuard를 추가해야 합니다.
IV. 요약
실시간 자산관리(RWA) 부문의 발전 과정을 되돌아보면, 사용자 인터페이스(UI) 기반의 규정 준수와 유동성 유지를 위한 시장 조성에 힘입어 허황된 번영을 이룩한 사례를 너무나 많이 보아왔습니다. 파로스(Pharos) 생태계 내에서 우리는 보다 탄력적인 발전 패러다임을 지향합니다.
개발자로서 우리 는 RWA(반응형 자산 자산)의 보안 리스크 스마트 계약 코드 구현을 넘어선다는 점을 명심해야 합니다. 오프체인 자산 소유권 무효화 및 유동성 불일치와 같은 문제 또한 주의를 기울여야 합니다 . 파로스(Pharos)의 1초 미만 최종화 속도는 복잡한 금융 업무 처리할 수 있다는 확신을 주지만, 이를 위해서는 개발자가 통합 전략을 더욱 엄격하게 수립해야 합니다. 즉, KYC/AML(고객 신원 확인/자금세탁방지)을 기본 로직에 통합하고, 코드 내에서 리스크 준비금 메커니즘을 시행하며, 자산 데이터 투명성을 극대화해야 합니다.
RWA 프로토콜의 미래 경쟁은 더 이상 TVL(총 예치금액) 경쟁이 아니라 자산의 진위성과 시스템 안정성 경쟁이 될 것입니다. 이러한 마지막 구간을 위한 안전한 루프를 구축하는 것은 모든 파로스(Pharos) 생태계 구축자에게 필수적인 과제입니다.
