# Stable

> Explore Stable docs to integrate stablecoin payments, liquidity, and infrastructure securely into your platform.

## Docs

- [Stable에 오신 것을 환영합니다](/ko): **스테이블(Stable)의 공식 문서에 오신 것을 환영합니다.**
- [Brand Kit](/ko/resources/brand-kit): 아래에서 Stable 브랜드 키트를 확인하실 수 있습니다. 이 키트에는 다양한 형식의 로고와 컬러 팔레트가 포함되어 있으며, 프로젝트나 커뮤니케이션에서 Stable의 브랜딩을 일관되게 유지할 수 있도록 설계되었습니다.
- [공식 링크](/ko/resources/official-links): 웹사이트: [https://stable.xyz](https://stable.xyz)
- [FAQ](/ko/introduction/faq): **Stable이란 무엇인가요?**
- [사용자들을 위한 Stable](/ko/introduction/stable-for-users): Stable은 각각의 사용자 그룹(기관, 사용자, 개발자)에 맞춘 기능을 통해 금융 효율성을 높이고 비즈니스 운영을 최적화합니다.
- [기술 로드맵](/ko/introduction/technical-roadmap): 사용자가 트랜잭션을 제출하기부터 결과를 받기까지의 라이프사이클은 여러 단계로 구성됩니다. 우선 트랜잭션은 RPC를 통해 전파되고, 멤풀에 저장되며, 블록에 포함된 다음, 합의를 통해 검증되고 실행되어, 마침내 데이터베이스에 결과 상태가 저장됩니다. 이러한 단계를 거쳐야만 사용자는 최종 결과를 받아볼 수 있습니다.
- [토크노믹스](/ko/introduction/tokenomics): Stable은 스테이블코인 결제, 엔터프라이즈급 결제 및 USDT 중심 인프라에 최적화된 고성능 레이어 1 블록체인입니다.
- [왜 Stable인가?](/ko/introduction/why-stable): Stable은 세계 최초의 Stablechain으로서 USDT를 네이티브 가스 및 정산에 사용하는 페이먼트 레이어 1 블록체인입니다.
- [개발자 지원](/ko/developers/developer-assistance): 다음과 같은 주제를 다루는 개발자 중심 질문 모음집입니다:
- [Stable에 첫 번째 스마트 컨트랙트 배포하기](/ko/developers/quick-start): 이 튜토리얼에서는 Stable 테스트넷에 간단한 스마트 컨트랙트를 배포하고 체인에서 상태를 읽어옵니다. 이 과정에서 Stable 네트워크 구성 방식, USDT0이 가스 토큰으로 작동하는 방식, 표준 EVM 도구를 Stable에 연결하는 방법을 배웁니다.
- [생태계](/ko/developers/testnet/ecosystem): 이 문서에서는 브릿지(LayerZero) 및 USDT0에 대한 정보를 확인할 수 있습니다.
- [Stable 테스트넷 지갑에 자금을 충전하는 방법](/ko/developers/testnet/funding-guide): Stable은 USDT0를 가스 토큰으로 사용하므로, 체인과 상호작용하기 위해서는 지갑에 USDT0가 필요합니다. 먼저 Faucet을 사용하여 계정에 USDT0를 충전해야 합니다.
- [Testnet 정보](/ko/developers/testnet/testnet-information): Stable testnet에 접근하기 위해 필요한 모든 정보입니다.
- [버전 히스토리](/ko/developers/testnet/version-history): Stable 테스트넷의 전체 버전 히스토리 및 관련 문서 정보입니다.
- [Overview](/ko/developers/node-operations/overview): This comprehensive guide covers everything you need to know about running and maintaining Stable nodes.
- [Mainnet 정보](/ko/developers/mainnet/mainnet-information): Stable mainnet에 접근하기 위해 필요한 모든 정보입니다.
- [버전 히스토리](/ko/developers/mainnet/version-history): Stable 메인넷의 전체 버전 히스토리 및 관련 문서 정보입니다.
- [EIP-7702](/ko/developers/core-mechanics/eip-7702): Stable은 **EIP-7702**를 지원하여 EOA(외부 소유 계정)가 임시로 스마트 계정처럼 작동할 수 있는 통합 계정 모델을 도입합니다.
- [Ethereum 생태계와의 호환성](/ko/developers/core-mechanics/ethereum-compatibility): Stable은 Ethereum Virtual Machine (EVM)과 완벽하게 호환되어, 개발자들이 익숙한 도구, 라이브러리 및 컨트랙트 패턴을 수정 없이 사용할 수 있습니다.
이를 통해 기존 애플리케이션의 원활한 마이그레이션과 이미 Ethereum 생태계에서 개발 중인 팀의 간편한 온보딩을 보장합니다.
- [Finality 규칙 및 호환성 보장](/ko/developers/core-mechanics/finality): Stable은 EVM 기반 실행 환경에서 트랜잭션을 처리합니다. 트랜잭션이 블록에 포함되면 그 효과가 상태에 적용되고 애플리케이션, 컨트랙트 및 인덱서에 즉시 표시됩니다.
- [Gas 가격 책정](/ko/developers/core-mechanics/gas-pricing): Stable은 단일 구성 요소 gas 수수료 모델을 사용합니다:
- [Gas Waiver](/ko/developers/core-mechanics/gas-waiver): Gas Waiver는 소수의 거버넌스 승인 주소("면제자")가 `gasPrice = 0`인 트랜잭션을 제출할 수 있도록 허용하여 Stable에서 가스리스 최종 사용자 트랜잭션을 가능하게 합니다. Stable은 현재 파트너가 프로토콜별 래퍼 로직을 구현하지 않고도 가스리스 UX를 제공하기 위해 통합할 수 있는 면제자 서비스("면제자 서버")를 운영하고 있습니다.
- [JSON-RPC API](/ko/developers/core-mechanics/json-rpc-api)
- [개요](/ko/developers/core-mechanics/overview): Stable이 트랜잭션, 수수료 및 프로토콜 수준의 USDT 동작을 처리하는 방법에 대해 자세히 알아보세요.
- [Bank](/ko/developers/core-mechanics/system-modules/bank): Stable SDK의 `x/bank` 모듈은 기본적인 토큰 관리 기능만 제공합니다.
모든 토큰은 제한 없이 다른 계정으로 전송될 수 있으며, 사용자는 다른 계정에 토큰 전송 권한을 위임할 수 없습니다.
이러한 이유로, `bank` precompile 컨트랙트는 Stable SDK의 기존 `x/bank` 모듈 위에 추가적인 권한 부여 및 위임 기능을 제공합니다.
- [Distribution](/ko/developers/core-mechanics/system-modules/distribution): `distribution` precompile 컨트랙트는 Stable SDK의 `x/distribution` 모듈 기능을 EVM 환경에서 사용할 수 있도록 브리지 역할을 합니다.
- [개요](/ko/developers/core-mechanics/system-modules/overview): Stable은 가스 효율성과 예측 가능한 제어를 위해 **precompiled contracts**로 구현된 **시스템 모듈**을 통해 핵심 settlement 동작을 제공합니다.
- [Staking](/ko/developers/core-mechanics/system-modules/staking): `staking` precompile 컨트랙트는 Stable SDK의 `x/staking` 모듈 기능을 EVM 환경에서 사용할 수 있도록 브리지 역할을 합니다.
- [System Transactions](/ko/developers/core-mechanics/system-modules/system-transactions): 시스템 트랜잭션은 Stable 프로토콜이 Stable SDK 작업에 대한 EVM 이벤트를 발생시킬 수 있는 방법을 제공합니다. 언본딩 완료와 같은 스테이킹 이벤트가 SDK 계층에서 발생하면 프로토콜은 해당 이벤트를 발생시키는 EVM 트랜잭션을 자동으로 생성하여 이러한 작업이 EVM 도구 및 애플리케이션에 완전히 표시되도록 합니다.
- [주요 기능](/ko/architecture/key-features): Stable은 USDT 기반 활동을 원활하게 지원하기 위해 설계된 고성능 블록체인입니다. **위임 지분증명 (dPoS)** 메커니즘 위에 구축된 Stable은 **완전한 EVM 호환성**을 제공하며, **1초 미만의 블록 생성 시간**을 통해 빠르고 신뢰성 높은 트랜잭션 완결성을 달성합니다. **USDT에 특화**된 네트워크인 Stable은 사용자 경험을 최적화하는 다양한 USDT 전용 기능을 제공합니다.
- [기술 개요](/ko/architecture/tech-overview): 상태 데이터베이스, 실행, 합의부터 USDT 전용 최적화에 이르기까지, Stable은 성능, 확장성, 신뢰성을 중점으로 설계되었습니다. Stable 스택의 각 구성 요소는 높은 처리량을 요구하는 워크로드 및 네트워크 전반에서 USDT 중심의 원활한 운영을 위해 최적화되어 있습니다.
- [기밀 전송](/ko/architecture/usdt-specific-features/confidential-transfer): 기업들 사이에서 블록체인 채택이 특히 스테이블코인 분야에서 가속화됨에 따라, 트랜잭션 프라이버시에 대한 수요도 점점 증가하고 있습니다. 기업들은 종종 결제 금액과 같은 민감한 데이터를 보호하기 위해 금융 운영에서 기밀성을 요구합니다. 이러한 요구를 해결하기 위해 Stable은 프라이버시 요구와 규제 준수라는 두 가지 필수 요소의 균형을 맞춘 기밀 전송 메커니즘을 개발 중입니다.
- [보장된 블록스페이스](/ko/architecture/usdt-specific-features/guaranteed-blockspace): 스테이블코인이 지속적으로 진화함에 따라, 점점 더 많은 기업들이 이를 결제, 재무 흐름, 국경 간 정산 등 금융 운영에 통합하고 있습니다. 이러한 변화는 특히 안정적인 명목 화폐 접근이 제한된 지역에서 두드러집니다. 아프리카 및 라틴 아메리카와 같은 시장에서는 인플레이션과 환율 통제가 일반적이기 때문에, 스테이블코인은 운영 안정성을 위한 핵심 도구가 되고 있습니다.
- [개요](/ko/architecture/usdt-specific-features/overview): Stable은 USDT를 위해 제작된 레이어 1 블록체인입니다. 프로토콜의 모든 구성 요소는 USDT 전송에서의 마찰을 최소화하고, 세계에서 가장 많이 사용되는 스테이블코인에 특화된 고성능 환경을 제공하기 위해 설계되었습니다.
- [USDT as Gas](/ko/architecture/usdt-specific-features/usdt-as-gas-token): Stable은 USDT 스테이블코인을 중심으로 구축되었습니다. USDT의 옴니체인 표현인 USDT0은 Stable 생태계를 지원하는 핵심 자산입니다.
- [USDT 전송 집계](/ko/architecture/usdt-specific-features/usdt-transfer-aggregator): USDT 트랜잭션에 최적화된 블록체인으로써, Stable은 전반적인 시스템 반응성을 유지하면서도 매우 높은 수준의 토큰 전송량을 처리할 수 있도록 설계되었습니다. USDT 중심 성능과 일반 트랜잭션 다양성 간의 균형을 맞추기 위해, Stable은 USDT 전송 집계 메커니즘을 도입합니다. 이는 USDT0 전송을 고도로 병렬화되고 장애 허용적인 방식으로 번들링 및 처리하는 효율적이고 확장 가능한 솔루션입니다.
- [합의](/ko/architecture/core-optimization/consensus): 초기 Stable 블록체인은 CometBFT 기반의 맞춤형 PoS 합의 프로토콜인 **StableBFT**를 활용하여, 높은 처리량, 낮은 지연 시간, 강력한 신뢰성을 보장합니다. StableBFT의 주요 강점은 결정론적 완결성(포크 없이 즉각적인 블록 완결 보장)과 강력한 장애 허용성(밸리데이터 중 1/3이 실패하거나 악의적인 행동을 하더라도 네트워크는 안전)입니다.
- [실행](/ko/architecture/core-optimization/execution): **Stable EVM**은 Stable의 Ethereum 호환 실행 계층으로, MetaMask와 같은 기존 Ethereum 도구 및 지갑을 사용하여 체인과 원활하게 상호작용할 수 있도록 합니다. Stable EVM은 EVM의 개발자 경험과 StableSDK의 모듈러한 고성능 인프라를 결합합니다.
- [고성능 RPC](/ko/architecture/core-optimization/high-performance-rpc): 고성능 블록체인을 구현하기 위해서는 합의나 블록 생성만을 최적화해서는 충분하지 않습니다. RPC 계층은 블록체인과 사용자를 연결하는 인터페이스로, 사용자 경험에 있어 핵심적인 구성 요소입니다. Stable은 기존 RPC 설계의 한계를 극복하기 위해 새로운 RPC 전용 아키텍처를 제안합니다.
- [개요](/ko/architecture/core-optimization/overview): 제출부터 결과 완결까지 블록체인 트랜잭션의 라이프사이클은, 강하게 연결된 여러 단계로 구성되어 있습니다. 트랜잭션은 **RPC** 인터페이스를 통해 제출되어, **멤풀**에 추가되고, 블록에 포함되며, **합의**를 통해 검증되고, **상태 머신**에 의해 실행되며, **데이터베이스**에 최종 저장됩니다. 전체 파이프라인을 모두 완료한 이후에야 사용자는 확정된 결과를 받을 수 있습니다.
- [StableDB](/ko/architecture/core-optimization/stable-db): 블록체인 성능에서 주요 병목 중 하나는 **디스크 I/O**에 있습니다. 보다 구체적으로는, 블록 실행 후 상태 데이터를 커밋하고 저장하는 작업이 핵심 병목 지점입니다. Stable은 이 문제를 해결하기 위해 `MemDB`, `VersionDB`, 메모리 매핑 파일 I/O 메커니즘 (`mmap`)와 같은 아키텍처 혁신을 도입하여 처리량을 획기적으로 향상시킵니다.
- [Autobahn](/ko/architecture/core-optimization/appendix/autobahn): 현대의 비잔틴 장애 허용(Byzantine Fault Tolerant, BFT) 합의 프로토콜은 일반적으로 부분 동기(partial synchrony) 모델에서 동작합니다. 이 모델은 어떤 시점 이후에는 네트워크가 안정되며 메시지 지연 시간이 유한하게 유지된다는 가정에 기반합니다. 이 모델은 프로토콜 설계에 있어 실용적으로 작용해 왔지만, 실제 운영 환경에서는 장기간 상태를 안정적으로 유지하기 어렵습니다. 대신 시스템은 지속적인 동기 구간과 간헐적인 장애(예: 레이턴시 증가, 노드 장애, 공격적 조건 등)를 반복적으로 겪습니다. 이러한 일시적 장애를 **"블립(blip)"** 이라고 합니다.
- [Integrate Stable](/en): Stable is a Layer 1 where USDT0 is both the native gas token and an ERC-20. Single-slot finality, sub-second block times, and full EVM compatibility. You bring your wallet, seed phrase, and USDT0 — there's no separate gas asset, no account migration, no new SDK to learn.
- [Bridge USDT0 to Stable](/en/tutorial/bridge-usdt0): In this tutorial, you will bridge USDT0 from Ethereum Sepolia to the Stable Testnet programmatically using TypeScript and ethers v6. You will build the script incrementally, adding one function per step.
- [Quick start](/en/tutorial/quick-start): The only tools you need are Node.js, some USDT0 from the faucet and a private key. Stable uses USDT0 as its gas token, so you only need USDT0 to transact. There is no separate gas asset to fund.
- [SDK quickstart](/en/tutorial/sdk-quickstart): You'll install `@stablechain/sdk`, create a client signed by a private key, send a USDT0 transfer on Stable Testnet, and fetch a bridge and swap quote. Total time: about five minutes.
- [Send your first USDT0](/en/tutorial/send-usdt0): On Stable, USDT0 is both the chain's native asset and an ERC-20 token. This means `approve`, `transferFrom`, and `permit` remain fully available alongside standard value transfers, and both paths move funds from the same underlying balance.
- [Deploy a smart contract](/en/tutorial/smart-contract): In this tutorial, you will deploy a simple smart contract to the Stable Testnet and read its state from the chain. Along the way, you will learn how Stable's network is configured, how USDT0 works as a gas token, and how to point standard EVM tooling at Stable.
- [Brand Kit](/en/resources/brand-kit): The Stable brand kit includes logos in multiple formats and the official color palette. Use it to keep Stable's branding consistent across projects and communications.
- [Facilitators](/en/reference/agentic-facilitators): A facilitator verifies a signed x402 payment and submits the on-chain call that settles it in USDT0 on Stable. Using a hosted facilitator means you do not run settlement infrastructure or manage gas tokens. For the rail-level context, see [Agent settlement](/en/explanation/agent-settlement).
- [Wallets](/en/reference/agentic-wallets): Agent wallets give AI agents and autonomous systems self-custodial signing so they can participate in x402 payment flows without human-driven setup.
- [Bank precompile reference](/en/reference/bank-module-api): **Concept:** For what the bank module does and when to use it, see [Bank module](/en/explanation/bank-module).
- [Bridges](/en/reference/bridges): Bridge providers supporting USDT0 transfers to and from Stable. For how cross-chain USDT0 movement works, see [Bridging to Stable](/en/explanation/usdt0-bridging). For a hands-on walkthrough, see the [Bridge USDT0 to Stable Testnet](/en/tutorial/bridge-usdt0) tutorial.
- [Connect](/en/reference/connect): This page consolidates the network details you need to connect to Stable.
- [Custody](/en/reference/custody): **MPC custody infrastructure:** Platforms using multi-party computation to distribute private key control across multiple parties. These provide secure key management, policy engines, and developer APIs for institutional digital asset operations.
- [Developer assistance](/en/reference/developer-assistance): A growing collection of developer-focused questions covering topics such as:
- [DEXes](/en/reference/dexes): DEX deployments on Stable for spot trading, liquidity provision, and on-chain routing. Stable is on the [Official Uniswap v3 Deployments List](https://gov.uniswap.org/t/official-uniswap-v3-deployments-list/24323/13#p-58106-stable-4): the Uniswap v3 contracts on Stable are governance-recognized as canonical and are routed through [Stable Swap](https://swap.stable.xyz) as the default frontend.
- [Distribution precompile reference](/en/reference/distribution-module-api): **Concept:** For what the distribution module does and when to use it, see [Distribution module](/en/explanation/distribution-module).
- [EIP-7702](/en/reference/eip-7702-api): Stable supports **EIP-7702**, which allows an EOA to set its account code to an existing smart contract. EOAs keep their original address and private key while executing the delegate's logic.
- [FAQ](/en/reference/faq): **What is Stable?**
- [Gas pricing reference](/en/reference/gas-pricing-api): Transaction construction, gas estimation, and tooling configuration for Stable.
- [Gas waiver protocol](/en/reference/gas-waiver-api): This document specifies the Gas Waiver mechanism: transaction formats, marker routing, governance controls, and the Waiver Server API.
- [Indexers](/en/reference/indexers): Indexers and analytics platforms provide structured access to on-chain data, enabling developers to query transactions, balances, logs, events, and application-specific data at scale. Stable is EVM-compatible, so standard Ethereum indexing tools work seamlessly.
- [Settle invoices](/en/reference/invoices): Each invoice maps to a unique, deterministic nonce derived from invoice metadata: invoice number, parties, amount, and due date. This nonce drives settlement via [ERC-3009](/en/explanation/erc-3009) and creates an immutable receipt that can be reconciled with existing accounting systems.
- [JSON-RPC API](/en/reference/json-rpc-api): [**Gas pricing reference**](/en/reference/gas-pricing-api) — Construct EIP-1559 transactions against Stable's base-fee-only model.
- [Mainnet information](/en/reference/mainnet-information): Everything you need to know to access Stable Mainnet.
- [Version history](/en/reference/mainnet-version-history): Complete version history and related documentation for the Stable Mainnet.
- [Network routing](/en/reference/network-routing): Network routing providers optimizing connectivity and data delivery for applications on Stable.
- [Network upgrades](/en/reference/network-upgrades)
- [Operate](/en/reference/node-operations-overview): Operate covers running a Stable node: full or archive, testnet or mainnet, from install through monitoring. For the chain-level behavior your node enforces (fee model, finality, USDT0 as gas), see [Gas pricing](/en/explanation/gas-pricing), [Finality](/en/explanation/finality), and the [Architecture overview](/en/explanation/core-optimization-overview).
- [Oracles](/en/reference/oracles): Oracles provide smart contracts with off-chain data such as asset prices. RedStone operates price feeds on Stable.
- [Send and receive USDT0](/en/reference/p2p-payments): On Stable, P2P payments settle in under a second. Two transfer methods are available depending on the use case.
- [Bill per API request](/en/reference/pay-per-call): Monetize any HTTP endpoint with per-request pricing using [x402](/en/explanation/x402) middleware. A server declares its price, a client pays per call, and settlement happens within the request lifecycle. No accounts, no API keys, no billing cycles.
- [Ramps](/en/reference/ramps): On/off ramp partners connect Stable to global fiat systems, enabling users and businesses to move between USDT, local currencies, and payment rails.
- [RPC providers](/en/reference/rpc-providers): RPC and developer infrastructure providers supporting Stable.
- [SDK reference](/en/reference/sdk): Full surface of `@stablechain/sdk`. For a walkthrough, see [SDK quickstart](/en/tutorial/sdk-quickstart).
- [Staking precompile reference](/en/reference/staking-module-api): **Concept:** For what the staking module does and when to use it, see [Staking module](/en/explanation/staking-module).
- [Set up recurring billing](/en/reference/subscriptions): Pull-based subscriptions let a service provider collect payments on a schedule without requiring the subscriber to initiate each payment.
- [System modules reference](/en/reference/system-modules-api-overview): Stable exposes core settlement behavior through **System Modules**, implemented as **precompiled contracts** for gas efficiency and predictable control.
- [System transactions reference](/en/reference/system-transactions-api): **Concept:** For how system transactions bridge SDK events to the EVM and why this matters, see [System transactions](/en/explanation/system-transactions).
- [Ecosystem](/en/reference/testnet-ecosystem): In this document, you can find the information for bridge (LayerZero) and USDT0.
- [Testnet information](/en/reference/testnet-information): Everything you need to know to access the Stable Testnet.
- [Version history](/en/reference/testnet-version-history): Complete version history and related documentation for the Stable Testnet.
- [Tokenomics](/en/reference/tokenomics): STABLE is the governance token of the Stable Mainnet. It secures the network through delegated Proof-of-Stake, governs protocol upgrades, and entitles stakers to a share of USDT0 gas revenue distributed by validators.
- [Wallets](/en/reference/wallets): **User Wallets:** These are traditional consumer-facing wallets such as mobile apps, browser extensions, or exchange-linked wallets. They allow users to hold USDT, make transfers, connect to dApps, and interact directly with Stable.
- [Account abstraction with EIP-7702](/en/how-to/account-abstraction): This guide walks through applying EIP-7702 to an EOA and using the delegation for three patterns: batch payments, spending limits, and session keys. The EOA keeps its address and private key throughout.
- [Build an MPP endpoint on Stable](/en/how-to/build-mpp-endpoint): This guide walks through writing a custom [MPP](/en/explanation/mpp) payment method for USDT0 on Stable and serving an MPP-gated endpoint. The buyer signs an [ERC-3009](/en/explanation/erc-3009) `transferWithAuthorization`, the server validates it through `mppx`'s `verify()` hook, and settlement happens in a separate step you control.
- [Learn P2P payments](/en/how-to/build-p2p-payments): This guide walks through building a P2P payment application on Stable. The app handles the full payment lifecycle: the sender transfers USDT0 directly, the receiver detects the incoming payment in real time, and both can query their own transaction history. Same architecture as any wallet or payment interface, whether a mobile app, web checkout, or backend service.
- [Build a pay-per-call API](/en/how-to/build-pay-per-call): This guide walks through monetizing an API endpoint with x402. The server adds a payment handler, the client pays per request, and settlement happens within the HTTP lifecycle.
- [Create a wallet](/en/how-to/create-wallet): A Stable wallet is an Ethereum-standard key pair. Any wallet library that produces an EVM account works on Stable without modification. This guide shows two paths: ethers.js for most applications, and Tether's [WDK (Wallet Development Kit)](https://github.com/tetherto/wdk) for integrations that want a turnkey self-custody layer for agents and payments.
- [Index contract events](/en/how-to/index-contract): Indexing turns on-chain events into data your application can react to: balance updates, transaction history, UI notifications. This guide shows how to subscribe to events from a deployed Stable contract using ethers.js and how to backfill historical events so you don't miss any emitted while your service was offline.
- [Index validator data](/en/how-to/index-validator-data): Validator data lives on-chain and is readable over standard EVM JSON-RPC. You query current state through the staking, slashing, and governance precompiles, and you reconstruct history from their event logs. This means an indexer or analytics platform reads everything it needs through `eth_call` and `eth_getLogs`, with no access to a node's `stabled` CLI or Cosmos REST.
- [Enable gas-free transactions](/en/how-to/integrate-gas-waiver): Gas Waiver enables gas-free transactions on Stable. With Gas Waiver, applications cover gas fees on behalf of users, so users can interact with contracts without holding USDT0 for gas.
- [Paying with invoice](/en/how-to/pay-with-invoice): This guide walks through settling an invoice on-chain using [ERC-3009](/en/explanation/erc-3009) with a deterministic nonce derived from invoice metadata. The nonce links each payment to its invoice and prevents double payment.
- [Paying with MCP server](/en/how-to/pay-with-mcp): This guide shows how to bridge x402-enabled APIs to [MCP](https://modelcontextprotocol.io) tools so AI clients can call and pay for them through natural-language prompts. It builds on the server from [Build a pay-per-call API](/en/how-to/build-pay-per-call).
- [Production readiness](/en/how-to/production-readiness): Work through each section below before switching from testnet to mainnet.
- [Use the SDK with viem](/en/how-to/sdk-with-viem): `@stablechain/sdk` is built on viem. `createStable` accepts three signing modes, and you pick one based on where the code runs: server-side with a private key, browser-side with the user's wallet, or with a `WalletClient` you've already constructed (for example, in a wagmi app).
- [Use the SDK with wagmi](/en/how-to/sdk-with-wagmi): `createStable` accepts a viem `WalletClient`, which is exactly what wagmi's `useWalletClient` returns. You connect the wallet through wagmi as you normally would, then memoize a `StableClient` whenever the wallet client changes.
- [Self-hosted gas waiver](/en/how-to/self-hosted-gas-waiver): Self-hosted Gas Waiver lets you operate your own waiver infrastructure instead of using the hosted Waiver Server API. You register a waiver address through on-chain governance, then broadcast wrapper transactions directly to the network.
- [Subscribe and collect](/en/how-to/subscribe-and-collect): This guide walks through building a subscription payment system where the subscriber authorizes once and the service provider collects each billing cycle automatically via EIP-7702 account abstraction.
- [Tracking unbonding completions](/en/how-to/track-unbonding): When an unbonding period completes, the protocol emits an `UnbondingCompleted` event through the `StableSystem` precompile (`0x0000000000000000000000000000000000009999`) via a system transaction. This lets dApps notify users and update balances in real time without running custom indexers or polling REST endpoints.
- [Get testnet USDT0](/en/how-to/use-faucet): Stable uses USDT0 as the gas token, so you need USDT0 in your wallet to submit transactions. There are two ways to fund a testnet wallet: the faucet for small amounts, or bridging from Ethereum Sepolia for larger amounts.
- [Use system modules](/en/how-to/use-system-modules): Stable exposes protocol-level settlement logic through **precompiled contracts** at fixed addresses. The precompiles let EVM code call Stable SDK modules (staking, reward distribution, STABLE token operations) without re-implementing them. They're significantly more gas efficient than equivalent Solidity implementations because they run at the protocol level.
- [Verify a smart contract](/en/how-to/verify-contract): Verification uploads your contract's source code to the block explorer and proves it compiles to the deployed bytecode. Once verified, users can read state, call functions, and audit the source on Stablescan without re-hosting your code. This guide walks through verifying a Foundry-deployed contract on Stable.
- [Work with USDT0 as gas](/en/how-to/work-with-usdt-gas): On Stable, USDT0 is both the chain's native asset and an ERC-20 token. The gas token is USDT0, not a separate native asset. Standard Ethereum gas estimation works once you adjust three things: `maxPriorityFeePerGas` is always `0`, `baseFee` is denominated in USDT0, and the `value` field in a native transfer carries USDT0 (not ETH).
- [Zero gas transactions](/en/how-to/zero-gas-transactions): Gas Waiver lets an application cover gas on behalf of a user. The user signs a transaction with `gasPrice = 0`, a governance-registered waiver wraps it, and validators execute the call at zero cost to the user. This guide walks through a qualifying transfer, shows how to verify gas was waived, and explains what the waiver does and doesn't cover.
- [Accounts guides](/en/explanation/accounts-): Every guide, concept, and reference under the Accounts tab, grouped by what you're trying to do.
- [Accounts on Stable](/en/explanation/accounts-overview): An account on Stable is a standard Ethereum EOA that can optionally execute smart contract logic through [EIP-7702 delegation](/en/explanation/eip-7702). Users keep one address and one private key across wallets, batch payments, recurring subscriptions, and session keys. Agents run the same account model without any custodial middleware.
- [Agent settlement](/en/explanation/agent-settlement): Agent settlement is Stable's rail for machine payments. An agent holds a USDT0 balance, pays for a resource over HTTP, and the payment settles on-chain in the same request cycle. The agent spends down from one balance for both the payment and the network fee. There is no separate gas token, no sign-up, and no API key rotation.
- [AI and agents guides](/en/explanation/ai-agents-): Every guide, concept, and reference under the AI/Agents tab, grouped by what you're trying to do.
- [Autobahn](/en/explanation/autobahn): Modern Byzantine Fault Tolerant (BFT) consensus protocols typically operate under the partial synchrony model. This model assumes that the network eventually stabilizes and message delays remain bounded. While practical for protocol design, real-world deployments rarely enjoy long periods of uninterrupted stability. Instead, systems frequently experience periods of synchrony followed by short disruptions such as latency spikes, node outages, or adversarial conditions. These transient disruptions are referred to as **“blips”**.
- [Bank module](/en/explanation/bank-module): The `x/bank` module in Stable's SDK handles token balances, transfers, and supply. Its EVM surface (the **bank precompile**) wraps this module and adds ERC-20 semantics plus an authorization layer for privileged mint/burn operations. Contracts that need to move tokens on Stable call the precompile directly without deploying their own token implementation.
- [Bridge security and DVNs](/en/explanation/bridge-security): A LayerZero bridge is only as secure as the verification layer that confirms a message sent on one chain happened on another. That layer is a Decentralized Verifier Network (DVN). This page explains what DVNs do, how Stable configures them on its bridges, and why a compromise of any single DVN does not put Stable at risk.
- [Overview](/en/explanation/build-overview): New to Stable? Run the [Quick start](/en/tutorial/quick-start) first. It takes five minutes and sends a testnet transaction so the rest of the tab has something to plug into.
- [Confidential transfer](/en/explanation/confidential-transfer): **Confidential Transfer** is a privacy layer on Stable that shields the **amount** of a USDT0 transfer while keeping sender and recipient addresses publicly visible. The shielded amount is readable only by the transacting parties and authorized regulatory auditors, using zero-knowledge (ZK) cryptography to prove validity without revealing the value. The feature is under development; this page describes the target model.
- [Consensus](/en/explanation/consensus): Stable Blockchain leverages **StableBFT**, a customized PoS consensus protocol built on CometBFT, to deliver high throughput, low latency, and strong reliability. StableBFT provides deterministic finality (blocks are final on inclusion, without forks) and Byzantine fault tolerance up to 1/3 of validators failing or acting maliciously.
- [Contracts guides](/en/explanation/contracts-): Every guide, concept, and reference under the Contracts tab, grouped by what you're trying to do.
- [Contracts on Stable](/en/explanation/contracts-overview): Stable is fully EVM-compatible. Solidity, Vyper, Hardhat, Foundry, ethers.js, and viem work unchanged. Existing contracts deploy as-is once you point tooling at Stable's RPC. On top of the standard EVM, Stable exposes protocol-level modules (Bank, Distribution, Staking) as precompiled contracts at fixed addresses, so your Solidity can call into staking and reward distribution without re-implementing them.
- [Core concepts](/en/explanation/core-concepts): Four concepts are enough to start building. Each section defines the concept, shows it, and links to the full reference.
- [Overview](/en/explanation/core-optimization-overview): The lifecycle of a blockchain transaction, from submission to finalized result, passes through multiple tightly connected stages. A transaction is first submitted through the **RPC** interface, added to the **mempool**, packaged into a block, validated through **consensus**, executed by the **state machine**, and finally written to persistent storage in the **database**. Only after completing this full pipeline does the user receive a confirmed result.
- [Distribution module](/en/explanation/distribution-module): The `x/distribution` module handles staking-reward accrual and withdrawal for delegators and validators. Its precompile bridges this behavior into the EVM so a Solidity contract can claim rewards, set withdraw addresses, and query outstanding rewards without interacting with the Cosmos SDK directly.
- [EIP-7702](/en/explanation/eip-7702): Stable supports **EIP-7702**, which allows an EOA to **set its account code to an existing smart contract**. The EOA executes that contract's logic while keeping its original address and private key. The delegation is persistent until the EOA explicitly changes or clears it.
- [Settle with signed authorizations](/en/explanation/erc-3009): ERC-3009 lets a token holder authorize a transfer by signing a message. Anyone can then submit that signed authorization to execute the transfer on-chain. The sender never needs to call the contract directly.
- [Ethereum comparison](/en/explanation/ethereum-comparison): Stable is fully EVM-compatible, so most Ethereum tools, libraries, and contract patterns work without modification. The sections below walk through what stays the same and what changes when you move from Ethereum to Stable.
- [Compatibility with the Ethereum ecosystem](/en/explanation/ethereum-compatibility): Stable is fully compatible with the Ethereum Virtual Machine (EVM), allowing developers to use familiar tools, libraries, and contract patterns without modification.
This ensures seamless migration of existing applications and straightforward onboarding for teams already building in the Ethereum ecosystem.
- [Execution](/en/explanation/execution): **Stable EVM** is Stable's Ethereum-compatible execution layer. Existing Ethereum tools and wallets like MetaMask interact with Stable unchanged. Stable EVM combines the EVM's developer experience with the modular infrastructure of the Stable SDK.
- [Finality rules & compatibility guarantees](/en/explanation/finality): Stable processes transactions within an EVM-based execution environment. When a block includes a transaction, the chain applies its effects to state and makes them immediately visible to applications, contracts, and indexers.
- [Flow of Funds](/en/explanation/flow-of-funds): Stable is the first blockchain purpose-built for stablecoin payments. The network is optimized for high-throughput, low-latency stablecoin transactions, delivering P2P payments and merchant acceptance with immediate settlement in USDT. Application-layer gas sponsorship and waivers allow providers to offer a zero-fee experience for end users, providing the feel of a mainstream payments network while abstracting away the complexity of blockchain systems.
- [Gas pricing](/en/explanation/gas-pricing): Stable uses a simplified, single-component gas fee model designed to remove fee volatility and deliver predictable, low transaction costs. Transaction ordering is not influenced by tip bidding. The effective gas price is determined solely by the protocol's base fee.
- [Gas waiver](/en/explanation/gas-waiver): Governance-approved addresses (called **waivers**) submit a wrapper transaction that carries the user's signed payload and executes it at `gasPrice = 0`. The user holds no USDT0 and pays no gas. Stable operates one such waiver as a hosted service; partners can also register their own waiver addresses through validator governance.
- [Guaranteed blockspace](/en/explanation/guaranteed-blockspace): **Guaranteed Blockspace** is a dedicated blockspace-allocation model that reserves a fixed share of every block's capacity for enrolled enterprise partners, regardless of broader network conditions. Transactions routed through the guaranteed path execute with predictable latency and cost. Payroll, settlement, and supplier payments don't compete with public mempool traffic.
- [High performance RPC](/en/explanation/high-performance-rpc): In the pursuit of a high-performance blockchain, it's not enough to only optimize consensus or block production. The RPC layer is a critical component of the end-to-end user experience because it is the interface between the blockchain and its users. Stable proposes a new RPC-dedicated architecture to overcome the limitations of traditional RPC design.
- [Overview](/en/explanation/integrate-overview): Stable is an EVM-compatible Layer 1 where USDT0 is the native gas token. Most Ethereum tools, libraries, and contract patterns work without modification. You connect by pointing your RPC to Stable and switching the chain ID.
- [Key features](/en/explanation/key-features): Stable is a delegated Proof-of-Stake Layer 1 with single-slot finality, full EVM compatibility, and USDT0 as the native gas token. The features below are the ones that shape day-to-day integration. Each links to the page that covers it in depth.
- [Learn](/en/explanation/learn-overview): [**Overview**](/en/explanation/overview) — What Stable is and how to read this documentation.
- [MPP sessions](/en/explanation/mpp-sessions): A session is an MPP payment intent that batches many small payments into a single on-chain settlement. The client deposits funds into an escrow once, then signs cheap off-chain vouchers for each request. Only the net amount settles on-chain, which makes sub-cent per-request economics viable for streaming workloads.
- [Machine Payments Protocol (MPP)](/en/explanation/mpp): MPP (Machine Payments Protocol) is an open standard for paying for HTTP resources in the same request that asks for them. It extends [x402](/en/explanation/x402) with new payment intents (charge, subscription, session), multi-rail support (stablecoins, cards, Lightning), production features (idempotency, body-digest binding, expiration), and additional transports (MCP, WebSocket). The protocol is on the IETF standards track.
- [Overview](/en/explanation/overview): Stable is a Layer 1 where USDT0 is the native gas token, and standard EVM tooling (Solidity, Foundry, Hardhat, ethers, viem, and the `eth_*` JSON-RPC methods) works unchanged.
- [Use cases overview](/en/explanation/payment-use-cases-overview): Stable supports multiple payment patterns, from simple wallet-to-wallet transfers to agent-driven service payments. The use cases below cover the patterns that are production-ready today. For patterns on the horizon (guaranteed settlement, confidential payments, agent-to-agent commerce), see [Upcoming use cases](/en/explanation/upcoming-use-cases).
- [Payments guides](/en/explanation/payments-): Every guide, concept, and reference under the Payments tab, grouped by what you're trying to do.
- [Payments on Stable](/en/explanation/payments-overview): Stable is built around payments. USDT0 is the native asset and the gas token, so settlement and fees share one balance. Single-slot finality means a transfer clears in under a second. ERC-3009, EIP-7702, and x402 are native primitives, not workarounds — you can settle with a signature, pull from a delegated account, or charge per HTTP request without running a billing stack.
- [Stable SDK](/en/explanation/sdk-overview): `@stablechain/sdk` is the official TypeScript client for Stable. It wraps viem with a small, typed API for the operations you reach for most: transfer USDT0, bridge between chains, and swap tokens on Stable. Routing, approvals, decimals, and chain switching are handled for you.
- [Storage (StableDB)](/en/explanation/stable-db): One of the main bottlenecks in end-to-end blockchain performance is **Disk I/O**. Specifically, committing and storing state data after block execution creates the key bottleneck. Stable tackles this problem with architectural innovations such as `MemDB`, `VersionDB`, and memory-mapped storage (`mmap`) to dramatically improve throughput.
- [Staking module](/en/explanation/staking-module): The `x/staking` module controls validator participation and delegation on Stable. Its precompile makes these operations callable from Solidity, so a contract can delegate STABLE, undelegate after the unbonding period, redelegate between validators, or query validator state without leaving the EVM.
- [System modules](/en/explanation/system-modules-overview): Stable's core protocol behavior lives in SDK modules: `x/bank`, `x/distribution`, `x/staking`. To make this behavior accessible from the EVM, Stable exposes each module as a **precompiled contract** at a fixed address. Contracts written in Solidity call the precompile directly, and the EVM routes the call into the native SDK handler. Precompiles are implemented at the protocol level, making them significantly more gas-efficient than an equivalent Solidity re-implementation.
- [System transactions](/en/explanation/system-transactions): EVM applications subscribe to on-chain activity through standard interfaces like `eth_getLogs`. But some of the most important operations on Stable (staking unbonding completions, for example) happen inside SDK modules that don't naturally emit EVM events. **System transactions** close this visibility gap: the protocol itself submits EVM transactions that emit events for SDK-layer operations, making them indexable through the same log stream dApps already use.
- [Tech overview](/en/explanation/tech-overview): **What's live today:** StableBFT consensus, Stable EVM (full EVM compatibility), and the split-path RPC layer are all production-ready. StableDB ships in the v1.4.0 upgrade. Autobahn (DAG-based consensus) and StableVM++ (optimistic parallel execution) are roadmap items. See the [Roadmap](/en/explanation/technical-roadmap) for timelines.
- [Roadmap](/en/explanation/technical-roadmap): Stable optimizes every layer of the transaction pipeline (consensus, execution, storage, RPC, and USDT-specific flows) across three phases. This page marks what's shipped, what's in progress, and what's still ahead.
- [Upcoming use cases](/en/explanation/upcoming-use-cases): Stable is building toward payment patterns that go beyond simple transfers and API billing. The cases below cover time-guaranteed settlement, privacy-preserving payments, and autonomous agent commerce. Some are functional today in early form; others depend on Stable features currently in development.
- [USDT as gas](/en/explanation/usdt-as-gas-token): **You pay fees in USDT0. No second token, no wrapping, no ETH-equivalent to keep topped up.** USDT0 serves as both the native gas token and an ERC-20 token on the same balance. The same asset that moves as payment also pays for the transaction that moves it. Fees are denominated in dollars, not a volatile native token.
- [Overview](/en/explanation/usdt-features-overview): Stable's USDT-specific features aren't a menu of independent options. They compose. Each one removes a specific friction that shows up when stablecoin payments move from demos to production. This page explains why the five features exist together.
- [USDT transfer aggregator](/en/explanation/usdt-transfer-aggregator): The **USDT Transfer Aggregator** bundles USDT0 transfers into parallelized, fault-tolerant batches instead of processing each transfer sequentially. It isolates USDT0 throughput from the rest of the execution pipeline so high-volume stablecoin activity doesn't crowd out other transactions.
- [USDT0 behavior on Stable](/en/explanation/usdt0-behavior): **If you're porting a contract from Ethereum, read this page before deploying.** USDT0 on Stable is both the native gas token and an ERC-20 token on the same balance. Four Ethereum-assumed behaviors break as a result: a contract's native balance can change without a call into the contract, `EXTCODEHASH` can oscillate between zero and empty hash, zero-address transfers revert, and a single logical transfer can emit multiple `Transfer` events from fractional-balance reconciliation.
- [Bridging to Stable](/en/explanation/usdt0-bridging): USDT reaches Stable via one of two bridge paths, depending on what form it takes on the source chain. Both paths deliver USDT0 into the user's wallet on Stable.
- [Payments & transfers](/en/explanation/use-case-payments): P2P payments and merchant settlement built around one asset that moves the money and pays for the transaction.
- [Payroll & mass payouts](/en/explanation/use-case-payroll): Paying employees, contractors, and suppliers at scale, with predictable throughput, predictable cost, and privacy for sensitive amounts.
- [Private transfers](/en/explanation/use-case-private): Treasury operations, supplier payments, and salary runs where the amount is commercially sensitive and shouldn't be published to the world.
- [Sponsored and gasless experiences](/en/explanation/use-case-sponsored): Apps that want to remove gas from the user experience entirely, so a first-time user can sign in and transact without acquiring a second asset first.
- [Monetize HTTP endpoints](/en/explanation/x402): x402 is a payment protocol built on HTTP. A server responds with `402 Payment Required` and payment details, a client signs an [ERC-3009](/en/explanation/erc-3009) authorization, and a facilitator settles it on-chain. The entire exchange happens over standard HTTP headers. The client only needs a wallet: no sign-up, no API keys, no card registration.
- [欢迎来到 Stable](/cn): 欢迎阅读 **Stable** 的官方文档。
- [Brand Kit](/cn/resources/brand-kit): 您可以在下方找到 Stable 的Brand Kit，其中包含标志的多种格式版本和配色方案。本工具包旨在帮助您在项目或传播中使用 Stable 品牌时保持一致性。
- [官方链接](/cn/resources/official-links): 网站: [https://stable.xyz](https://stable.xyz)
- [常见问题](/cn/introduction/faq): **什么是 Stable？**
- [Stable 为用户而生](/cn/introduction/stable-for-users): Stable 提供强大、可靠且具成本效益的稳定币区块链解决方案，专为 USDT 优化。通过为机构、普通用户和开发者量身打造的全面功能，Stable 提升金融效率，推动卓越运营表现。
- [技术路线图](/cn/introduction/technical-roadmap): 从用户提交交易到最终结果确认，交易生命周期要经历多个阶段：交易首先通过 RPC 广播，然后进入内存池（mempool），然后被打包进区块，经过共识验证、执行，最终将结果状态写入数据库。只有完成这些步骤，用户才能获得最终的交易结果。
- [代币经济学](/cn/introduction/tokenomics): Stable 是一个高性能的第一层区块链，专为稳定币结算、企业级支付和以 USDT 为中心的基础设施而优化。
- [为什么选择 Stable](/cn/introduction/why-stable): 随着数字金融加速发展，稳定币——尤其是 USDT——已成为链上活动的核心组成部分。然而，大多数区块链基础设施并未针对稳定币操作进行优化，导致一系列关键问题：
- [开发者支持](/cn/developers/developer-assistance): 如何连接 Stable 网络？
- [在 Stable 上部署你的第一个智能合约](/cn/developers/quick-start): 在本教程中，你将向 Stable 测试网部署一个简单的智能合约，并从链上读取其状态。在此过程中，你将了解 Stable 网络的配置方式、USDT0 作为 gas 代币的工作原理，以及如何将标准 EVM 工具指向 Stable。
- [生态系统](/cn/developers/testnet/ecosystem): 在本文档中，您可以找到桥接（LayerZero）和 USDT0 的信息。
- [如何为您的 Stable 测试网钱包充值](/cn/developers/testnet/funding-guide): Stable 使用 USDT0作为燃料代币，因此您需要在钱包中有 USDT0 才能与链进行交互。首先，您需要使用水龙头为您的账户充值 USDT0。
- [测试网信息](/cn/developers/testnet/testnet-information): 您访问 Stable 测试网所需了解的一切信息。
- [版本历史](/cn/developers/testnet/version-history): Stable 测试网的完整版本历史和相关文档。
- [Overview](/cn/developers/node-operations/overview): This comprehensive guide covers everything you need to know about running and maintaining Stable nodes.
- [主网信息](/cn/developers/mainnet/mainnet-information): 您访问 Stable 主网所需了解的一切信息。
- [版本历史](/cn/developers/mainnet/version-history): Stable 主网的完整版本历史和相关文档。
- [EIP-7702](/cn/developers/core-mechanics/eip-7702): Stable 支持 EIP-7702，引入了统一账户模型，使外部账户（EOA）可临时以智能账户方式运行。
- [与以太坊生态的兼容性](/cn/developers/core-mechanics/ethereum-compatibility): Stable 完全兼容 EVM，使开发者可直接使用以太坊工具、库和智能合约模块，无需进行任何修改。
- [终局性规则与兼容性保证](/cn/developers/core-mechanics/finality): Stable 的交易在 EVM 执行环境中处理。当交易被打包入区块后，其状态变更立即生效。
- [Gas 定价机制](/cn/developers/core-mechanics/gas-pricing): Stable 采用单一组成部分的 Gas 费模型：
- [Gas 豁免人](/cn/developers/core-mechanics/gas-waiver): Gas 豁免人（免 Gas 费）功能通过允许一小部分经过治理批准的地址（"豁免人"）提交 `gasPrice = 0` 的交易，实现 Stable 链上终端用户的无 Gas 费交易。Stable 目前运营一个豁免人服务（"豁免人服务器"），合作伙伴可以集成该服务，无需实现特定协议的封包逻辑即可提供无 Gas 费用户体验。
- [JSON-RPC API](/cn/developers/core-mechanics/json-rpc-api)
- [概览](/cn/developers/core-mechanics/overview): 了解更多关于 Stable 如何处理交易、费用和协议级 USDT 行为的信息。
- [银行模块](/cn/developers/core-mechanics/system-modules/bank): Stable SDK 中的 `x/bank` 模块仅提供基本的代币管理功能。
每个代币都可以无限制地转移到任何账户，用户无法委托其他账户代为转移其代币到其他账户。
因此，`bank` 预编译合约在 Stable SDK 现有的 `x/bank` 模块基础上提供了额外的授权和委托功能。
- [分配模块](/cn/developers/core-mechanics/system-modules/distribution): `distribution` 预编译合约作为桥梁，使 Stable SDK 的 `x/distribution` 模块功能能在 EVM 环境中使用。
- [概览](/cn/developers/core-mechanics/system-modules/overview): Stable 通过**系统模块**暴露核心结算行为，以**预编译合约**的形式实现，确保gas效率和可预测的控制。
- [质押模块](/cn/developers/core-mechanics/system-modules/staking): `staking` 预编译合约作为桥梁，使 Stable SDK 的 `x/staking` 模块功能能在 EVM 环境中使用。
- [System Transactions](/cn/developers/core-mechanics/system-modules/system-transactions): 系统交易为 Stable 协议提供了一种为 Stable SDK 操作发出 EVM 事件的方式。当质押事件（如解绑完成）在 SDK 层发生时，协议会自动生成发出相应事件的 EVM 交易，使这些操作对 EVM 工具和应用程序完全可见。
- [核心功能](/cn/architecture/key-features): Stable 是一条高性能区块链，专为支持 USDT 相关活动而设计。基于 **委托权益证明（dPoS）** 机制构建，Stable 实现了 **完全兼容 EVM**，并达成 **亚秒级出块时间**，确保交易快速可靠地达成最终性。作为一个 **专注于 USDT 的网络**，Stable 提供了一系列优化用户体验的 USDT 专属功能。
- [技术概览](/cn/architecture/tech-overview): 从状态数据库、执行引擎、共识机制，到针对 USDT 的特定优化，Stable 的设计始终聚焦于性能、可扩展性与可靠性。技术栈中的每一层组件都经过专门优化，以支持高吞吐的工作负载和无缝的 USDT 原生操作。
- [隐私转账（Confidential Transfer](/cn/architecture/usdt-specific-features/confidential-transfer): 随着区块链在企业中的应用不断加速，尤其是在稳定币领域，**对交易隐私的需求日益增长**。许多企业在处理财务操作时需要保持隐私性，以保护如付款金额等敏感信息。为满足这一需求，Stable 正在开发**隐私转账（Confidential Transfer）功能**，以在隐私保护与监管合规之间实现平衡。
- [保证区块空间（Guaranteed Blockspace）](/cn/architecture/usdt-specific-features/guaranteed-blockspace): 随着稳定币的持续发展，越来越多的企业将其纳入财务操作中，例如支付、资金调拨和跨境结算。这一趋势在那些获取稳定法币受限的地区尤为明显。在非洲、拉丁美洲等通货膨胀严重、货币管控严格的市场，稳定币正逐渐成为这些地区企业持续运营的关键工具。
- [概览](/cn/architecture/usdt-specific-features/overview): Stable 是一条专为 USDT 打造的 Layer 1 区块链网络。协议的每一个组件都围绕 USDT 的无摩擦转账进行优化，致力于为全球最广泛使用的稳定币提供一个高性能、简洁流畅的运行环境。
- [USDT as Gas](/cn/architecture/usdt-specific-features/usdt-as-gas-token): Stable 是围绕 USDT 稳定币构建的。USDT0 是 USDT 的原生跨链版本，是支撑 Stable 生态系统的核心资产。
- [USDT 转账聚合器](/cn/architecture/usdt-specific-features/usdt-transfer-aggregator): 作为一条专为 USDT 交易优化的区块链，Stable 被设计用于处理极高频次的代币转账，同时保持系统的整体响应。为了在优化 USDT 特定性能的同时兼顾一般交易的多样性，Stable 引入了 USDT 转账聚合器机制。这是一种高效、可扩展的解决方案，可对 USDT0 转账进行高度并行化和容错处理。
- [Consensus](/cn/architecture/core-optimization/consensus): 在初始阶段，Stable 区块链采用 **StableBFT**，这是一个基于 CometBFT 定制的权益证明（PoS）共识协议，旨在确保网络具备高吞吐量、低延迟和高鲁棒性。其主要优势包括高确定的最终确定性以及强大的容错能力（即便有 1/3 验证者失效或作恶，网络仍可保持安全）。
- [执行层](/cn/architecture/core-optimization/execution): **Stable EVM** 是 Stable 区块链的以太坊虚拟机兼容执行层，使用户能够通过现有的以太坊工具和钱包（如 MetaMask）无缝与链进行交互。Stable EVM 结合了 EVM 的开发体验与 StableSDK 的模块化、高性能基础设施。
- [高性能 RPC](/cn/architecture/core-optimization/high-performance-rpc): 在构建高性能区块链的过程中，仅仅优化共识机制或出块速度是不够的。**RPC 层** 是区块链与用户之间的接口，是实现端到端用户体验的关键组成部分。Stable 提出一种高性能 RPC 架构，旨在突破传统 RPC 的性能瓶颈。
- [概览](/cn/architecture/core-optimization/overview): 一笔区块链交易从提交到最终确认，需要经历多个紧密相连的阶段。交易首先通过 **RPC** 提交，进入 **内存池（mempool）**，被打包进区块后通过 **共识机制** 验证，再由 **状态机（state machine）** 执行，最终写入 **数据库** 进行持久化。只有在完成整个流程后，用户才能收到确认结果。
- [StableDB](/cn/architecture/core-optimization/stable-db): 区块链端到端性能的主要瓶颈之一是 **磁盘 I/O（Disk I/O）**。尤其是在区块执行后提交和存储状态数据的操作，是性能的关键瓶颈。Stable 通过架构创新，使用如 `MemDB`、`VersionDB` 以及文件内存映射存储（`mmap`），显著提升系统吞吐量。
- [Autobahn](/cn/architecture/core-optimization/appendix/autobahn): 现代拜占庭容错（BFT）共识协议通常运行在部分同步模型下，该模型假设在某个不确定的时间点后，网络最终会变得稳定，消息传递延迟会有上限。虽然这个模型在协议设计上是实用的，但现实部署中很少能享受长时间的持续稳定。相反，系统经常经历同步阶段后出现短暂中断，如延迟激增、节点宕机或恶意攻击。这些短暂中断被称为 **“突变（blips）”**。