Ethereum can be simple enough to understand from a bird’s-eye view: Decentralized applications powered by the same sort of crypto-economic guarantees that underpin Bitcoin. But once you’ve zoomed in to, say, a street-level view, things get complicated rapidly.

Even assuming one has a strong grasp on proof-of-work, it’s not immediately clear how that translates to a blockchain doing more than keeping track of everyone’s unspent transaction outputs. Bitcoin uses computational work to decentralize money. Ethereum uses computational work to decentralize abstract computation. Wut? That abstraction is called the Ethereum Virtual Machine, and it’s the centerpiece of the Ethereum protocol, because “inside” the EVM is the special domain of smart contracts, and it’s the smart contracts that are ultimately to blame for all those ridiculous #defi tweets.

Upgrading the EVM is one of the major milestones of the Stateless Ethereum Tech Tree, and before we can dig in to the interesting work there, I think it’s prudent to first tackle the obvious question: “WTF is the EVM?”. In the first of this two-part series, we’ll get back to basics and try to understand the EVM from the ground up, so that later we can really engage with current discussion about things like Code Merklization and UNGAS— even stuff from the exciting world of Eth2 like Execution Environments!

WTF is the EVM?

When first year Algebra students get taught about that familiar function f(x), an analogy of “the function machine” is often used. The concept of deterministic input/output, it seems, is a lot easier for kids to think about as a literal physical machine chugging along. I like this analogy because it cuts both ways: The EVM, which in a way actually is a literal machine chugging along, can be thought about as a function which accepts as inputs some state and outputs a new one based on some arbitrary set of rules.

Setting aside the specifics of those rules for now, say that the only valid state transitions are the ones that come from valid transactions (that follow the rules). The abstract machine that will determine a new state (S’) given an old valid state (S) and a new set of valid transactions (T) is the Ethereum state transition function:
Y(S, T)= S’

The first thing that’s very important to understand about this function is that, as an abstraction, it’s sort of a mathematical placeholder: arguably not a real thing, and definitely not the EVM. The Ethereum state transition function is written all fancy in Greek in the yellow paper because thinking about the EVM as a black box function really helps with imagining the whole blockchain system (of which the EVM is just one part). The two-way connection between functions and machines is determinism: Given any valid input, both should produce one and only one output.

But the EVM, as I said before, is in some sense a literal machine chugging along out there in the world. The EVM’s physical instantiation can’t be described in the same way that one might point to a cloud or an ocean wave, but it does exist inside thousands of connected computers running Ethereum clients. And at any given time, there is one and only one canonical Ethereum state, and that’s what we care about. All of the other components inside an Ethereum client are there just to keep consensus over which state is the right one.

The term ‘canonical’ is used because ‘valid’ isn’t quite appropriate; a state transition computed correctly is ‘valid’, but it still might not end up “on chain” as part of the canon. Deciding which states are canonical and which states are not is the sole responsibility of miners doing proof-of-work on the chain. Anyone using Ethereum mainnet has, either literally or just figuratively, “bought in” to one particular state history, namely the one with the most computational work put behind it, as determined by Ethereum’s Greedy Heaviest Observed Subtree (GHOST) protocol. Along with each new block on the network comes a new set of transactions, a state transition, and a freshly determined output state ready to be passed forward into the next canonical block, determined by miners. And so on and so forth; that is how the Ethereum blockchain do.

We’ve so far ‘black-boxed’ the EVM as the state transition function (machine) that takes previous valid blocks and a handful of fresh transactions (as input), does some computation on it, and spits out a new valid state (as output). The other pieces of the Ethereum protocol (such as miners choosing canonical blocks) are necessary context, but now it’s time for some inside-the-box thinking. What about those specific rules we set aside earlier? How does the EVM compute a new state? How can a single machine compute everything from simple balance transfers to elliptic curve algebra?

The Steampunk Stack Machine

The best I can do to introduce the notion of a stack machine is this cartoon image of Babbage’s Analytical Engine (credit: Sydney Padua), which was designed in 1837 but never built:

With most people carrying around fantastically powerful electric computers in their pockets these days, it’s easy to forget that computers don’t necessarily need to be electronic, nor all that powerful. Babbage’s Analytical Engine is a very (hypothetically) real example of a Turing-complete (!) computer that if it had been built, would’ve run on steam and punch cards. The EVM is in important ways much closer kin to the Analytical Engine of two centuries ago than to the CPU inside the device you’re using to read this article.

The EVM is a stack machine, and although in reality it’s a virtualized machine running inside many Ethereum clients simultaneously, I find helpful to imagine the EVM as a real, more advanced (but of course still steam-powered) version of the Analytical Engine. This metaphor might seem a little far-fetched, but I implore you to stick with it for a little bit because it’s quite illustrative when we get to the subject of gas and a shared execution environment.

The steampunk EVM would be a mechanical computer that functions by manipulating physical punch cards. Each card would have 256 places for hole punches, and therefore each card could represent any number between 0 and 2^256. To perform a calculation, one could imagine this computer, through some fancy system of compressed air, putting the cards representing numbers and operations into a stack, and following a simple principle of “first in, last out”, one-by-one it would PUSH new cards to the top of the stack, or POP cards from the top of the stack to read them for next steps. These might be new numbers to calculate with, or arithmetic operations like ADD or MULTIPLY, but they could also be special instructions such as to STORE a card or set of cards for later. Because the cards are simple binary, the operations also have to be ‘encoded’ into a binary number; so we call them operational codes, or just opcodes for short.

If the stack machine were calculating 4 * 5 + 12, it would go about it like so:

_POP value 4 from the stack, keep it in memory. POP the value 5 off the stack, keep it in memory. POP the value _ from the stack; send everything in memory to the multiplication module; PUSH the returned result (20) the stack. POP the value 20 from the stack; keep it in memory. POP the value 12 from the stack; keep it in memory. POP the value + from the stack; send everything in memory to the addition module; PUSH the returned result (32) the stack. (Source: The EVM Runtime Environment)

We can imagine opcodes like ADD or MULTIPLY as special modules built into the machine, near enough to the stack so as to be accessible quickly. When the computer must multiply 4 and 5, it would send both cards to the “multiplication engine”, which might click and hiss before spitting back out the number 20 punched into a new card to PUSH back to the top of the stack.

The “real” EVM has many different opcodes for doing various things. A certain minimum-viable set of these opcodes are needed to do generalized computation, and the EVM has all of them (along with some special ones for crypto, e.g. the SHA-3 hash function). For better or worse, the idea that the EVM is (or is not) Turing-complete has long been under discussion— it’s this stack-based architecture which has the property of Turing-completeness: The EVM’s rules of execution can in principle, given a long enough time and big enough memory, run any conceivable computer program so long as it’s compiled down to the correct 256-bit words and executed in the stack.

Compiling a program in our alternate universe would entail the creation of a booklet of punch cards containing the appropriate data and opcodes. This is literally (er, figurative-literally, whatever) the process going on under the hood when you write a smart contract in a high-level language like Solidity and compile it to bytecode. You can get a pretty good sense of how a programming language gets converted into machine code by reading this humerously annotated output of a Solidity compiler.

So far, the state has not been mentioned, but recall that we set out to understand the rules by which a state transition can be calculated. Now we can summarize it a bit more clearly: The EVM is the physical instantiation (read: instance) of the state transition function. A valid state in Ethereum is one that was calculated by the EVM, and the canonical state is the valid state with the most computational work done on it (as determined by the GHOST protocol).

(Ideal) Gas

We might imagine Babbage completing the fictitious Ethereum Stack Engine and thereafter announcing that all mathematical tabulations and solutions for impossibly difficult problems were now within reach. He’d invite mathematicians and engineers to package up their problems as ‘transactions’ and deliver them to be compiled by Lady Lovelace into punch cards to run through the world computer. (Incidentally, Lovelace was the first person to ever write a computer program, making her the original compiler). Since the machine is meant to be an implementation of the EVM and part of a larger Ethereum steampunk universe, we’d have to imagine the state as being some sort of massive Merkleized library catalog which would be updated once per day according to a pre-selected set and order of transactions chosen as ‘canonical’, and committed to archive.

The trouble with this vision is that a real, mechanical EVM would be extraordinarily expensive to run. The turning of gears, winding of springs, and pumping of various pneumatic chambers collating punch cards would use tonnes of coal every day. Who would bear the expense of running the engine constantly? Say that five mathematicians wanted to run their programs on a particular day, but there was only time enough for three. How would these and related problems of resource management be solved? The solution that Ethereum employs seems, paradoxically, a lot more intuitive when we think about a large and inefficient mechanical computer: Charge money for computation and memory storage!

Imagining the the operations of the stack machine to be powered by compressed air, one could measure the exact amount of gas needed to perform an ADD operation, and compare it to the (much larger) amount of gas needed for SHA3. The table of gas costs for each opcode could be made publicly available, and anyone submitting a program required to provide at least enough money for their computation and storage space according to the cost of gas (which might be related to the price of coal or the demand for computation). The final stroke of genius is to make the machine state itself a ledger for accounts and balances, allowing a user to include payment for their computation inside the transaction itself.

As you might know, gas in an Ethereum transaction accounts for computation and memory costs of the EVM. Gas costs for a transaction must be paid for in ETH, and cannot be recovered once the execution takes place, whether the operation succeeds or not. If a contract call runs out of gas at any point during an operation, it throws an out-of-gas error.

The gas mechanic cleverly does two jobs: Gas efficiently allocates the common-pool computational resources of the EVM according to demand, and provides reasonable protection against infinitely looping programs (a problem that arises from Turing-completeness).

In the next installment of “The 1.X Files”

I hope this fanciful mechanical explanation of a stack machine has been helpful. If you enjoyed thinking about the steampunk EVM as much as I have, and you like historically plausible alt-reality comic books, do investigate “The Thrilling Adventures of Babbage and Lovelace” linked earlier; you won’t be disappointed.

Getting a handle on something so abstract isn’t easy, but there are topics in the Stateless Tech Tree that will be much easier to approach with a relatively complete (even if it’s a bit cartoonish) mental image of an EVM implementation.

One such topic is the introduction of Code Merkleization to the EVM, which would greatly reduce the size of witnesses by breaking up compiled contract code into smaller chunks. Next time we’ll be able to dig in to these immediately.

As always, if you have any questions, comments, requests for new topics or steampunk Ethereum fanfictions, please @gichiba or @JHancock on twitter.

Coinbase officially launched Coinbase Payments on June 18, a three-layer platform that enables commerce providers to add USDC checkout without running their blockchain infrastructure.

The stack begins with Stablecoin Checkout, a wallet-native interface that supports hundreds of wallets, delivers gas-free transactions, and records payments in USDC. 

Beneath it, an E-commerce Engine exposes application programming interfaces for authorization, capture, refunds, ledgering, and subscriptions, allowing payment service providers to integrate stablecoin flows into existing merchant dashboards. 

At the base, the Commerce Payments Protocol executes smart contract escrow and settlement on Base, Coinbase’s layer-2 network, in sub-second blocks. 

The company stated that the modular design eliminates the need for “crypto-native teams” and can settle global transactions at a lower cost than traditional card networks.

Early production use at Shopify

Shopify activated the stack last week for an early-access cohort of merchants, marking one of the first retail deployments of USDC at scale. 

Buyers pay in USDC, and Shopify receives fiat payouts unless a merchant opts to retain the stablecoin. 

Stripe helped abstract the crypto logic from sellers’ workflows, and Shopify plans to add 1% USDC cashback incentives for consumers. 

Coinbase stated that Stablecoin Checkout handles consumer interaction, the E-commerce Engine manages merchant controls through APIs, and the protocol layer facilitates smart-contract escrow and settlement behind the scenes.

Market context and adoption target

According to Coinbase, more than half of Fortune 500 firms are experimenting with on-chain tools while roughly one-third of small businesses already accept some form of crypto. 

By making stablecoin rails accessible through a single integration, the exchange aims to position USDC as a default internet payment method.

Additionally, platforms that onboard can add off-ramps to local currencies, audit trails via open-source contracts, and programmable reward systems in a forthcoming update.

Coinbase invited payment processors, marketplaces, and e-commerce software vendors to integrate immediately, noting that the same stack powering Shopify’s rollout is now available through the company’s developer portal.

Mentioned in this article

Deutsche Bank, Memento Blockchain, and Interop Labs published a litepaper on June 17 outlining plans for Digital Asset Management Access 2 (DAMA 2), a tokenization platform intended to operate on public blockchains and facilitate the issuance of regulated funds.

According to the paper, DAMA 2 would link three layers: Ethereum (ETH) would act as the settlement base, Memento Blockchain’s ZKsync-based layer-2 would process transactions with zero-knowledge privacy safeguards, and a top-layer interface would offer an app store with ready-made fund smart contract templates.

The concept is framed as Blockchain-as-a-Service, allowing issuers to launch products without the need to build protocol teams.

To support cross-chain activity, DAMA 2 would integrate Axelar Network’s Interchain Token Service, enabling interoperability with more than 70 blockchains. This multichain setup would give issuers a single dashboard to lock, mint, and burn tokens across networks while preserving fungibility.

The litepaper confirms Deutsche Bank’s earlier initiative, first reported on Dec. 17 last year, to address regulatory barriers tied to public blockchains, using ZKsync technology to cut costs and boost efficiency.

The partners expect to deliver a minimum viable product in the second half of 2025, though no specific launch date has been given.

Regulatory alignment and rollout

Boon-Hiong Chan, Deutsche Bank’s innovation lead for securities and technology advocacy, said the project demonstrates how public blockchains have matured for institutional finance and how applied technologies can achieve resilience and compliance through a single platform. He added that familiar workflows and low learning curves remain essential for adoption.

The litepaper describes modular compliance tools, on-chain investor registries, and expense management features. Privacy would be managed through allowlisted wallets and private RPC endpoints, while Axelar’s hub-and-spoke model could isolate compromised chains if necessary.

Axelar co-founder Sergey Gorbunov called DAMA 2 a compliant pathway for institutions to enter the digital assets space and scale securely across multiple blockchains, noting that vendor fragmentation and isolated liquidity remain industry challenges.

Settlement finality would tie back to Ethereum proofs, and legal agreements would define clear transfer points on layer-2 networks.

Nicola Lanteri, CEO of Memento Blockchain, said the planned Memento ZK Chain would combine a permissioned sequencer with zero-knowledge proofs to give institutions predictable control while preserving the openness of public blockchain networks.

The litepaper projects that asset managers could tap into an estimated $84 trillion intergenerational wealth transfer by 2045, citing Cerulli Associates, and positions DAMA 2 as a way to reach digital-native investors.

Mentioned in this article

April 10th What is a stack (STX)?

The Stacks network acts as a Layer 2 solution for Bitcoin, allowing you to use smart contracts and decentralized applications (DAPP) on the Bitcoin blockchain. Its design introduces features commonly associated with other blockchain platforms like Ethereum, while highlighting the security and robustness of Bitcoin. By acting as separate layers, stacks allow developers to build Bitcoin without changing their core structure and create an extended environment that takes advantage of the decentralised and unreliable nature of Bitcoin.

The stack is unique among the Bitcoin layer because of the independent token STX, which encourages block production and network maintenance that is different from the Bitcoin primary chain. This token model addresses the need for incentive validation while maintaining the simplicity of Bitcoin at the base layer. Furthermore, Stacks differs from other Bitcoin scalability solutions such as Lightning Networks as it maintains a persistent state that is essential for running applications that require data consistency, such as Smart Contracts, as opposed to temporary designs focusing on Lightning transactions.

Another important feature of the stack is to make Bitcoin a productive asset of Decentralized Financial (DEFI) without being wrapped in third-party custodians or non-vitocoin chains. By pinning Bitcoin’s security and using a token-based incentive structure, Stacks enables applications that enhance Bitcoin utility, extending its role from a valuable repository to a decentralized financial product base. This setup facilitates the innovation of Bitcoin’s network without introducing complexity and security risks that directly add programmerity to Bitcoin’s core protocols.

Stacks is hoping to create a scalable ecosystem that utilizes Bitcoin as a decentralized financial foundation, ensuring a future where financial applications and software are locked into Bitcoin security. This layered approach ensures that Bitcoin retains its original simplicity, while Stacks brings a high degree of programmerism, making Bitcoin the basis for a wide range of decentralized applications and financial services.

What is an STX token?

STX tokens play a central role in the Stacks ecosystem, providing incentives and resources for network participants to secure and grow their Layer 2 platform. Unlike Bitcoin, which is only valuable stores and decentralized currencies, STX is designed to support Stacks’ unique features and economic incentives. This includes protecting the network through a mechanism called the mechanism (POX), in which STX owners can “stack” tokens and earn Bitcoin rewards. By committing STX, participants maintain the integrity of their stack blockchain, indirectly support the Bitcoin Layer 2 ecosystem, and blend the Bitcoin security model with new economic incentives for developers and users.

The POX mechanism is one of the innovative ways in which STX enhances the capabilities of STCSS networks by adjusting incentives between the two networks. Through POX, STX owners participate in the consensus process that will allow Bitcoin workplace certification security to act as a separate chain. This not only strengthens Stacks’ decentralized framework, but also encourages the tougher economic ties between Bitcoin and the stack, as the network can reward Bitcoin STX owners. This structure encourages active participation in securing networks without the need for proof-of-mining of traditional work. This otherwise puts a strain on resources and adds complexity.

STX also provides the main fuel to run transactions and promotes ecosystem growth by deploying smart contracts in the stack. Whenever a user interacts with DAPP or initiates a smart contract operation on the network, STX is used to cover transaction fees to ensure that the network remains operational and secure. By assigning costs to transaction processing, the ecosystem blocks spam transactions and encourages efficient use, as well as ETH’s use for Ethereum gas charges. This makes STX essential to network capabilities and utilities, supporting Stacks’ broader goal of scaling Bitcoin use cases without compromising basic security and decentralization.

STX encourages a wider developer and user community by providing staking and investment opportunities. Developers are incentivized to build applications through their economic design, as STX rewards help offset the costs and efforts associated with platform deployment. For investors and ecosystem participants, STX offers a way to take part in the growth of Bitcoin’s Layer 2 expansion, creating economic value related to network success. By using STX as a tool for both infrastructure support and economic growth, the Stacks ecosystem is positioned as a flexible, Bitcoin-powered environment for decentralized innovation.

STX Tokenomics

The Stacks STX token was launched in 2021, and the Genesis block created an initial supply of 1.32 billion tokens, strategically distributed to promote ecosystem growth and development. Of this initial distribution, 32% were allocated through token sales in 2017, while the remaining tokens were directed towards the Stacks Ecosystem Fund (28%), Hiro PBC (25%), and Stacks Foundation (15%). This allocation strategy was structured to ensure balanced funding for development, community initiatives and operational costs, supporting long-term ecosystem sustainability.

The new STX tokens are minted in each block, primarily as rewards for miners and stackers, with annual inflation rates initially set at 10% and expected to drop by 0.5% per year until the stable rate reaches 2.5%. This progressive inflation reduction aims to reward early adopters while maintaining a controlled supply of tokens for the future. Over the course of 20 years, the system will lead to the ultimate STX supply of around 2.04 billion people, encouraging network participation and providing a predictable token technological structure to support a sustainable token ecosystem.

How to buy STX with crypto

1. Log in or sign up to create a Bitfinex account.

2. You will be taken to the deposit page.

3. In the CryptoCurrencies section, select the cryptography you plan to purchase STX and generate a deposit address in your Exchange wallet.

4. Send Crypto to the generated deposit address.

5. Once your funds arrive in your wallet, you can exchange them for STX. Learn how to trade with Bitfinex here.

How to Buy STX with Fiat

1. Log in or sign up to create a Bitfinex account.

2. To have Fiat deposited into your Bitfinex account, you must obtain a full verification. Here you will learn about the various levels of verification.

3. On the Deposit page, under the Bank Wire menu, select the Fiat currency for your deposit. Bitfinex’s Fiat deposits have a minimum amount. Click here for details.

4. For more information about the wire, please check the Bitfinex registration email.

5. I’ll send you the funds.

6. Once your funds arrive in your wallet, you can use them to purchase STX.

Additionally, since you have BitFinex on your mobile, you can easily purchase STX currency while you’re out.

(AppStore) (Google Play)

STX Community Channel

Website| X (Twitter) |Discord|Telegraph