Stable: A Digital Nation of, by, and for USDT

1. Blockchain as a Nation

1.1 Diverse Perspectives on Blockchain

Since the inauguration of the Trump administration, interest in blockchain and cryptocurrencies has been intense. Companies worldwide, both publicly and privately held—including Strategy—have begun holding part of their corporate reserves in Bitcoin or Bitcoin ETFs, and some have started accumulating Ethereum/Solana. Major financial institutions are also launching various RWA products based on blockchain.

As blockchain technology and cryptocurrencies increasingly integrate into traditional finance, new ways of viewing blockchain networks have emerged. In particular, traditional financial circles often regard cryptocurrencies in a manner akin to stocks, applying traditional valuation models. Of course, such mental frameworks can be applied to dApps. However, I believe we should see blockchain not as a company, but as a nation.

Blockchain is a nation where anyone can engage in diverse activities in a trustless and permissionless environment. In blockchain, consensus algorithms are the physical laws, validators are lawmakers, dApps are businesses, and native tokens are the national currency.

1.2 GDP on the Blockchain

If blockchain is a nation rather than a company, can the concept of GDP be applied? Both Fidelity and Bankless have introduced this idea. GDP is defined as the total market value of all final goods and services produced within a country over a certain period. There are several calculation methods, with the most representative expenditure-based formula as follows:

*GDP = C + I + G + (X-M)*

Here, C is consumption, I is investment, G is government spending, and (X-M) is net exports. Since one entity's production is another's expenditure, the sum of consumption, corporate investment, government spending, and net exports amounts to GDP. Fidelity even defined blockchain's C, I, G, and X-M in a similar manner, as shown in the chart above.

However, besides the expenditure approach, there are various ways to express GDP—most notably, the equation of exchange "MV=PQ" that captures the relationship between money and total expenditure. Here, M is the money supply, V is the velocity of money, P is the price level, and Q is real output; P*Q refers to nominal GDP. Thus, as per this formula, higher money supply and velocity can increase GDP.

Applied to blockchain, for the GDP of a digital nation to grow, its total value locked (TVL)—its money supply—must rise, and the velocity—or how fast assets circulate on-chain—must be high.

1.3 USDT: The Key to GDP Growth

If blockchain is seen as a nation, USDT is the core driver of GDP growth:

- Money Supply (M): USDT has the third-largest market cap among cryptocurrencies, after BTC and ETH, at approximately ~$160B. Ethereum DeFi protocols have a total TVL of ~$65B, but the USDT alone on Ethereum is ~$74B. On Tron, total TVL is ~$86B, with ~$80B being USDT—functioning as the de facto reserve currency of the blockchain ecosystem.

- Velocity of Money (V): Unlike other cryptos, stablecoins were created for practical use and are pegged to fiat. Statistics indicate that USDT has 443M global users and processes about ~21M transactions daily, moving ~$46B per day. This results in a V of about 100—an enormous figure (for reference, the US M1 V is 1.2-1.6).

2. No Nation Exists for USDT

2.1 The USDT Diaspora

From the MV=PQ perspective, USDT is a first-class citizen. However, there is no blockchain nation built specifically for USDT. At present, most USDT exists on the Tron network ($78B) and Ethereum ($71B), with smaller amounts on Solana ($1.9B), Arbitrum ($1.3B), and Avalanche ($1.1B), among others. Yet neither Tron nor Ethereum were designed specifically for USDT.

Tron quickly adopted USDT deposits and withdrawals thanks to Binance, leading to rapid growth. Notably, 99.3% of Tron transactions and 98.7% of gas on Tron are due to USDT. In effect, Tron is essentially a USDT chain at this point.

Even more interesting, over the past year, the network with the highest transaction fees was not Ethereum, Solana, or Bitcoin—but Tron, with a staggering $3.2B in fees, about 99% of which were from USDT transfers. While Tether is the issuer, Tron collects immense revenues through these transaction fees.

Certainly, Tron boasts higher scalability compared to Ethereum, making it advantageous for USDT transfers. However, fees per transaction are relatively high (~$0.2 each), and DeFi TVL hovers around ~$5B, meaning the ecosystem remains underdeveloped. Tron's use for USDT transfers is primarily out of inertia from its early adoption, not because it is ideally suited for USDT transactions.

2.2 Time to Build a Nation for USDT

Stablecoins are an unstoppable trend. With the US’s GENIUS Act spearheading, global stablecoin industry growth will be unprecedented, USDT included. If current growth rates continue, USDT’s market cap could reach $350B–$400B by 2030.

USDT is a first-class citizen of blockchain. The industry must provide USDT with a better blockchain network environment.

3. Stable: A Digital Nation of, by, and for USDT

Existing blockchains present many inconveniences for stablecoin users: holding volatile tokens for fee payments, unpredictable fees, and high fee volatility from network usage. If you were to design blockchains for easy USDT use, what features might you add?

- First and foremost, high scalability. As previously discussed, USDT’s velocity is exceptionally high—meaning frequent transactions. High scalability is essential to process this volume.

- Second, users should be able to use the network stably with only USDT. All activities should be accessible while holding only USDT, and businesses must be able to predict fees for secure use as a remittance/payment backbone.

- Third, low fees. Given the frequent remittance/payment activity inherent to stablecoins, networks should offer extremely low—or even zero—fees for USDT transfers.

Stable was created with exactly these goals in mind.

Stable offers the optimal environment for USDT, not only with backing from Tether CEO Paolo and Bitfinex (where Paolo is CTO), but also from USDT0—the cross-chain USDT infrastructure provider. These investments validate Stable as the blockchain for USDT, and will smooth its future business development.

4. Features Optimized for USDT

Stable is a network for USDT, offering these features:

- USDT as a gas token

- Gas-free USDT0 transfers

- Guaranteed blockspace

- USDT Transfer Aggregator

- Confidential Transfer

4.1 USDT0 & gasUSDT

Users can perform seamless activities based on USDT on Stable. Stable introduces EIP-7702 and account abstraction so that holding only USDT0 is sufficient for all network actions. Behind the scenes, there are two types of USDT: gasUSDT (for transaction fees) and USDT0 (for remittance/payment/DeFi).

4.1.1 USDT0

USDT0 is a token based on LayerZero’s OFT (Omnichain Fungible Token) standard, enabling seamless cross-ecosystem transfers without liquidity fragmentation. Previously, without USDT0, USDT was bridged via various third-party bridges, causing liquidity fragmentation.

USDT0 solves this through a burn-and-mint mechanism. It intermediates bridging to networks without native USDT issuance as follows:

1. Asset lock: To send USDT from Ethereum to another network (A), USDT is locked in a smart contract on Ethereum.

2. Issue USDT0: After verifying the lock, the same amount of USDT0 is issued on the destination chain (A).

3. Seamless cross-chain transfer: To move USDT0 from chain A to chain B, USDT0 is burned on A and the same amount is minted on B. USDT0 on B always matches the value of USDT locked on Ethereum.

4. Redemption: To redeem USDT0 for USDT, the user burns USDT0 and can withdraw the equivalent USDT from Ethereum.

With USDT0, users get an almost-native USDT experience, even on networks lacking native issuance. Networks like Arbitrum, Verachain, Unichain, Optimism, etc., have adopted USDT0, whose total issuance approaches ~$1.3B.

Stable has adopted USDT0, too, allowing its users to utilize USDT with no liquidity fragmentation. By leveraging existing mass USDT liquidity, Stable can rapidly accelerate its ecosystem’s growth.

4.1.2 gasUSDT

gasUSDT is the token used for transaction fees on Stable. When sending tokens other than USDT0 or interacting with smart contracts (like DeFi), users pay fees in gasUSDT. gasUSDT always equals USDT0 in value.

Generally, users need not directly acquire gasUSDT, because Stable supports EIP-7702 and account abstraction—holding only USDT0 suffices for all network actions. If desired, gasUSDT can be obtained two ways:

First, via free unwrap: converting USDT0 to gasUSDT is free and seamless via account abstraction, so once users bridge USDT0 to Stable, they can easily get gasUSDT. Second, during LayerZero bridging, the gas conversion feature lets users receive small amounts of gas tokens automatically on the destination chain.

USDT0 is broadly compatible with native USDT on networks supporting it (e.g., Ethereum, Solana), as well as with exchange USDT on Binance, Bybit, etc. But gasUSDT is restricted to Stable to prevent user error via external deposits. Still, as long as users have USDT0, they can easily access gasUSDT via free unwrap.

4.2 How USDT as a Gas Token & Gas-Free USDT0 Transfers Are Made Possible: EIP-7702 & Account Abstraction

Stable provides EIP-7702 and account abstraction, allowing users to do everything with only USDT0, even without gasUSDT. When a transaction simply sends USDT0, users pay no fee.

4.2.1 Account Abstraction

Ethereum has two account types: EOA (Externally Owned Account, like MetaMask controlled by private keys) and CA (Contract Account, created when deploying contracts). EOA can execute transactions directly, while CA cannot—it needs to be called by an EOA.

This design provides an intuitive developer experience by separating user and contract accounts. But for users, it has drawbacks: losing a private key means losing ownership; only ECDSA signatures are possible; and users must always have ETH to execute transactions.

Account abstraction aims to unify EOAs and CAs, so users and developers need only work with a single account type—combining their strengths: EOAs get CA functionality, CAs gain EOA autonomy.

How can this be achieved? Transaction execution involves "verification" and "execution":

First, the protocol checks via private key that a transaction’s sender is valid. Then, the execution layer processes the transaction’s data and updates EVM state accordingly.

4.2.2 ERC-4337

There have been many attempts to implement account abstraction on Ethereum, but the most widely adopted is ERC-4337, as it adds EntryPoint, Bundler, and Paymaster functionalities without changing the protocol.

In ERC-4337, users sign a UserOp object instead of a traditional transaction. Rather than entering the official mempool, UserOps are sent to a separate off-chain mempool. Bundlers validate UserOps and bundle them, forwarding to the EntryPoint smart contract.

EntryPoint is the core smart contract, which validates and executes UserOps, and settles gas fees. Paymasters (optional) are smart contracts that prepay fees or allow alternative token payments; if a UserOp includes a Paymaster and extra data, EntryPoint processes it so users don’t pay gas fees or can pay with non-ETH tokens.

4.2.3 EIP-7702

Despite ERC-4337’s innovation, its practical use faced hurdles. The main issue: for users to benefit, funds had to be moved from an old EOA to a newly created CA, adding friction and slowing adoption.

EIP-7702 solves this. Introduced in the Ethereum Pectra upgrade, it lets EOAs temporarily behave like CAs, dramatically improving the user experience. Now, users retain their familiar EOA interface and address while instantly benefiting from account abstraction.

4.2.4 USDT as a Gas Token

Stable implements EIP-7702 and ERC-4337 so users can leverage account abstraction features directly through wallets like MetaMask—no complex setup needed. All EOAs on Stable are EIP-7702-enabled; users don’t need to submit additional transaction types for EIP-7702. Thus, account abstraction is available out of the box.

One flagship feature is using USDT0 as a gas token. Users can pay gas not only with gasUSDT, but also with USDT0, so even those holding only USDT0 can interact with dApps:

1. When sending transactions, users sign that they will use USDT0 to pay gas.

2. That transaction is passed as a UserOp to a Bundler.

3. Bundler batches transactions and forwards them to EntryPoint, where Paymaster prepares for gas payment.

4. Paymaster converts USDT0 to gasUSDT and pays gas for the transaction on Stable.

5. The user’s EIP-7702 smart account invokes the contract as if holding gasUSDT, but only USDT0 was needed.

4.2.5 Gas-free USDT0 Transfer

Stable processes USDT0 transfers for free, again using EIP-7702 and ERC-4337:

1. The user signs the USDT0 transfer with their EIP-7702-enabled account.

2. The signed UserOp is sent to the Bundler network.

3. Bundler includes it in a bundle, forwarding to EntryPoint, with Paymaster prepping gas payments.

4. Paymaster covers the gas, EntryPoint executes, and the USDT0 transfer is processed for free.

4.3 Guaranteed Blockspace

Enterprises (and individuals) need stable and reliable payments/remittance via stablecoins. If the network gets congested, payment services can be disrupted. Stable plans to resolve this by offering "Guaranteed Blockspace."

Guaranteed Blockspace is a subscription service allocating part of Stable’s block capacity exclusively for subscribers. No matter the network congestion, subscribers’ transactions are assured space in blocks.

Delivering this requires: 1) a dedicated mempool buffering only subscriber transactions, 2) validators pre-allocating block space for these, and 3) dedicated RPC endpoints so subscribers can reliably submit transactions.

4.4 USDT Transfer Aggregator

In addition to making USDT0 transfers free, Stable introduces a USDT Transfer Aggregator to further elevate efficiency. It batches USDT0 transfers, processing these independently from other transactions—offering users a significantly higher experience.

Whereas standard ERC-20 transfer processing is sequential (slow), Stable’s precompiled contract can calculate per-account balance diffs in parallel, batching and processing all USDT0 transfers at once—a drastic increase in throughput.

Each USDT0 transfer consists of a sender and recipient. For each account, a net balance diff is calculated. For example, A sends B 100 USDT, so A: -100, B: +100. Verification is parallelized: total sent must equal total received, and each account’s balance must cover the diff (e.g., A can't have -150 with only 120 USDT0). Such accounts are pre-flagged.

If conflicting transactions share accounts or may lead to insufficient funds, Stable flags and isolates those accounts’ transfers in advance, so they don’t impact others.

4.5 Confidential Transfer

Financial privacy is critical. While blockchain’s transparency is often touted, in finance, this is a bug rather than a feature. As Stable is optimized for stablecoin-based payments and remittances, privacy is key. Stable plans to introduce privacy features based on ZK-tech in the future.

Stable’s confidential transfer will reveal sender and recipient addresses for regulation, but hide transfer amounts. Only the sender, recipient, and authorized regulators will see transfer values, preventing illicit use even after confidential transfers launch.

5. Blockchain Core Optimization

Stable’s USDT-focused features are paired with core scalability improvements to efficiently process massive USDT transaction volumes.

When a transaction is generated, it enters the mempool via RPC, then is included in a block, goes through consensus, is executed (state transition), and finally stored in the blockchain database. Improving any one component without others may cause bottlenecks; thus, end-to-end optimization is required.

Stable aims to optimize every component in the transaction lifecycle. Its technology roadmap includes:

5.1 Consensus

5.1.1 StableBFT

Stable initially deploys StableBFT, based on CometBFT, as its consensus algorithm. Offering instant finality and no forks, it’s ideal for financial applications. StableBFT brings several enhancements over CometBFT:

5.1.2 Autobahn

Stable plans to introduce Autobahn, a BFT consensus protocol, to further scale consensus.

BFT protocols fall into two categories: traditional view-based BFT (e.g., CometBFT, Hotstuff) and DAG-based BFT (e.g., Narwhal-Tusk):

- View-based BFT has low latency during normal operation but recovers slowly from faults (blips), so unprocessed requests backlog and cause post-recovery latency.

- DAG-based BFT recovers quickly from blips (data propagation and consensus are decoupled), so after recovery, batches of transactions can be processed efficiently. Drawbacks include higher latency during normal operation as all nodes must synchronize data.

Autobahn aims to combine the strengths of both—low latency, high throughput, and fault tolerance as a DAG-based BFT protocol.

Let’s look at how Autobahn's nodes reach consensus.

Data Dissemination

In Autobahn, every node proposes blocks—continuously batching incoming transactions as data proposals and broadcasting them. Unlike typical consensus (one proposer per round), each node produces its own "lane" (individual chain), unaffected by others.

Upon receiving a data proposal, other nodes vote on it. Assuming n=3f+1 nodes, once f+1 votes are collected, a PoA (Proof of Availability) is created—confirming at least one node holds the data.

A data proposal + PoA is called a CAR (Certification of Available Request)

—a unit certifying data’s reliability and propagation.

New CARs always reference previous ones.

Consensus

Because nodes independently create lanes, consensus across the latest CARs (called the "tip cut") is executed in a BFT round.

Since CARs always reference earlier CARs, agreeing on all latest CARs completes consensus for previous ones as well—enabling fast recovery after blips.

Additionally, since CARs include PoAs from f+1 nodes, not all nodes need full data synchronization, enabling DAG-BFT protocols to achieve low-latency consensus akin to view-based BFTs.

5.2 Execution

5.2.1 Stable EVM

Stable EVM is an EVM-compatible execution layer, supporting existing Ethereum wallets, infrastructure, and code. Stable uses StableBFT consensus, with core modules for native token management and staking. Several precompiles bridge Stable EVM to these core modules.

5.2.2 Roadmap 1: Optimistic Parallel Execution

Parallelization is a leading method to scale EVMs. By default, EVM processes transactions sequentially. But, for example, A sending B 1 ETH and C sending D 1 ETH could be executed in parallel, doubling throughput.

MegaETH simulated parallel execution from Ethereum block 20000000 to 20010000, batching up to 10 blocks. A single block batch yielded 2x speedups, but increasing batch size led to only ~2.75x improvements, due to conflicting transactions within blocks.

Key is identifying whether transactions touch the same state. If so, parallel execution can produce inconsistent results, so such conflicts must be managed.

Two methods exist: “State Access” (pre-transaction scan for state overlap; sequentialize conflicts, parallelize others—used in Solana, Sui) and “Optimistic Parallel Execution (OPE)” (process all transactions in parallel, re-sequentialize conflicts). Block-STM is a typical OPE method; Aptos and Monad use this. Stable plans to adopt a Block-STM-based OPE engine.

5.2.3 Roadmap 2: StableVM++

Stable plans to employ alternative, high-performance EVM implementations such as EVMONE. The traditional Go-based EVM offers programming simplicity and battle-tested reliability, but lacks raw speed compared to C++, due to limited low-level memory control and optimizations.

EVMONE, from the Ethereum Foundation’s Ipsilon team (formerly eWASM), is C++-based and achieves outstanding speed and efficiency. In practice, it can be up to 5–10x faster than Go-based EVMs.

5.3 Database

5.3.1 Existing DB Issues

Blockchain DBs store and manage on-chain state—e.g., balances, contract variables, token ownership. Every new block execution changes state, in two stages:

1. State Commitment: derive the new state after transaction execution.

2. State Storage: write committed state to disk for future verification and history queries.

Legacy DBs have two major drawbacks: First, the stages are coupled—execution must wait for full disk write before starting the next block. If storage is slow, blocks are bottlenecked.

Second, state reads are inefficient—data is scattered randomly on disk, increasing latency for later access.

5.3.2 StableDB

Stable addresses these by:

First, decoupling commitment from storage. In StableDB, nodes can execute the next block as soon as the previous state is committed — storage proceeds in parallel.

Second, introducing "mmap," “MemDB,” and “VersionDB.”

“mmap” maps disk files directly to virtual memory, letting software read/write files as if in memory, no read()/write() calls needed.

“MemDB” is fast, in-memory temporary storage—holding hot account info, frequently-used token balances, and recent state. Access is extremely fast thanks to direct memory mapping.

“VersionDB” is slower, persistent storage—keeping infrequently used history for verification.

In sum: StableDB 1) allows parallel block execution for higher throughput and 2) leverages the two-DB design to greatly speed up reads/writes for hot state. This design is already used in networks like Sei, achieving 2x TPS improvement.

5.4 RPC

6. Conclusion: The Rise of a Giga-Scale Digital Nation

In summary, seeing blockchain as a digital nation, USDT is the key on-chain asset for GDP growth. Stable leverages core blockchain optimizations, high scalability, and features tailored for USDT, delivering the ultimate environment for USDT utility. How might Stable provide value in practice?

First, as a network for USDT remittance. Users can transfer USDT0 for free; Stable’s USDT Transfer Aggregator enhances efficiency even further. Thus, people in regions with difficult dollar access (Africa, South America, Asia) can easily transfer USDT via Stable, and high-volume CEXs like Binance may support Stable as their deposit/withdrawal network—cutting operational costs.

Second, as a payment network for USDT. Stable supplies infrastructure for businesses to accept USDT payments smoothly. For example, with Guaranteed Blockspace, businesses can process customer payments reliably even under heavy load. Thanks to high scalability and free USDT0 transfers, Stable enables payments and debit card services, helping people bridge the gap to real-world spending even if dollars are hard to access.

Additionally, Stable can rapidly aggregate large pools of existing USDT liquidity thanks to USDT0, and its EVM compatibility fosters a robust DeFi ecosystem centered on USDT. With free USDT0 transfers, USDT will circulate faster than ever. Considering all these features, Stable has immense potential for on-chain GDP (MV=PQ) and is poised to become a giga-scale digital nation built for USDT.

Four Pillars is a global blockchain research firm comprising seasoned professionals who provide research services to international clients. Since its founding in 2023, the company has conducted research with over 100 protocols and enterprises on topics such as stablecoins, decentralized finance, infrastructure, and tokenomics—working to alleviate information asymmetries and support blockchain adoption and growth.

Disclaimer

This article is independent research by the author under the sponsorship of Stable. It is for general informational purposes only; it does not constitute legal, business, investment, or tax advice. Do not base investment decisions or accounting, legal, or tax actions on this article. Mentions of specific assets or securities are solely for informational purposes and are not investment recommendations. The views expressed are those of the author and may differ from those of affiliated institutions, organizations, or individuals. These views are subject to change without notice.

This report is unrelated to editorial direction, and all responsibility lies with the information provider.