메인 콘텐츠로 건너뛰기
Stable은 USDT 스테이블코인을 중심으로 구축되었습니다. USDT의 옴니체인 표현인 USDT0은 Stable 생태계를 지원하는 핵심 자산입니다.

​
요약

Stable은 USDT0을 네이티브 가스 토큰으로 사용하는 EVM 호환 블록체인입니다. USDT0은 가스 지불 및 가치 전송을 위한 네이티브 자산이면서 동시에 approve, transfer, transferFrom 및 permit를 지원하는 ERC20 토큰으로 기능합니다. 이 설계는 예측 가능한 달러 표시 트랜잭션 비용을 가능하게 하고 사용자 경험을 단순화합니다. 그러나 이는 잔액 의미론, 허용 안전성 및 특정 opcode 가정에 영향을 미치는 이더리움과의 행동 차이를 도입합니다. 본 문서는 Stable의 USDT0 가스 메커니즘을 명시하고, 결과적인 행동 차이를 설명하며, Stable에 배포된 스마트 컨트랙트에 필요하고 권장되는 개발 패턴을 정의합니다.

​
버전 참고사항

Stable v1.2.0에서 USDT0이 gUSDT를 대체하여 Stable의 네이티브 가스 토큰이 됩니다. 이 전환의 일부로:
  • gUSDT가 폐지됩니다.
  • 기존 gUSDT 잔액이 자동으로 USDT0으로 전환됩니다.
  • 사용자와 애플리케이션은 더 이상 수수료를 지불하거나 가치를 이동하기 위해 래핑 및 언래핑 플로우가 필요하지 않습니다.
v1.2.0 이후 USDT0은 다음 두 가지 역할을 합니다:
  • 네트워크 수수료 자산(가스), 그리고
  • approve, permit, transfer 및 transferFrom을 갖춘 표준 ERC20 토큰.

​
네트워크 주소

USDT0 토큰 컨트랙트 주소:

​
용어

  • Stable: USDT0이 네이티브 가스 토큰인 EVM 호환 블록체인.
  • USDT0: USDT의 옴니체인 버전으로 다음 두 가지로 기능합니다:
    • 가스 및 가치 전송에 사용되는 네이티브 자산, 그리고
    • approve 및 permit 기능을 가진 ERC20 토큰.
  • 네이티브 잔액: address(x).balance로 반환되는 USDT0으로 표시된 잔액.
  • 가스 수수료: EIP-1559 스타일 수수료 시장에서 계산된 USDT0으로 지불하는 트랜잭션 수수료.

​
USDT0이란 무엇인가?

USDT0은 LayerZero의 옴니체인 대체 가능 토큰 (OFT) 표준을 사용하는 USDT의 옴니체인 표현입니다. USDT0은 USDT와 1:1로 페깅되어 있으며 전통적인 브리지 워크플로우나 래핑된 표현 없이 여러 블록체인을 이동하도록 설계되었습니다. 체인 간에 USDT0을 전송할 때, 토큰은 일부 소스 체인에서 잠기거나(체인의 네이티브 USDT 지원에 따라) 소각된 후 LayerZero의 크로스체인 메시징을 통해 목적지 체인에서 발행됩니다. 이는 1:1 페그를 유지하면서 유동성을 분산된 체인 로컬 풀이 아닌 단일 상호 운용 가능한 자산으로 통합합니다. 사용자에게 이는 더 빠른 온보딩, 운영 복잡성 감소 및 향상된 유동성 이동성을 가능하게 합니다.

​
USDT0과 Stable

USDT0은 Stable의 온체인 경제와 일상적인 사용을 지원하는 핵심 자산입니다. 동일한 자산이 수수료 지불과 가치 전송 모두에 사용되기 때문에 Stable은 다음에 대한 마찰을 줄입니다:
  • 일반 사용자: 더 간단한 온보딩과 더 적은 토큰 개념
  • 개발자: 더 간단한 수수료 및 가치 흐름
  • 기업: 단순화된 회계 및 재무 운영
Stable은 또한 사용자가 LayerZero를 통해 다른 네트워크에서 USDT0을 온보딩할 수 있도록 하여 첫날부터 깊은 USDT 유동성에 액세스할 수 있습니다.

​
가정 및 전제 조건

아래 내용의 경우 독자는 다음을 이해해야 합니다:
  • Solidity 실행 의미론 및 네이티브 가치 전송
  • ERC20 허용 메커니즘 및 허가 플로우
  • Checks-Effects-Interactions를 포함한 표준 스마트 컨트랙트 보안 패턴

​
1. 가스 및 수수료 모델

​
1.1 개요

Stable은 모든 트랜잭션 수수료를 USDT0으로 표시합니다. 가스 가격 책정은 동적으로 조정되는 기본 수수료가 있는 EIP-1559 스타일 모델을 따릅니다. 트랜잭션 수수료는 다음과 같이 정의됩니다: 
fee = gasUsed × baseFee
트랜잭션은 표준 EIP-1559 매개변수를 사용하여 maxFeePerGas를 지정할 수 있습니다. 참고: Stable은 우선순위 팁을 지원하지 않습니다. maxPriorityFeePerGas를 설정하지 마세요. 그렇지 않으면 팁 금액이 손실됩니다.

​
1.2 트랜잭션 제출

클라이언트는 가장 최근 블록에서 최신 기본 수수료를 가져오고 maxFeePerGas를 계산할 때 안전 마진을 포함해야 합니다. 예시(설명용): 
const block = await provider.getBlock("latest");
const baseFee = block.baseFeePerGas;

const maxPriorityFeePerGas = 1n;
const maxFeePerGas = baseFee * 2n + maxPriorityFeePerGas;

​
1.3 USDT0 획득

계정은 다음을 통해 USDT0을 얻습니다:
  • 다른 지원되는 체인에서 USDT0 브리징
  • Stable의 다른 계정으로부터 전송 받기

​
2. Stable이 USDT0을 가스 토큰으로 활성화하는 방법

Stable은 사전 청구 및 환불 결산 모델을 사용하여 USDT0으로 가스를 청구합니다.

​
예시 트랜잭션

Alice가 Bob에게 100 USDT0을 보냅니다.

​
2.1 Ante-handler 단계

MonoEVMAnteHandler에서 트랜잭션 검증 중:
  1. Alice의 USDT0 잔액을 읽습니다.
  2. 프로토콜은 Alice가 다음을 커버할 수 있는지 확인합니다:
    • 트랜잭션 가치(100 USDT0), 그리고
    • 최대 가능 가스 수수료(gasWanted × fee).
  3. 최대 가스 수수료가 사전에 이체됩니다:
    • alice → fee_collector로 USDT0.

​
2.2 실행 단계

ApplyTransaction 동안:
  1. EVM이 트랜잭션을 실행합니다.
  2. 실제 가스 소비가 기록됩니다.
  3. 가치 전송이 적용됩니다:
    • alice → bob이 100 USDT0을 전송합니다.

​
2.3 결산 단계

실행 후:
  1. 프로토콜은 사전 청구된 수수료의 사용되지 않은 부분을 계산합니다: 
    refund = (gasWanted − gasUsed) × baseFee
  2. 사용되지 않은 수수료가 환불됩니다:
    • fee_collector → alice로 USDT0.

​
3. 잔액 의미론 및 행동 차이

​
3.1 네이티브 잔액 가변성

이더리움에서는 컨트랙트의 네이티브 잔액이 일반적으로 컨트랙트 실행의 결과로만 변경됩니다. Stable에서는 컨트랙트의 네이티브 USDT0 잔액이 transferFrom 및 permit를 포함한 ERC20 허용 기반 작업으로 인해 변경될 수도 있습니다. 이러한 작업은 컨트랙트 코드를 호출하지 않고도 컨트랙트의 네이티브 잔액을 줄일 수 있습니다. 결과적으로 다음 가정은 Stable에서 유효하지 않습니다:
  • 컨트랙트의 네이티브 잔액은 컨트랙트가 호출된 경우에만 감소할 수 있습니다.

​
4. 컨트랙트 설계 요구 사항

​
4.1 금지된 패턴: 미러 잔액 회계

컨트랙트는 네이티브 잔액을 미러링하기 위해 내부 변수에 의존해서는 안 됩니다. 안전하지 않은 패턴의 예: 
uint256 public deposited;

function deposit() external payable {
  deposited += msg.value;
}
허용 기반 전송을 통해 USDT0이 고갈되면 이러한 변수는 실제 네이티브 잔액과 달라질 수 있습니다.

​
4.2 필수 패턴: 실제 잔액 지불 능력 확인

모든 네이티브 가치 전송은 전송 직전에 address(this).balance를 사용하여 지불 능력을 확인해야 합니다. 예시: 
require(address(this).balance >= amount, "insufficient balance");
출금은 Checks-Effects-Interactions 순서를 따라야 합니다: 
uint256 amount = credit[msg.sender];
credit[msg.sender] = 0;

require(address(this).balance >= amount);
payable(msg.sender).call{value: amount}("");

​
4.3 상태 진행은 잔액과 독립적이어야 함

진행, 마일스톤 또는 완료 조건에 의존하는 프로토콜 로직은 카운터나 에포크와 같은 비잔액 상태 변수를 사용하여 명시적으로 추적해야 합니다. 네이티브 잔액은 지불 시점의 지불 능력 확인에만 사용되어야 합니다.

​
4.4 허용 노출

사용자 자금을 보관하는 컨트랙트는 외부 주소에 USDT0 허용을 부여해서는 안 됩니다. 허용이 불가피한 경우 컨트랙트는:
  • 정확한 금액만 승인
  • 사용 후 즉시 허용 재설정
  • 잔여 고갈 위험을 알려진 제한 사항으로 처리

​
5. 주소 상태 가정

​
5.1 EXTCODEHASH

컨트랙트는 EXTCODEHASH(addr) == 0x0에 의존하여 주소가 한 번도 사용되지 않았다고 추론해서는 안 됩니다. 주소 사용에 대한 모든 개념은 컨트랙트 상태 내에서 명시적으로 추적되어야 합니다. 예시: 
mapping(address => bool) public used;

​
6. 제로 주소 처리

Stable에서:
  • address(0)으로의 native value 전송은 실패합니다.
  • address(0)으로의 ERC20 USDT0 전송도 실패합니다.
제로 주소로 전송하여 USDT0을 소각하는 지원되는 메커니즘은 없습니다. 컨트랙트는 다음을 해야 합니다:
  • address(0)을 수신자로 명시적으로 거부
  • 제로 주소 소각을 가정하는 모든 로직을 재설계
  • 되돌릴 수 없는 손실 의미론이 필요한 경우 명시적 싱크 컨트랙트 사용

​
7. 테스트 요구 사항

Stable 배포를 위한 테스트 스위트에는 다음이 포함되어야 합니다:
  • 허용 기반 고갈 시나리오 (approve + transferFrom)
  • 실제 네이티브 잔액을 사용한 지불 능력 시행
  • EXTCODEHASH에 의존하지 않는 주소 사용 로직
  • 제로 주소 전송에 대한 명시적 실패 케이스

​
8. 마이그레이션 체크리스트

이더리움에서 Stable로 컨트랙트를 마이그레이션 할 때:
  • 컨트랙트 내부에서 변수로 네이티브 잔액을 미러링하는 로직 제거
  • 모든 지불 능력 확인을 address(this).balance로 교체
  • address(0)으로의 모든 네이티브 또는 ERC20 전송 제거
  • 모든 USDT0 approve에 대한 검사
  • approve 및 permit 기반 플로우를 다루는 테스트 추가

​
9. 요약

Stable의 USDT0을 가스 토큰으로 사용하면 예측 가능한 수수료와 통합 가치 회계를 제공하는 동시에 네이티브 잔액 동작에 대한 핵심 가정을 변경합니다. Stable에서의 올바른 컨트랙트 설계는 다음을 필요로 합니다:
  • USDT0을 이중 역할 자산으로 처리
  • 실제 잔액에 대한 지불 능력 시행
  • approve 기반 잔고 고갈 경로 회피
  • Ethereum invariant에 의거한 잔고에 대한 의존성 제거

​
FAQ

현재 USDT0을 래핑된 네이티브 토큰으로 사용하고 있습니다. 업그레이드 후에는 어떤 토큰을 래핑된 네이티브로 처리해야 하나요? 업그레이드 후 USDT0은 네이티브 토큰이자 ERC-20 토큰이 됩니다. USDT0을 직접 사용해야 하며, 래핑이나 언래핑은 더 이상 필요하지 않습니다. 원래 USDT0 컨트랙트 주소(0x779Ded0c9e1022225f8E0630b35a9b54bE713736)는 어떻게 되나요? 아무것도 변경되지 않습니다. 동일한 주소가 유효하며 계속해서 USDT0을 나타냅니다. 업그레이드 후, 네이티브 토큰 주소는 0x779Ded0c9e1022225f8E0630b35a9b54bE713736인가요 (0x0000000000000000000000000000000000001000 대신)? 예. 업그레이드 후 네이티브 토큰 식별자/주소는 0x779Ded0c9e1022225f8E0630b35a9b54bE713736 입니다. 0x0000000000000000000000000000000000001000은 어떻게 되나요? 여전히 gUSDT의 토큰 주소로 사용되며, 우리 측에서 유지해야 하나요? 아니요. 제거할 수 있습니다. 업그레이드 후에는 사용되지 않습니다. DEX calldata의 경우, 프로토콜이 “네이티브 토큰” 식별자로 0x0000000000000000000000000000000000001000 사용을 중단하고 대신 0x779Ded0c9e1022225f8E0630b35a9b54bE713736를 사용하게 되나요? 맞습니다. 업그레이드 후 DEX는 0x779Ded0c9e1022225f8E0630b35a9b54bE713736를 네이티브 토큰 식별자로 사용해야 합니다.