ERC-8161 이전 가능한 토큰화 금고 요청 (Transferable Tokenized Vault Requests)
Final · 금고·DeFi · 2025-02-12 작성
비동기 금고(ERC-7540)에서 처리를 기다리는 입금·상환 요청을 다른 주소로 통째로 넘길 수 있게 하는 선택 확장입니다.
왜 필요한가
비동기 토큰화 금고 표준인 ERC-7540에서는 입금이나 상환을 요청하면 금고가 처리할 때까지 대기(Pending) 상태로 머뭅니다. 이 대기 기간이 길어질 수 있는데, 그동안 요청의 소유자(컨트롤러)는 자신의 대기 중인 자리를 다른 주소로 옮길 방법이 없습니다. 지갑을 새 주소로 옮기고 싶은 사용자, 여러 계정 사이에서 포지션을 재배치하려는 사용자, 대기 중인 요청 포지션 위에 기능을 얹으려는 프로토콜 모두에게 걸림돌이 됩니다. 기존에는 요청을 취소하고 새 주소에서 다시 제출하는 수밖에 없었습니다. 이 표준은 대기 중인 요청 자체를 이전할 수 있게 해서 대기 포지션의 2차 시장 유동성을 열고 계정 관리를 단순하게 만듭니다.
심층 설명
transferDepositRequest의 필수 규칙
입금 요청 이전을 지원하는 금고는 IERC7540DepositTransferable 인터페이스를 구현해야 합니다(MUST). transferDepositRequest는 해당 requestId의 대기 중인 입금 요청 잔액 전체를 oldController에서 newController로 옮깁니다. 대기(Pending) 잔액만 옮겨야 하고 수령 가능(Claimable) 잔액은 건드리면 안 됩니다(MUST NOT). 이전이 성공하면 pendingDepositRequest(requestId, oldController)는 이전된 양만큼 줄고 pendingDepositRequest(requestId, newController)는 같은 양만큼(수수료가 있으면 그만큼 뺀 값) 늘어야 합니다. msg.sender는 oldController 본인이거나 oldController가 승인한 오퍼레이터여야 하며 TransferDepositRequest 이벤트를 반드시 발생시켜야 합니다.
transferRedeemRequest의 필수 규칙
상환 요청 이전을 지원하는 금고는 IERC7540RedeemTransferable 인터페이스를 구현해야 합니다(MUST). 규칙은 입금 쪽과 대칭입니다. 대기 중인 상환 요청 잔액 전체를 oldController에서 newController로 옮기되 Pending 잔액만 대상이고 Claimable 잔액은 영향받지 않아야 합니다. 성공하면 pendingRedeemRequest(requestId, oldController)가 줄고 pendingRedeemRequest(requestId, newController)가 같은 양만큼(수수료 제외) 늘어야 합니다. msg.sender 제한과 TransferRedeemRequest 이벤트 발생 의무도 동일합니다.
ERC-165 인터페이스 식별
이 표준을 구현하는 컨트랙트는 ERC-165의 supportsInterface 함수를 반드시 구현해야 합니다. IERC7540DepositTransferable을 구현한 금고는 interfaceID로 0x53b3bb0a가 들어오면 true를 반환해야 하고 IERC7540RedeemTransferable을 구현한 금고는 0x7846f5bd에 대해 true를 반환해야 합니다. 통합하는 쪽은 이 값으로 금고가 어느 쪽 이전을 지원하는지 미리 확인할 수 있습니다.
왜 Pending 잔액만 옮기는가
이 표준은 일부러 이전 대상을 대기(Pending) 상태로 제한합니다. 수령 가능(Claimable) 잔액은 이미 교환 비율이 확정되어 있고 컨트롤러가 언제든 수령할 수 있으므로, 이것까지 이전하게 하면 큰 이득 없이 복잡도만 늘어납니다. Pending으로 범위를 좁히면 인터페이스가 단순해지고 부분적으로만 수령 가능한 경우 같은 경계 상황을 피할 수 있습니다.
입금과 상환을 별도 인터페이스로 나눈 이유
ERC-7540이 입금 흐름과 상환 흐름을 각각 선택 사항으로 둔 설계 철학을 따라, 이 표준도 입금 이전과 상환 이전을 별도 인터페이스로 둡니다. 금고마다 한쪽만 허용할 타당한 이유가 있을 수 있습니다. 예를 들어 자산이 잠겨 있는 대기 입금 요청의 이전은 허용하되, 지분이 이미 소각되거나 특정 회계 처리와 얽혀 잠긴 대기 상환 요청의 이전은 막는 금고가 있을 수 있습니다.
부분 이전 없이 전체 잔액만 이전
transferDepositRequest와 transferRedeemRequest는 일부 금액을 지정하는 대신 대기 잔액 전체를 이전합니다. 인터페이스가 단순해지고 같은 requestId의 요청들이 서로 대체 가능(fungible)하다고 보는 ERC-7540 모델과도 맞습니다.
기존 ERC-7540 금고와의 호환성
이 표준은 ERC-7540과 완전히 하위 호환됩니다. 이 확장을 구현하지 않은 금고는 이전과 똑같이 동작하며 통합하는 쪽은 ERC-165 supportsInterface로 이전 기능 지원 여부를 감지할 수 있습니다. 원문 상태는 Final로 확정된 표준입니다.
쓸 때 주의할 점
- 오퍼레이터 권한의 범위: ERC-7540과 마찬가지로 컨트롤러가 승인한 오퍼레이터는 컨트롤러 대신 대기 요청을 이전할 수 있습니다. 오퍼레이터 권한을 주면 잠긴 자산이나 지분을 임의의 주소로 옮겨 컨트롤러의 통제 밖으로 보낼 수 있는 능력까지 넘어간다는 점을 사용자가 알아야 합니다.
- 대기 요청에는 기준 가격이 없음: 금고 지분은 convertToShares와 convertToAssets라는 온체인 가격 기준이 있지만 대기 중인 요청은 내장된 가격 산정 수단이 없습니다. 교환 비율은 요청이 처리되기 전까지 알 수 없습니다. 이전 가능한 요청으로 2차 시장을 만드는 쪽은 공식 가격 출처가 없다는 점을 가격 산정과 정산 설계에 반영해야 합니다.