> ## Documentation Index
> Fetch the complete documentation index at: https://stablelabs.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# USDT as Gas

> USDT0가 Stable의 네이티브 가스 토큰으로 기능하여 예측 가능한 거래 수수료를 제공하는 방식.

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 토큰 컨트랙트 주소:

* 테스트넷: [0x78cf24370174180738c5b8e352b6d14c83a6c9a9](https://testnet.stablescan.xyz/token/0x78cf24370174180738c5b8e352b6d14c83a6c9a9)
* 메인넷: [0x779ded0c9e1022225f8e0630b35a9b54be713736](https://stablescan.xyz/token/0x779ded0c9e1022225f8e0630b35a9b54be713736)

## 용어

* **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`를 계산할 때 안전 마진을 포함해야 합니다.

예시(설명용):

```javascript theme={"dark"}
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 금지된 패턴: 미러 잔액 회계

컨트랙트는 네이티브 잔액을 미러링하기 위해 내부 변수에 의존해서는 안 됩니다.

안전하지 않은 패턴의 예:

```solidity theme={"dark"}
uint256 public deposited;

function deposit() external payable {
  deposited += msg.value;
}
```

허용 기반 전송을 통해 USDT0이 고갈되면 이러한 변수는 실제 네이티브 잔액과 달라질 수 있습니다.

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

모든 네이티브 가치 전송은 전송 직전에 `address(this).balance`를 사용하여 지불 능력을 확인해야 합니다.

예시:

```solidity theme={"dark"}
require(address(this).balance >= amount, "insufficient balance");
```

출금은 Checks-Effects-Interactions 순서를 따라야 합니다:

```solidity theme={"dark"}
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`에 의존하여 주소가 한 번도 사용되지 않았다고 추론해서는 안 됩니다.

주소 사용에 대한 모든 개념은 컨트랙트 상태 내에서 명시적으로 추적되어야 합니다.

예시:

```solidity theme={"dark"}
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`를 네이티브 토큰 식별자로 사용해야 합니다.