StableBlockchain is a nation. In blockchain, the consensus algorithm is the law of physics, validators are members of parliament, dApps are companies, and the native token is the reserve currency. Then how can we calculate the GDP of a blockchain? From the perspective of MV=PQ, the GDP of a blockchain can grow when TVL and the velocity of money increase.
From this perspective, USDT is a key driver of blockchain GDP growth. In terms of money supply, it has the third highest market capitalization after BTC and ETH, and when calculating the velocity of money, it reaches an astounding figure of around 100. However, there is still no blockchain specialized for USDT, and it is mostly used on slow and expensive chains like Ethereum and Tron.
Stable is a network for USDT. Stable provides 1) USDT-specific features and 2) high scalability through blockchain core optimization to support this.
Through support for EIP-7702 and ERC-4337, Stable enables users to perform all network activities with only USDT holdings, and allows free USDT transfers. In addition, Stable provides USDT-specialized features such as Guaranteed Blockspace, USDT Transfer Aggregator, and Confidential Transfer, making it easier for enterprise users to utilize stablecoins.
In terms of scalability, Stable introduces comprehensive optimizations from RPC to consensus, execution, and DB. Initially, it uses a CometBFT-based consensus with an EVM execution layer, but later plans to maximize network scalability through full-scale upgrades including a DAG-based BFT called Autobahn, Stable RPC, StableVM++, and Stable DB.
Stable can easily attract existing massive USDT liquidity through USDT0, and since it is fully-compatible with EVM, various DeFi ecosystems for USDT can be built. With free transaction fees for USDT0, USDT will be traded at an extremely fast pace. Considering all of these characteristics, Stable has the potential to achieve enormous on-chain GDP from the perspective of MV=PQ, and can position itself as a hyper-scale digital nation for USDT.
Since the beginning of the Trump administration, interest in blockchain and cryptocurrencies has surged. Companies around the world, both public and private, including Strategy, have begun holding part of their corporate treasury in Bitcoin or Bitcoin ETFs. Some are buying and accumulating Ethereum or Solana, while major financial institutions are releasing various RWA products built on blockchain.
As blockchain technology and cryptocurrencies increasingly integrate into traditional finance, new perspectives on blockchain networks have emerged. In particular, traditional financial institutions often treat crypto like stocks and apply conventional valuation models. While this mental model can apply to dApps, I would argue that we should view blockchain not as a company, but as a nation.
A blockchain is a nation where anyone can freely engage in various activities in a trustless and permissionless environment. The consensus algorithm is the law of physics. Validators are the members of parliament. dApps are corporations. The native token is the reserve currency.
Source: Fidelity
If blockchain is not a company but a nation, can we not apply the concept of GDP to it? Both Fidelity and Bankless have introduced this idea before. GDP is defined as the total market value of all final goods and services produced within a country over a specific period, and there are several ways to calculate it. The most well-known expenditure-based formula is as follows:
GDP = C + I + G + (X - M)
Here, C represents private consumption, I stands for business investment, G is government spending, and (X - M) is net exports. Since one party’s production is another’s expenditure, the sum of spending by households, businesses, government, and net exports equals GDP. Fidelity defined the blockchain equivalents of C, I, G, and X minus M in its report as shown in the table above.
Besides the expenditure approach, there are other ways to express GDP. One of them is the equation of exchange, MV = PQ, which is an accounting identity representing the relationship between money and total spending. In this formula, M is the money supply, V is the velocity of money, P is the price level, and Q is the real output. P times Q equals nominal GDP. This means GDP can increase as money supply and velocity rise.
Applying MV equals PQ to blockchain, the GDP of a digital nation like a blockchain can grow when its money supply, or TVL, increases and the velocity of money, or the rate at which assets circulate within the blockchain, becomes higher.
Source: Token Terminal
When viewing blockchain as a nation, USDT is the key driver of GDP growth:
From the Money Supply (M) Perspective: USDT has the 3rd largest market capitalization in crypto after BTC and ETH, standing at approximately $160B. The total TVL of DeFi protocols on the Ethereum network is about $65B, yet the amount of USDT on Ethereum alone is around $74B. On Tron, the total TVL of all assets on the network is about $86B, of which $80B is USDT. In effect, USDT functions as the reserve currency of the blockchain ecosystem.
From the Velocity of Money (V) Perspective: Unlike other cryptocurrencies, stablecoins are designed to maintain their value pegged to fiat currencies in order to maximize usability. According to statistics, USDT has 443M users globally, and processes roughly 21M transfers per day, with a total daily volume of around $46B. Based on this, the velocity of USDT comes out to an astonishing value of about 100. For comparison, the velocity of US M1 money supply is roughly between 1.2 and 1.6.
Scene from “No Country For Old Men”
Source: rwa.xyz
From the MV equals PQ perspective, USDT is a first-class citizen. Yet there is no blockchain nation built for USDT. Currently, USDT mostly resides on the Tron network ($78B) and the Ethereum network ($71B), with smaller amounts on Solana ($1.9B), Arbitrum ($1.3B), and Avalanche ($1.1B). However, neither Tron nor Ethereum is a network suited for USDT.
Source: Token Terminal
Tron’s USDT adoption grew rapidly after it was initially adopted as a deposit and withdrawal network by Binance. Interestingly, 99.3% of all transactions on the Tron network today are USDT transactions, and 98.7% of gas usage comes from USDT transfers. In essence, it would not be an exaggeration to call Tron a USDT chain.
Source: Token Terminal
Even more remarkable is that over the past year, the network that generated the highest transaction fees was not Ethereum, Solana, or Bitcoin, but Tron, producing a total of $3.2B in transaction fees. Around 99% of these fees originated from USDT transactions. This means that although Tether is the issuer of USDT, nearly all the revenue from its transfer activity flows into the Tron ecosystem.
Of course, Tron has higher scalability than Ethereum, which makes it advantageous for USDT transfers. Even so, Tron’s transaction fee per transfer remains relatively high at around $0.2, and its DeFi TVL is only around $5B, indicating limited ecosystem activity. In short, Tron is heavily used for USDT transfers due to early momentum and its initial exchange integrations, but it cannot be considered a network truly optimized for USDT use.
Source: USDT
Stablecoins are an unstoppable trend. Led by the GENIUS Act in the United States, the global stablecoin industry is poised to grow at an unprecedented pace, and USDT is no exception. If USDT continues to grow at its current rate, its market capitalization is expected to reach between $350B and $400B by around 2030.
USDT is a first-class citizen in the blockchain ecosystem. The blockchain industry now needs a better-suited network environment built specifically for USDT. If a blockchain emerges that is optimized for USDT usage, it could establish itself as the next-generation mega digital nation, backed by USDT’s strong network effects.
Source: Stable
Using stablecoins on existing blockchain networks has always come with certain inconveniences. Users engaging in stablecoin transactions still had to hold volatile tokens to pay gas fees. Fee estimation was difficult, and network activity caused high variability in transaction costs.
Now imagine you are designing a blockchain optimized for seamless USDT usage. What kind of features would you include?
First, high scalability is a must. As seen earlier, USDT has extremely high velocity. This means a massive volume of transactions occurs frequently. To handle this, the network must be highly scalable.
Second, users should be able to use the network entirely with USDT. They should not need to hold any other tokens. For businesses, being able to predict fees with stability is crucial in using a blockchain for payments and remittances.
Third, the fees must be low or free. Because stablecoins are used for high-frequency payments and transfers, the network must charge very low fees or possibly none at all to allow frictionless use of USDT.
Stable is a network created with this exact mission in mind. It is an L1 blockchain specialized in remittances and payments with stablecoins, particularly USDT. Stable offers high scalability through core blockchain optimizations and provides USDT-focused features, enabling anyone to use USDT and other stablecoins for remittance, payment, DeFi, and more with ease.
Source: Stable
From a business standpoint, Stable also offers the most optimized environment for USDT. Not only has Paolo, the CEO of Tether, invested in the project, but so have Bitfinex, where Paolo serves as CTO, and USDT0, which handles USDT’s cross-chain infrastructure. These investments legitimize Stable as a blockchain built for USDT and lay the foundation for smooth business development going forward.
Stable is a network built for USDT and provides the following features:
USDT as Gas Token
Gas-free USDT0 Transfer
Guaranteed Blockspace
USDT Transfer Aggregator
Confidential Transfer
Source: Stable
Users can seamlessly do various things on Stable using USDT. Stable basically adopts EIP 7702 and account abstraction to allow users to perform all activities on the network even if they only hold USDT0. But if you look at how it works under the hood, there are actually two types of USDT in the Stable ecosystem. One is gasUSDT and the other is USDT0.
4.1.1 USDT0
USDT0 is a token based on LayerZero’s OFT (Omnichain Fungible Token) standard that enables seamless USDT usage across ecosystems without liquidity fragmentation. Before USDT0 existed, bridging USDT across different chains often caused liquidity fragmentation due to the involvement of various third-party bridges. For example, when bridging USDT from Ethereum to Arbitrum, one could use 1) the official rollup bridge or 2) a third-party bridge. The USDT bridged via these methods would not be compatible with each other, leading to fragmented liquidity.
USDT0 solves this problem through a burn-and-mint mechanism. It facilitates USDT bridging to networks that do not support native USDT issuance through the following steps:
Asset Locking: If a user sends USDT from Ethereum to another network (A), the USDT is locked in a smart contract on Ethereum.
USDT0 Minting: Once the lock is verified, an equivalent amount of USDT0 is minted on the destination chain (A).
Seamless Cross-Chain Transfers: To transfer USDT0 from chain A to chain B, USDT0 is not locked on chain A and minted on chain B. Instead, USDT0 on chain A is burned, and the same amount is freshly minted on chain B. The USDT0 on chain B still reflects the original USDT locked on Ethereum.
Redemption: If the user wants to redeem USDT0 back to native USDT, the USDT0 is burned and an equivalent amount of USDT is released on Ethereum.
Source: Dune (@sealaunch_team)
Because USDT0 offers an experience almost identical to native USDT on networks that do not support native issuance, it has been adopted by various chains such as Arbitrum, Berachain, Unichain, and Optimism. The total circulating supply of USDT0 has reached approximately $1.3B
Stable also adopts USDT0, enabling users to interact with USDT without any liquidity fragmentation within the network. Moreover, because USDT0 allows easy access to the massive liquidity of existing USDT, it is expected to serve as a catalyst for rapid growth of the Stable ecosystem.
4.1.2 gasUSDT
gasUSDT is the token used for paying transaction fees on Stable. When a user transfers tokens other than USDT0 or interacts with smart contracts such as DeFi, gasUSDT is used to pay the gas. gasUSDT carries the same value as USDT0.
Basically, users do not need to interact with gasUSDT. This is because Stable supports EIP-7702 and account abstraction, allowing users to perform all transactions on the network as long as they hold only USDT0. However, if they really want to, how can they obtain gasUSDT within the Stable ecosystem?
The first method is the free unwrap feature. Since unwrapping USDT0 into gasUSDT is provided for free through account abstraction, users can easily acquire gasUSDT after bridging USDT0 through Stable. Second, by using the gas conversion feature during the LayerZero bridging process. LayerZero supports automatic gas conversion, which allows users to receive a small amount of the destination chain’s gas token when bridging. Through this, users can obtain a small amount of gasUSDT while bridging USDT or USDT0.
Note that USDT0 can be treated almost identically to native USDT due to its design. It is compatible not only with networks like Ethereum and Solana that support native USDT issuance, but also with exchange deposits and withdrawals on platforms like Binance and Bybit. However, gasUSDT is a gas token used only within the Stable network. Because of the risk that users may mistakenly send it to other networks or exchanges, its transfer is restricted. Even so, users can easily obtain gasUSDT simply by holding USDT0 and unwrapping it for free.
Stable provides EIP-7702 and Account Abstraction so that users can perform all activities within the ecosystem even if they only hold USDT0 and do not have gasUSDT. In particular, if the user's transaction is simply transferring USDT0, it can be done free of charge.
4.2.1 Account Abstraction
Source: Takenobu T.
There are two types of Ethereum accounts. One is an EOA (Externally Owned Account), which is controlled by a private key like MetaMask that we commonly use. The other is a CA (Contract Account), which is created when a smart contract is deployed. A CA has EVM code that contains the logic of the smart contract and storage that holds the contract's data. EOAs can execute transactions directly, while CAs cannot. A CA must receive a call from an EOA to execute a transaction.
This structure provided an intuitive developer experience by separating user accounts and smart contract accounts. However, from a user experience perspective, EOAs have many inconveniences such as: users lose wallet ownership if they lose their private key, EOA signatures are only possible with the ECDSA algorithm, which reduces wallet design flexibility, and users must hold ETH to execute transactions through EOAs.
Account abstraction aims to simplify this by abstracting EOA and CA into a single account type, so developers and users do not need to distinguish between them. It allows EOAs to utilize the diverse functionalities of CAs and enables CAs to execute transactions like EOAs, combining the strengths of both.
How can this be implemented? Transaction execution is divided into two steps: verification and execution. First, on the Ethereum protocol layer, the transaction is verified to check whether the initiator is the correct account using the private key and whether the transaction is valid. Second, on the Ethereum execution layer, the transaction data is executed, and the EVM state is updated accordingly. For CAs to execute transactions directly, the verification step originally performed on the protocol layer must be moved to the execution layer. This is the key to implementing account abstraction.
Account abstraction improves user experience significantly by enabling the following:
Gas Abstraction: Users can pay gas in tokens other than ETH, or the dApp or another account can pay the fee on their behalf. Users can interact with the network without holding gas tokens.
Signature Algorithm Flexibility: Instead of being limited to ECDSA, users can choose from Schnorr, BLS, or quantum-resistant algorithms.
Customizable Verification Logic: Features like multisig (control by multiple private keys), periodic key rotation, and other custom verification methods are supported.
Multicall Functionality: Previously, interacting with a smart contract required signing two separate transactions: “approve” and the actual transaction. Account abstraction allows combining them or pre-authorizing for repeated interactions, greatly improving usability.
Social Recovery: Users can designate trusted friends, family, or their other devices as guardians when creating a wallet. If the private key is lost, these guardians can cooperate to recover access by assigning a new key.
4.2.2 ERC-4337
There have been various attempts to implement account abstraction in Ethereum, but the most widely used standard today is ERC-4337. This is because ERC-4337 enables easy implementation of account abstraction without changing the Ethereum protocol, through features like EntryPoint, Bundler, and Paymaster.
In ERC-4337, users sign a separate object called UserOp instead of a transaction, and send it to a separate off-chain mempool called the UserOperation mempool, not the official Ethereum mempool. While validators used to verify mempool transactions, ERC-4337 uses a Bundler to validate UserOps and bundle them into a single Bundle transaction, which is sent to a smart contract called EntryPoint.
EntryPoint is the core smart contract of ERC-4337, verifying and executing UserOps while handling gas settlements in one step. Paymaster can optionally be used to pay gas fees or to allow payment in alternative tokens. If a UserOp includes a designated Paymaster and additional data, EntryPoint processes it so that users do not have to pay gas fees or can use other tokens for gas.
4.2.3 EIP-7702
Although ERC-4337 proposed an innovative account abstraction standard, there were practical challenges for end users. The most common problem was that to use account abstraction, users had to transfer funds from their original EOA to a newly created CA, introducing friction and hindering adoption of ERC-4337.
EIP-7702 solves this issue. Introduced in the Ethereum Pectra upgrade, EIP-7702 allows EOAs to temporarily behave like CAs. This is a highly practical standard that lets users keep the UX and address of their existing EOA while using account abstraction features like those in ERC-4337.
To enable this, EIP-7702 introduces a new transaction type. This new type includes an additional field called “authorization_list” alongside the standard fields. It contains signature data authorizing certain contract code to be delegated as the EOA’s own code. This signature essentially expresses consent to temporarily apply that smart contract code to the EOA address. When the EOA executes a transaction, the delegated smart contract logic runs, and after the transaction, the delegation is automatically revoked, restoring the EOA to its original state.
4.2.4 USDT as a Gas Token
Stable adopts EIP-7702 and ERC-4337 so that users can utilize account abstraction features through wallets like MetaMask that they already use. All EOAs in Stable come with EIP-7702 enabled by default, so there is no need to send a separate transaction type for EIP-7702 each time. This means Stable users can use smart wallet features without complex configuration.
One representative feature utilizing this is using USDT0 as a gas token. Stable allows users to pay gas fees with USDT0 instead of gasUSDT, enabling a wide range of activities on the network even if users only hold USDT0:
The user signs a transaction indicating they want to use USDT0 as the gas token.
The transaction is sent to the Bundler in the form of a UserOp.
The Bundler collects transactions and sends them to EntryPoint, coordinating with the Paymaster to prepare gas payments.
The Paymaster converts the user’s USDT0 into gasUSDT and pays the required gas fees on the Stable network.
The user's EIP-7702 smart account calls the actual smart contract, allowing the user to interact with dApps using only USDT0, without holding gasUSDT.
4.2.5 Gas-free USDT0 Transfer
Stable enables users to send USDT0 free of charge. This is also made possible by the combination of EIP-7702 and ERC-4337:
The user signs a USDT0 transfer transaction with an EIP-7702 enabled account.
The signed UserOp is sent to the Bundler network.
The Bundler includes the transaction in a bundle and sends it to EntryPoint, coordinating with the Paymaster to prepare gas payment.
The Paymaster covers the gas fee for executing the transaction, and EntryPoint processes it so that the user’s USDT0 transfer is completed without any gas cost.
While individuals also benefit, it is especially important for businesses to be able to rely on stablecoin-based payments and transfers for their operations. If the network suddenly becomes congested and causes issues in payment or remittance services, it could severely impact their business. To address this, Stable plans to introduce a Guaranteed Blockspace feature.
Guaranteed Blockspace is a service that reserves a portion of Stable’s block capacity for subscribed users. This ensures that even during times of network congestion, these users can rely on a guaranteed amount of blockspace, allowing them to use the service consistently and without disruption.
To ensure that subscriber transactions are reliably included through Guaranteed Blockspace, three things must be implemented: 1) a dedicated mempool that holds subscriber transactions separately, 2) validators must pre-allocate part of each block for these transactions, and 3) a dedicated RPC must be provided so that subscribers can reliably send their transactions.
Stable not only offers gas-free USDT0 transfers but also introduces a USDT Transfer Aggregator to further enhance the efficiency of USDT0 transfers. This mechanism batches and processes USDT0 transfer transactions separately without affecting other types of transactions, aiming to deliver a better user experience.
While traditional ERC-20 transfers are processed sequentially and therefore slow, Stable uses precompiled contracts to compute account balances and transfer diffs in parallel. By collecting USDT0 transfers and processing them together at once, the network significantly improves transfer throughput.
Each USDT0 transfer consists of a sender and a recipient. For these transfers, the net change or diff is calculated per account. For example, if A sends 100 USDT to B, then A’s diff is minus 100 and B’s diff is plus 100.
Verification is also performed in parallel. The total amount sent must equal the total amount received, and each account’s balance is individually verified to ensure it can cover its diff. For instance, if A has 120 USDT0 and the diff is minus 150 USDT0, this is invalid and account A will be flagged.
One challenge in batch-processing USDT0 transfers this way is the possibility of conflicts. For example, multiple transfers might involve the same account. To prevent this, Stable pre-detects such overlapping transactions and flags high-risk transfers that might lack sufficient balance. If a specific account is short on funds, Stable isolates the transfer at the account level to ensure it does not affect others.
Privacy is essential in financial systems. While transparency is often cited as a strength of blockchains, in the context of finance, transparency is closer to a bug than a feature. Because Stable is a network optimized for stablecoin remittance and payments, privacy is critically important. Accordingly, Stable plans to introduce privacy features in the future using ZK technology.
Confidential transfers on Stable will disclose the sender and recipient addresses to comply with regulation, but the transferred amount will remain hidden. Only the sender, recipient, and authorized regulatory entities will be able to view the transaction amount. This ensures that even with confidential transfers, funds cannot be used illicitly.
Stable not only provides various features optimized for USDT but also enhances the scalability of the blockchain to efficiently handle large volumes of USDT transactions.
When a user initiates a transaction, it passes through the RPC interface, is added to the mempool, included in a block, verified through the consensus algorithm, changes the blockchain’s state via execution, and is finally stored in the blockchain’s database. Even if one part of this process is improved, any underperforming segment can become a bottleneck. Therefore, improving blockchain scalability requires comprehensive performance enhancement across all components.
Stable aims to optimize every component involved in the transaction lifecycle. Its technical roadmap is as follows:
Consensus: Initially, Stable will use StableBFT, an optimized version of CometBFT, and later upgrade to Autobahn, a DAG-based BFT consensus algorithm.
Execution: Based on the fully EVM-compatible Stable EVM, Stable will later introduce a parallel execution engine built on BlockSTM and a high-performance EVM client.
Database: In the future, Stable plans to decouple state commits from storage and optimize the database by introducing memory-mapped (mmap) functionality.
RPC: Stable will optimize RPC by separating read and write paths, optimizing EVM view calls, and embedding an indexer.
Let’s explore how Stable optimizes performance for each component in more detail.
5.1.1 StableBFT
At launch, Stable uses StableBFT, a consensus algorithm based on CometBFT. This provides instant finality, eliminating the possibility of forks and making it ideal for financial systems. To further enhance the performance of CometBFT, StableBFT plans to introduce the following improvements:
Decoupled transaction and consensus gossiping: In CometBFT, nodes handle both transaction propagation and consensus message dissemination over a single P2P network. StableBFT separates these channels so that congestion in one does not impact the other.
Direct transaction broadcasting to the block proposer: In CometBFT, transaction propagation happens peer-to-peer across nodes, which can burden the network. StableBFT improves this by broadcasting transactions directly to the block proposer, reducing unnecessary network load.
5.1.2 Autobahn
In the future, Stable plans to further enhance consensus scalability by introducing Autobahn, a DAG-based BFT consensus protocol.
BFT protocols generally fall into two categories: traditional view-based BFT (e.g., CometBFT, Hotstuff) and DAG-based BFT (e.g., Narwhal-Tusk):
View-based BFT has the advantage of low latency under normal network conditions, but suffers from slow recovery when intermittent failures or blips occur. During such disruptions, unprocessed requests accumulate as a backlog, and even after the network recovers, this backlog can cause delays in consensus.
DAG-based BFT offers faster recovery from failures, as data dissemination and consensus are decoupled. Even if consensus halts, data continues to propagate. Once the network stabilizes, a large number of transactions can be finalized at once. However, because all transaction data must be synchronized among nodes to reach consensus, DAG-based BFT tends to have higher latency during normal operation compared to view-based BFT.
Autobahn is a DAG-based BFT protocol that aims to combine the strengths of both models, achieving low latency, high throughput, and strong failure recovery. Autobahn accomplishes this balance through the following key design elements:
Low latency: Autobahn introduces a structure called CAR, allowing consensus to proceed without requiring all nodes to synchronize all data. This reduces the cost of consensus, and by verifying the latest CAR, it becomes possible to finalize previously accumulated transactions, thus lowering consensus latency.
Blip resistance: As a DAG-based BFT protocol, Autobahn completely separates data dissemination from consensus. This allows transaction propagation to continue even when consensus halts. Once the system stabilizes, all pending transactions can be finalized in bulk, making it highly resilient to network disruptions.
Let’s take a closer look at how nodes reach consensus in Autobahn.
Data Dissemination
In Autobahn, all nodes act as block proposers, continuously batching incoming transactions into units called data proposals and broadcasting them. While typical consensus algorithms assign one block proposer per time frame to create and disseminate a block, in Autobahn, each node independently builds its own chain that is not influenced by others. These individual chains are called lanes.
When a node broadcasts a data proposal, other nodes receive and vote on it. Assuming a system of n = 3f + 1 nodes, once f + 1 votes are collected, a PoA (Proof of Availability) is formed. This ensures that at least one honest node in the network possesses the data proposal.
A CAR (Certification of Available Request) is a unit that combines a data proposal and its PoA. It is the minimum structure that guarantees the reliability and availability of the data, serving as a prerequisite for consensus. Each new CAR references the previous one.
Consensus
Since each node generates its own data chain (lane) independently and at its own pace, consensus must be achieved across these chains. Autobahn reaches agreement by performing a BFT consensus on a snapshot called the “tip cut,” which consists of the latest CAR from each node.
Importantly, because CARs always reference previous CARs, finalizing the latest CAR in each lane also finalizes all prior CARs. This is one of the reasons Autobahn can recover so quickly from blips.
Furthermore, since each CAR includes a PoA with votes from at least f + 1 nodes, consensus can proceed without full data synchronization among all nodes. This allows Autobahn to achieve consensus with latency comparable to view-based BFT protocols, despite being DAG-based.
5.2.1 Stable EVM
Stable EVM is an execution layer compatible with the EVM, allowing users and developers to use existing Ethereum wallets, infrastructure, and codebases without modification. Since Stable uses the StableBFT consensus algorithm and its network core includes modules for managing native token transfers and staking, several precompiles are added to Stable EVM to connect these core components.
5.2.2 Roadmap 1: Optimistic Parallel Execution
One of the most common methods to improve scalability in the EVM execution layer is through parallel execution. By default, transactions in the EVM are processed sequentially. However, consider a block that includes a transaction where A sends 1 ETH to B and another where C sends 1 ETH to D. These two are independent and could be executed in parallel, greatly improving processing speed.
Source: MegaETH
In fact, MegaETH simulated blocks from Ethereum block 20000000 to 20010000 and tested parallel execution across blocks of size 1, 2, 5, and 10. They found that parallelizing execution within a single block yielded an average speedup of 2x. Interestingly, increasing the number of blocks grouped for parallel processing did not result in a proportional speed increase and instead converged around a 2.75x improvement. This was due to conflicting transactions within blocks.
The critical factor in parallel execution is whether transactions access or modify the same state. If two transactions conflict, their outcomes may differ depending on execution order, which can cause issues in parallel execution.
Conflict example 1: A sends 1 ETH to B, and B sends 3 ETH to C
Conflict example 2: A and B both mint NFTs from the same contract
Conflict example 3: A calls “approve” on a DeFi contract, while another transaction calls “transferFrom” on the same contract
There are two main methods to detect transaction conflicts in parallel execution.
The first is the state access approach, which determines in advance which state each transaction accesses. Transactions that touch the same state are processed sequentially, while the rest can be executed in parallel. Solana and Sui are examples of networks using this method.
The second method is optimistic parallel execution (OPE), where all transactions are first executed in parallel, and only the conflicting ones are re-executed sequentially. A representative implementation of this is Block-STM, used by chains like Aptos and Monad. Stable also plans to adopt an optimistic parallel execution engine based on Block-STM.
In Stable, OPE operates as follows:
Transactions in a block are passed from the consensus layer to the execution layer.
The transactions are executed in parallel, and ReadSets and WriteSets are recorded. These sets contain the versions and keys of all data read and written during execution.
Stable compares the ReadSets and WriteSets of each transaction to detect conflicts and returns the results.
If a conflict is found, only the conflicting transaction is re-executed. Non-conflicting transactions proceed to the commit stage.
If all transactions are validated with no conflicts, the block is finalized.
In addition to OPE, Stable plans to adopt optimistic block processing (OBP), which pre-executes transactions before the block is fully propagated and finalized, maximizing execution efficiency.
5.2.3 Roadmap 2: StableVM++
Stable also plans to introduce other high-performance EVM implementations in the future. A representative example is EVMONE. The widely used Go-based EVM has the advantage of simple syntax and long-term stability due to extensive use and testing. However, Go is less suitable for low-level optimization and fine-grained memory control compared to C++, resulting in slower performance.
On the other hand, EVMONE is a C++-based implementation developed by the Ethereum Foundation’s Ipsilon (formerly eWASM) team. EVMONE significantly enhances speed and efficiency through direct memory management and advanced optimization. In practice, EVMONE can deliver 5 to 10 times greater performance than Go-based EVMs.
5.3.1 Problems with Traditional Databases
A blockchain’s database is the storage layer that holds and manages the network’s state. State refers to all current data such as account balances, smart contract variables, and token ownership. The state changes every time a block is executed. This process can be divided into two steps:
State Commitment: After executing transactions, the new resulting state is finalized.
State Storage: The finalized state is saved to disk for future verification or historical reference.
Traditional blockchain databases suffer from several issues. First, these two steps—commitment and storage—are tightly coupled. That is, after the state is finalized, the system must wait until it is completely written to disk before executing the next block. If disk writing is slow, the system must pause until it finishes.
Second, loading state data is inefficient. Since state is not stored at fixed disk addresses but scattered randomly across the disk, reading state during transaction execution results in high latency.
5.3.2 StableDB
To solve these problems, Stable introduces two major improvements.
The first is decoupling state commitment from state storage. In StableDB, once the state commitment for the previous block is completed, the node can immediately begin executing the next block, while state storage is handled in parallel.
The second is introducing “MemDB” and “VersionDB” using “mmap.” “mmap” is a technique that maps files stored on disk directly into virtual memory, rather than copying them into RAM. This allows the program to read and write file contents as if they were memory, without needing to call “read()” or “write().”
“MemDB” is a fast, temporary storage layer. It holds recently updated state, such as account balances or frequently traded token data. By using “mmap,” data is accessed at fixed memory addresses, enabling extremely fast reads and writes.
“VersionDB” is a scalable, long-term storage layer. Since it’s not feasible to keep all state in memory, older data is moved to disk. Although not accessed frequently, this data is essential for verification and historical queries.
In summary, StableDB enables 1) parallel execution of the next block before state storage is complete, enhancing network performance, and 2) dramatically faster read/write speeds for frequently used state by leveraging both “MemDB” and “VersionDB.” This structure is already implemented in networks like Sei, which reported a twofold improvement in TPS as a result.
5.4.1 What Is RPC in Blockchain?
In blockchain, RPC refers to the communication method for sending requests to and receiving responses from a node connected to the network. Simply put, it is the interface your web3 wallet uses to interact with the blockchain. Among many types of nodes in a blockchain network, RPC nodes serve as intermediaries between clients and the network. They allow users to submit signed transactions, call smart contracts, and more.
5.4.2 Problems with Traditional RPC
Traditional blockchain RPC nodes are typically implemented by replicating a full node and attaching an RPC endpoint to it. This means that a single node handles multiple responsibilities such as chain synchronization, consensus verification, and RPC response handling, making it heavy and complex. All these functions share the same CPU, memory, and disk, so if other processes are under load, RPC responsiveness slows down.
Moreover, in existing RPC designs, both write and read operations are handled through the same pathways and resources. Despite read requests being far more common than writes, they are not processed separately, making write operations inefficient when overwhelmed by read queries.
5.4.3 Stable RPC
Stable plans to move away from this heavy and complex RPC structure by splitting responsibilities and deploying lightweight, fast edge nodes. Rather than a single node processing all requests, functions are divided—for example, into read-only and write-specific roles—and optimized lightweight nodes are operated for each purpose. Internal testing has shown that Stable's read-only RPC can handle over 10,000 RPS with latency under 100ms.
Additionally, Stable plans to integrate an indexer directly into RPC nodes. This will allow dApps to query the data they need in a single step, without passing through an external indexer. With this design, nodes themselves will be able to fulfill data queries.
To summarize, if we view blockchain as a digital nation, USDT is the key asset driving on-chain GDP growth, and Stable provides an environment optimized for USDT usage through blockchain core optimizations and a wide array of USDT-specific features. So how might Stable be used in practice to create real value for users?
The first use case is as a network for USDT remittance. Users on Stable can send USDT0 transfers for free by default. Stable also introduces features like the USDT Transfer Aggregator to improve the efficiency of USDT0 transactions. From this perspective, people in regions such as Africa, Latin America, and Asia—where access to US dollars is limited—will be able to use Stable as a USDT transfer network. Centralized exchanges like Binance, which handle high USDT volumes, could integrate Stable as a USDT deposit and withdrawal network to significantly reduce operational costs.
The second use case is as a network for USDT payments. Stable provides infrastructure that enables businesses to smoothly accept payments in USDT. For example, if a business uses Guaranteed Blockspace, it can ensure that customer payments are processed reliably even during times of network congestion. Thanks to its high scalability and gas-free USDT0 transfers, Stable could support services like payment processing and debit cards, allowing people without easy access to dollars to pay for goods and services using USDT.
In addition, Stable can easily tap into the massive existing USDT liquidity through USDT0. Its full EVM compatibility makes it possible to build a wide range of DeFi ecosystems around USDT. With zero-cost USDT0 transfers, transactions can happen at very high speed. Considering all these features, Stable has the potential to generate a massive on-chain GDP in the context of MV = PQ and position itself as a super-scale digital nation built for USDT.
