Reserve는 모든 바스켓을 받치는 하나의 보험기금을 만들지 않았다. 대신 어디로든 옮길 수 있는 고정 공급 토큰을 만든 뒤 선택의 대가를 배포별로 묶었다. RSR을 한 Yield DTF에 스테이킹하면 그 풀의 의결·수익 설정을 받아들이는 동시에 담보 부실 때 가장 먼저 소진될 자본이 된다.
현행 RSR 계약 0x320623…d70은 2022년 1월 13일 구 0x8762… 토큰을 대체했다. 잔액은 필요할 때 새 계약에 기록하는 지연 복사(copy-on-write) 방식으로 이어졌으므로 새 계약에서 Transfer 이벤트가 생기기 전에도 잔액이 존재할 수 있었다. 저장소는 총량을 1,000억 개로 고정하고 포크 계약을 업그레이드할 수 없다고 명시한다.
설정 기간에는 소유자와 일시 중지 담당자가 이전을 통제했다. 공개된 절차는 포크 뒤 두 역할을 0 주소로 바꾸는 것으로 끝난다. 이는 독립 ERC-20의 관리 권한을 제거한 것이며, 이후 배포된 RToken의 거버넌스·실행 대기 장치·일시 중지·동결 권한은 별개로 남는다.
RToken, 현재 명칭으로 Yield DTF는 자기 담보 바스켓을 기준으로 발행된다. BackingManager가 자산을 보관하고, RToken 보유자는 정상 상태에서 토큰을 태워 비례 담보를 받는다. RSR은 그 자산을 나타내지도, 그 자산으로 상환되지도 않는다.
보유자가 특정 stRSR 계약을 골라야 RSR이 그 DTF의 손실 위험에 노출된다. 그 풀은 설정된 수익을 받고, 일반적인 배포에서는 해당 DTF 의결권도 위임할 수 있다. 다른 DTF에는 별도의 풀과 담보, 거버넌스가 있다.
따라서 어떤 stRSR 풀의 높은 표시 수익률은 그 DTF의 수익과 손실 가능성을 함께 반영한다. 전체 프로토콜의 이표도 아니고 유동 RSR 보유자 전원에게 약속된 분배도 아니다.
담보가 부실해지면 시스템은 남은 자산을 목표 바스켓으로 교환한다. 필요한 RSR 매각량이 BackingManager 보유분을 넘으면 코드는 선택된 StRSR의 seizeRSR을 호출한다. 프로토콜은 이렇게 손실을 먼저 부담한 예치자에게 해당 금액의 보상을 보장하지 않는다.
손실은 풀 전액에 이를 수 있으며 회수된 물량만큼 의결권도 줄어든다. 예상 가능한 부실이나 바스켓 교체 직전에 빠져나가기 어렵도록 스테이킹 해제에는 대기 시간이 있다. 참조 배포는 1,209,600초, 즉 2주와 메인넷 withdrawalLeak 5%를 쓴다. 이 기준은 누적 출금 비율이 넘으면 자산 상태를 갱신하도록 하는 설정이다. 실제 DTF의 값은 따로 확인해야 한다.
발행 일시 중지는 신규 발행을, 거래 일시 중지는 담보·수익 관리를 멈춘다. 동결은 상환을 포함한 대부분의 작업을 중단한다. 상태표는 그동안에도 거버넌스 기능을 유지하며, 악성 제안에 맞설 투표력을 보탤 수 있도록 동결 중 신규 스테이킹도 허용한다.
따라서 담보 목록과 함께 누가 변경을 실행하는지도 봐야 한다. 핵심 계약들은 공통 관리 권한 아래에서 업그레이드되며, 거버넌스가 우선 사용하는 담보 구성인 기본 바스켓과 운영 설정을 정하고 BackingManager가 거래한다. 특정 DTF를 평가할 때는 그 배포의 의사결정 주체, 실행 전 대기 시간, 권한 보유자를 확인해야 한다.
공식 자료는 1,000억 개 상한에는 동의하지만 풀린 물량에는 합의하지 못한다. Core Components는 여전히 535억 개, FAQ와 RSR 개요는 약 60%라고 쓴다. 프로젝트 통제 Slow·Slower 지갑, 4주 지연, 비트코인과 비슷한 감소형 방출 정책도 함께 설명한다.
이 문서들은 보관·정책의 경계를 보여줄 뿐 정확한 실시간 유통량이나 공개 보유자에 대한 법적 약속을 만들지 않는다. 이용약관도 RSR과 DTF를 실험적이고 무보험이며 ABC Labs·은행·정부가 보장하지 않는 자산으로 규정한다. 이 설명은 토큰과 프로토콜이 제공하는 기능의 범위다. 적용 법률이나 별도 계약에서 생길 수 있는 모든 권리까지 판단한 것은 아니다.
활성화 전에 새 RSR 토큰 코드를 다룬 감사 보고서가 작성된다.
구 토큰이 정지되고 잔액이 고정 공급 포크 계약으로 이동하기 시작한다.
서로 다른 담보 바스켓·스테이킹 풀·거버넌스 도메인이 실제 프로토콜 구조가 된다.
프로젝트 자료는 4주 지연과 4주마다 총공급량 최대 1% 제한을 설명한다.
마지막 근거 검토: 2026-09-05
Reserve Rights(RSR)는 Reserve의 여러 자산 바스켓 주변에서 쓰이는 총 1,000억 개 고정 공급 이더리움 토큰이다. 유동 RSR은 전송 가능한 토큰일 뿐이다. 특정 Yield DTF의 stRSR 계약에 예치하면 해당 풀의 1차 손실 부담 자본이 되고, 그 DTF의 의결권과 설정된 수익 배분을 받을 수 있다. 담보와 상환 구조를 가진 RToken/Yield DTF는 별도 자산이다.
“Reserve”라는 이름 아래에는 전혀 다른 세 장부가 있다. 전역 RSR 공급, DTF별 BackingManager 담보, DTF별 stRSR 풀이다. 이를 하나로 보면 모든 RSR 보유자가 모든 담보를 소유하고 모든 수수료를 받으며 스테이블 자산으로 상환할 수 있다는 잘못된 결론이 나온다. 실제 설계는 위험과 통제를 배포 단위로 격리한다.
사용자는 담보 바스켓을 넣어 RToken을 발행하고, 상환이 허용된 상태에서는 이를 소각해 현재 담보를 비례 배분받는다. 수익 처리 계약 RevenueTrader는 설정된 잉여를 소각 담당 Furnace와 선택된 stRSR 풀로 보낸다. 담보 부실 뒤 자산 관리 계약 BackingManager가 일반 자산으로 부족분을 복구하지 못하면 seizeRSR 함수를 호출해 해당 풀의 RSR을 회수하고 경매한다.
각 RToken에는 의사결정을 맡는 거버넌스, 결정 실행 전 대기 시간을 두는 타임락, 특정 작업의 일시 중지와 광범위한 동결을 담당하는 권한자가 따로 있다. 독립 RSR 토큰의 소유자와 일시 중지 담당자 주소는 2022년 포크 뒤 0 주소로 바뀌었지만, 그것이 RToken별 권한까지 없앤 것은 아니다.
아니다. 특정 Yield DTF 풀에 RSR을 스테이킹해야 1차 손실 부담이 시작되고, 그 지분은 선택한 배포만 보호한다.
그렇다. 현행 문서는 해당 DTF의 담보 복구에 필요하면 풀의 최대 100%를 슬래싱할 수 있다고 설명한다.
계약 상태가 허용할 때 RToken을 태워 그 바스켓의 현재 담보를 비례 배분받는다. 유동 RSR에는 이런 담보 상환권이 없다.
각 RToken의 거버넌스 또는 소유자가 업그레이드와 운영 설정을 통제하며, 타임락은 결정과 실행 사이에 대기 시간을 둔다. 별도의 일시 중지·동결 담당자는 정해진 작업을 멈출 수 있다. 그동안에도 거버넌스는 수정과 복구를 진행할 수 있다.
총량은 1,000억 개로 고정됐지만 공식 페이지가 535억 개와 약 60%로 충돌한다. 이 글은 어느 반올림 수치도 정밀한 실시간 잔액으로 바꾸지 않는다.
아니다. Solidified는 2022년 RSR 포크를, 다른 업체들은 프로토콜 버전을 검토했지만 담보·오라클·경매·거버넌스·연동 위험은 남는다.
Reserve Rights 실시간 시세 및 거래소 확인:
