For years Zenon sat in the shadows. Its anonymous founders had handed the flame to a community and disappeared, and the community held something it could never quite grasp with conviction. The pieces were strange and the intent was unstated, so the chain mostly waited, half-understood by the people who believed in it and ignored by everyone else.
The strangeness was real. The founders had split the ledger in two instead of keeping one. They had given the network separate node types with separate jobs instead of one validator doing everything. They had left out transaction fees. They had added a class of infrastructure nodes and never documented what it was ultimately for. At the time none of it was obviously correct, and some of it looked like a mistake. Then they stopped posting, and the code sat mostly as they left it.
What sat there was a settlement layer with no fees, an ordering system no single party controlled, and a base layer deliberately too thin to hold much state. For years no one could say with confidence what those pieces were meant to become.
There is now a specification that answers it.
Zenon now has a production-grade protocol specification for a settlement layer. Implementation-ready, already in developers’ hands, being built quietly by the same kind of pseudonymous builders the network was founded by. The spec doesn’t ask anyone to interpret it. It ships with machine-readable conformance artifacts that are themselves normative: locked gas tables, SMT test vectors, execution conformance vectors. An implementation that diverges from them, byte for byte, is non-compliant. There’s no room left for “what was meant here.” That’s the level of precision that turns “hand it to devs” from a slogan into a literal description of what just happened.
And the document on the table is not the document anyone expected.
It started as something smaller. The work in progress was a WASM smart contract layer for Zenon, a way to bring programmable execution to a chain that never had it. A useful goal, and a bounded one. Then a developer who goes by digitalSloth looked at the same problem from underneath and turned it over. The question stopped being “how do we put a VM on Zenon” and became “what is the smallest thing the base layer has to guarantee so that any VM can run on it.” That inversion is the whole story. The moment execution was treated as a service the settlement layer secures rather than a feature the chain implements, a single WASM layer became a doorway to something much larger, and the spec that came out the other side describes a platform nobody set out to build and everybody now has to reckon with.
What came out the other side is a multi-VM settlement platform: a runtime-agnostic core designed from its first line to anchor any number of independent execution environments at once, each isolated, each able to message the others without a bridge. Feeless. MEV-resistant. Browser-verifiable. Built on a chain that had all of those properties before this spec existed. And because of how that core is shaped, the pieces that run on top of it, starting with the executor, can be packaged as bare single-purpose images with almost no attack surface, which turns out to change what the whole network can become.
If you’ve spent any time in this industry, that paragraph reads like every overpromise you’ve learned to distrust. Feeless, bridgeless, infinitely extensible: the exact vocabulary of a thousand whitepapers that shipped nothing. So this essay does two things at once. It shows why each of those words is structurally true here rather than aspirational, and it draws a hard line, more than once, between what is shipping and what the architecture merely permits. The claims are large. The honesty about their current state is larger. If either half fails to land, the essay hasn’t done its job.
So start with the fact the rest of it depends on. Zenon is not one chain. It is a dual-ledger system: a block-lattice where every account owns its own chain, and a meta-ledger of momentums that periodically commits the global order across all of them. Account chains hold state and let users transact in parallel. Momentums, produced by Pillars, anchor those account chains into a single canonical history. Two ledgers, two jobs, deliberately never fused into one.
That split is the source of everything this essay claims. A single-ledger chain does all its work in one place: ordering, execution, state, fee collection, spam control, the whole load welded into one structure where every decision constrains every other. Fees exist to ration that structure and to pay whoever produces it. MEV exists because whoever produces it chooses the order. Both are baked into the geometry of a one-ledger design, and neither can be removed without starving it. Zenon never had that geometry. By separating the account ledger from the ordering ledger, it pulled apart the two things every other chain fuses, and that single decision is the reason feeless, MEV-resistant, independently verifiable execution is even available to build on. Hold onto that. Everything below is a consequence of it.
Follow it far enough and the multi-VM platform turns out not to be the destination either. It is the first proof of a larger thesis: that infrastructure itself, execution and data and oracles and payments and Bitcoin interoperability, could become a native settlement primitive, with consensus securing a market of services instead of a single application environment. Execution is just the first service to come online.
That combination exists nowhere else. This essay is about why it matters.
Start with the thing a developer can’t get anywhere else
Here is what the ledger split means the moment you try to build on it.
Every VM in the industry inherits the properties of the chain beneath it. If the chain has fees, the VM has fees. If the chain lets a proposer reorder transactions, the VM has MEV. This is not a choice made inside the VM; it is inherited from below. The EVM has no opinion about fees; fees come from Ethereum’s security model. The SVM has no opinion about MEV; MEV comes from Solana’s block production. Every rollup, every L2, every sidechain inherits what its base layer hands down, for better and worse.
And what every base layer hands down is the same, because they all share the same one-ledger geometry: fees, because security is funded by them, and ordering discretion, because someone has to sequence the single ledger. No major smart-contract base layer in production is feeless. Very few, if any, strip ordering authority from the executor before it ever sees a transaction. So no VM on top of them can be feeless or MEV-resistant at the ordering layer, however it is designed. The VM was never the problem. The ledger underneath it was.
Zenon hands down something different, because its ledger is split. Execution is metered by plasma, which is locked capital, not spent: you fuse QSR and reclaim it later, and every operation costs a finite amount of it, so spam is bounded by real capital an attacker has to lock up and gets nothing paid back for. No fee accrues to anyone. No inflation fills a gap, because there is no gap; security was never funded by per-transaction fees. And ordering, the thing that produces MEV everywhere else, was handed to the momentum ledger entirely. By the time the executor sees a transaction, momentum height and the content order inside the momentum hash have already fixed its place. The executor inherits an order it cannot touch.
So the property belongs to every runtime, not one. Any VM registered on Zenon’s settlement layer gets feeless admission and ordering-layer MEV resistance the moment it registers, because those come from the ledger underneath, not from the VM. A Solidity-compatible EVM domain could inherit Zenon’s feeless admission and canonical ordering while keeping the tooling developers already know. A Move domain, feeless and MEV-resistant, with the toolchain Sui and Aptos developers already use. An SVM domain, a Cairo domain, a purpose-built financial VM: each inherits the same base, because the base does not care what runs on top of it. None drops in untouched, gas accounting and nonce rules and transaction semantics still have to be mapped to the settlement model, but that is adapter work. The hard part, the part no other base layer can offer, comes free.
Now the consequence for a builder. Someone who wants to launch an execution environment on a feeless, MEV-resistant network does not have to build a new chain. Does not have to bootstrap a validator set, mint a security token, or talk anyone into abandoning their existing tooling. They register a domain, bond an executor, and bring their VM. The toolchains, the libraries, the developer communities: all of it travels with the runtime.
That is not a faster chain or a cheaper chain. It is a different relationship between the VM and everything below it.
Which raises the question the next section answers: if the VM is no longer the thing that defines the chain, what is?
The VM was never the platform
In every ecosystem you know, the virtual machine is the identity. Ethereum is the EVM. Solana is the SVM. The chain and its execution environment are fused; changing the VM means building a different chain.
Project Zeno inverts that. It does not add another VM. It makes the VM replaceable.
The settlement contract manages a concept called an execution domain: a runtime, a state-transition function, a bonded executor, and a state-root lineage, bundled under a single domainId. Phase 1 registers one domain: WASM. But runtimeKind is a field in a domain record, not a property of the protocol. The settlement core has no opinion about what occupies that field. WASM today. EVM, Move, SVM, Cairo, a zkVM, a purpose-built financial VM tomorrow: each is a new domain handler compiled into the node and activated by governance. No migration. No rewrite. No disturbance to anything already running.
In most ecosystems, the VM is the platform and settlement is an implementation detail. Here, settlement is the platform and VMs are the implementation details.
That single inversion turns execution environments into services under one settlement truth, and it changes what the permanent object in the system even is. Everywhere else, the VM is the fixed point and the rest of the stack is built around it; the execution environment is load-bearing identity, the one thing that can never be swapped. Here that relationship flips. Settlement is the permanent object. The VMs are tenants. A runtime can be added, deprecated, or replaced, and the chain underneath it persists unchanged, because the chain was never defined by any runtime in the first place. That is not how blockchains are usually structured. It is how operating systems are structured: a stable kernel that outlives the applications running on top of it, where programs come and go and the system endures. Zenon’s settlement layer is closer to a kernel than to a chain, and the VMs are closer to processes than to ecosystems. Most chains are an application that happens to have a ledger. This is a ledger that can host any application class anyone writes for it.
And the inheritance is wider than the developer section let on. Feelessness and MEV resistance were the headline, but force inclusion and independent verifiability fall out of the same place, the settlement layer rather than any VM. Four properties, none of them engineered into a runtime, all of them inherited at once by every domain that registers.
Multiple VMs run simultaneously as peers under the same settlement core, from the moment the second domain registers. Not sequentially. Not in separate ecosystems. Concurrently. Each with its own executor, its own isolated custody, its own state-root lineage, its own fraud-proof path. The isolation is total: a faulty executor in one domain cannot reach another domain’s custody. Conservation accounting is keyed per (domainId, asset). One bad runtime cannot contaminate the platform.
Every runtime talks to every other runtime. Without a bridge.
This is the part most people walk past, and it may be the most important property in the entire design. One caveat up front, because it’s the one a skeptic reaches for immediately: this is not a cross-chain interoperability claim. It is not LayerZero, not IBC, not a new omnichain messaging layer promising to connect everything to everything. It is narrower and, precisely because it’s narrower, actually solid. It applies only between domains that already share Zenon’s settlement layer; cross that boundary and the hard problems come straight back.
In the current industry, if a contract on one VM needs to interact with a contract on a different VM, there is a bridge in between. Bridges are the connective tissue of a fragmented ecosystem, and they are the single largest source of catastrophic loss in the history of this space. They introduce trusted intermediaries, multisig committees, or optimistic assumptions about relayer honesty. They fragment liquidity. They add latency. They create attack surfaces that have cost billions of dollars.
The reason bridges exist is structural: each chain has its own consensus, its own state, its own finality. To move information or value between them, something has to attest that one chain’s state is valid from the perspective of another. That attestation is the bridge, and it is the point of failure.
Project Zeno’s domain model removes that structural reason, between its own domains. Bridges exist because chains do not share truth; Project Zeno domains share truth through Settlement. All domains settle to the same contract, on the same L1, under the same consensus. There is no attestation gap. When a WASM contract needs to send a message to a Move contract, the message doesn’t leave the settlement layer. It goes into the WASM domain’s outbox. The batch finalizes. The outbox root is committed on-chain. Anyone can then relay that message into the Move domain’s input stream using a permissionless RelayMessage transaction, proven by an inclusion proof against the committed outbox root. No multisig. No trusted relayer. No optimistic window. The proof is verified against data that L1 already has.
WASM-to-EVM. Move-to-SVM. Cairo-to-WASM. Any domain to any domain, asynchronously, permissionlessly, through the same settlement contract that anchors everything else. The relay mechanism is the same regardless of which VMs are involved, because the settlement layer doesn’t know or care what runtime produced the outbox entry. It only cares that the outbox root was committed in a finalized batch.
One distinction has to be exact here, because it’s the one a serious reader will press on. This is not synchronous composability. A contract in the WASM domain cannot call a contract in the EVM domain and read its return value inside the same execution, the way two contracts on a single chain can. The model is asynchronous and settlement-mediated: domain A emits a message, the batch finalizes, and the message is delivered into domain B’s input stream on a later step, where B acts on it and can send a result back the same way. It is message-passing between isolated services, not shared-memory function calls inside one runtime. That is a real constraint, and it is the honest shape of the thing. But it is also the same shape that distributed systems have used to scale for decades, and it buys something no synchronous design can offer: the domains stay genuinely isolated, so a failure in one cannot corrupt another, while still composing across the boundary through proofs the settlement layer already verifies. And it is not the cross-chain machinery it might be mistaken for. IBC needs each chain to run a light client of the other; Polkadot’s XCMP routes through a relay chain with its own consensus. This routes through nothing. The domains already share one settlement layer, one consensus, one finality model, so the message just moves through the layer they have in common.
The composability this opens up is still large, within that asynchronous model. A DeFi protocol could keep its matching engine in a WASM domain (optimized for deterministic execution) and its user-facing contracts in an EVM domain (maximizing Solidity tooling compatibility), passing messages between them rather than sharing a call stack. A gaming application could run its logic in a purpose-built VM optimized for state transitions while settling its assets through a general-purpose domain. A financial system could move value across Move and WASM domains without a liquidity bridge in between. None of these are synchronous calls, and none of them need to be; they are workflows that span runtimes, coordinated through a settlement layer that verifies every hop.
And the scope is narrow in the right way: this fixes the inside, not the outside. Bridges to chains beyond Zenon (Bitcoin, Ethereum, the rest) stay exactly as hard as they are everywhere else, and a later section treats that honestly. What changes is that everything within the settlement boundary composes natively, and that boundary is wide enough to hold every VM anyone ever registers. It is a categorically larger composability surface than any single-VM chain can offer, with no trusted bridge anywhere inside it.
The industry has built fragments of cross-VM communication. It has not built bridgeless cross-VM composability under a single settlement layer. Cosmos has IBC. Polkadot has shared security. Avalanche has subnets. EigenLayer has AVSs. Each solved a piece. None offers runtime-agnostic settlement under one conservation model with native cross-domain messaging and MEV resistance inherited by every VM at once. The pieces exist. The shape they would make together does not exist, until this.
Verifiable in a browser
There is one more property, and it compounds with everything above in a way that’s easy to miss.
The WASM execution layer is verifiable in a browser. L1 stores only SMT roots, never bulk execution state. Every artifact a verifier needs (state roots, receipts, event roots, batch commitments) is published in a fully specified, reproducible format, served by Sentinels over a content-addressed libp2p network. The commitment is compact enough for a light client. A user can check that the system cannot pay out more than was deposited, without running a full node, in a browser.
Be precise about the boundary, because the spec is. Browser-native settlement-layer verification (conservation, force inclusion, canonical ordering, domain isolation) holds for every registered domain, regardless of runtime, because those guarantees are provable from L1 state alone. Browser-native full-execution verification is a per-domain question: the WASM domain is designed for it from day one; whether a future EVM or Move domain achieves the same depends on what that domain handler specifies. The floor is verifiable everywhere. What sits above the floor depends on the domain.
Even the floor changes what a developer can build. No wallet extensions to march users through, no gas balances to top up, no fee estimation, no slippage tolerance. Resource allocation runs through plasma: fused QSR, not paid gas. Ordering comes from consensus, not a sequencer with its own incentives. Across the industry, the onboarding problem is structural; it descends from base-layer decisions that every major chain made at launch. This platform operates from a different set of base-layer decisions entirely.
Now stack the browser-native pieces on top of each other, because individually they’re features and together they’re something the industry has talked about for a decade and almost never delivered. A wallet that runs in the browser. Proof-of-work that runs in the browser. WASM execution that runs in the browser. Verification that runs in the browser. No gas to acquire before you can act. Put those in one stack and the result is a blockchain application that behaves like a website. Open a URL, use the application. No extension to install. No MetaMask to configure. No RPC endpoint to set. No gas to buy. No bridge to cross before you’ve started. No node to run.
The entire industry says the words “crypto UX.” Very few architectures actually move the whole stack toward open URL, use application, because in most stacks the friction isn’t a UI problem; it’s baked into the base layer and can’t be designed away. Here it was never baked in. The website-grade experience isn’t a product someone has to build on top; it’s the natural shape of a stack that was feeless, browser-verifiable, and extension-free from the root.
What if every service were a bootable image
Now the architecture does something nobody saw coming.
Consider what an executor actually is: a single-purpose program that reads inputs, computes a state transition, and commits a result. Nothing about that needs a general-purpose operating system around it. It could be packaged as a unikernel, a single-purpose, minimal OS image where one binary becomes a bootable microVM guest. No shell, no SSH, no package manager, no general-purpose surface at all. The attack surface collapses to the service itself, nothing more. Built reproducibly, two independent builders produce identical image hashes, and the image can be required to emit consensus bytes identical to a plain build, so hardening the deployment costs nothing in correctness. This isn’t part of what’s shipping with the settlement spec, and it doesn’t need to be. It’s a property of what an executor is, available the moment anyone wants it.
That much is just good operational security. But security is the small version of the idea. The deeper point is that the unikernel isn’t a packaging trick for one component; it’s the natural shape of every service on this network, and the executor is simply the clearest first example. Follow the thread and it turns architectural.
If an executor can be a unikernel, what else can?
Data availability is the first and most critical companion. Execution proves what happened. DA makes it independently knowable. Without DA, future fraud proofs weaken, browser verification loses its teeth, and “independently verifiable” becomes a claim about formats rather than about reality. A DA provider is a well-defined service: accept DA bundles, content-address them, serve them over libp2p. That’s a single-purpose process, which means it could take exactly the same form, and of all the services the network will eventually need, it’s the one that matters most.
And it doesn’t stop at DA. An oracle is a well-defined service: ingest external data, commit it on-chain in a specified format. Single-purpose process. It could be a unikernel. A payment-channel router, a bridge relay, an indexer, a light-client server: each one is bounded, deterministic, single-purpose. Each one could be a bootable image.
So picture a Sentinel operator. Today, running a Sentinel means running a node. In the architecture Project Zeno is pointing toward, it could mean running a fleet of purpose-built images, each providing a different infrastructure service to the network. An executor image for the WASM domain. A DA image serving execution bundles. An oracle image feeding price data. Each one minimal, hardened, reproducible, independently auditable.
And here is the part that changes the economics entirely. The operator’s allocation becomes liquid.
Say the network’s incentives make oracle provision more valuable this week than DA serving. The operator doesn’t rebuild anything. They spin down the DA image. They boot the oracle image. The hardware moves to where the rewards are. Next week the balance shifts again, and the fleet shifts with it. The network gets the infrastructure it pays for, because infrastructure has stopped being a fixed commitment locked in at setup and become a commodity that follows the incentives in real time.
That’s what turns “infrastructure marketplace” from a phrase into a mechanism. Without unikernels, “Sentinels provide services” is philosophy; with them, it’s an operating model. And plasma is the natural meter for it: the same locked-capital resource model that prices execution today could price the consumption of any service tomorrow, which makes it less a spam-prevention trick than the resource scheduler for an entire economy of services. That role isn’t built yet, but the primitive it would be built from already exists.
Take the most loaded example in crypto: Bitcoin.
It’s tempting to say Project Zeno makes Bitcoin bridgeless the way it makes its own domains bridgeless. It does not, and the reason matters, because it’s the same reason the internal case works. Internal domains share settlement truth, so they need no bridge. Bitcoin is outside that settlement boundary. It doesn’t share Zenon’s truth, and it can’t read Zenon’s state. So Bitcoin interoperability stays genuinely hard, and it stays asymmetric.
One direction is tractable. Bitcoin-to-Zenon is primarily a watching-and-proof problem: observe Bitcoin headers, verify confirmations, verify SPV-style inclusion proofs, check Taproot-relevant scripts, or commit other Bitcoin-side evidence into Zenon in a form Zenon can verify. That is exactly a bounded, deterministic, single-purpose service. It is a unikernel. A Bitcoin watcher image boots, follows the Bitcoin chain, verifies what it sees, commits evidence on-chain, and serves proofs to anyone over libp2p. Where Zenon can verify those proofs on-chain, trust collapses to the proof system rather than the operator running it.
The other direction is the hard one. Zenon-to-Bitcoin means releasing native BTC, and Bitcoin cannot natively read Zenon to authorize it. That still requires one of the known minimization mechanisms: a federation, threshold signing, a BitVM-style proving scheme, covenants if Bitcoin ever adopts them. None of that disappears. Project Zeno doesn’t pretend it does.
But here is the reframe that matters. Bitcoin interoperability was never really one bridge. It’s a class of services: header watchers, light clients, SPV verifiers, relayers, threshold signers, proof servers, liquidity routers, and eventually covenant or BitVM adapters. Every one of those is a bounded, single-purpose process. Every one of them could be a bootable image. And every one of them could be a service a Sentinel provides, bonds collateral against, and earns rewards for running correctly.
So the honest version isn’t “Bitcoin becomes bridgeless.” It’s something arguably more useful: Bitcoin interoperability becomes a native Sentinel service market. The operators who run Zenon’s infrastructure could also become the operators who connect it to Bitcoin, not by deploying one trusted bridge, but by booting the specific images the connection requires and being held accountable for each one. A Sentinel stops being only a Zenon infrastructure provider and becomes, optionally, a Bitcoin interoperability operator too. Same operating model, wider surface.
And there’s an irony worth sitting with. Bitcoin interoperability may not be the first service the platform enables, but it may be the one that proves the Sentinel economy matters beyond Zenon itself. An infrastructure market that only serves its own chain is a closed system. An infrastructure market whose operators can verifiably connect the most valuable asset in the space is something else: evidence that the model has reach. The day a Sentinel earns its keep watching Bitcoin is the day “infrastructure as a settled service” stops being a Zenon-internal idea and starts being a claim about the whole industry.
This is speculative, and worth labeling as such. None of it ships with the settlement spec. Nobody has built the oracle image, the DA image, or the incentive layer that would price them; the unikernel angle is a property the architecture exposes, not a component being delivered. But the architecture doesn’t prohibit it, it invites it. And if it ever materializes, the result is something no blockchain has achieved: a network where infrastructure provision is as fluid as capital allocation, because every service is a deterministic, reproducible, single-purpose binary an operator can boot or halt in response to real-time economic signals from consensus.
The size of the thing
The developer story and the unikernel story are the near edges of something much larger. Step back far enough to see the whole shape.
For fifteen years the industry has moved in two real steps and one long cleanup. Bitcoin gave us decentralized settlement. Ethereum gave us programmable settlement. Then we spent a decade fixing the consequences of how that programmability was built: gas markets, MEV, sequencers, bridges, DA layers, rollups, shared sequencers, intent layers, preconfirmations. Entire sectors, billions in funding, years of engineering, exist to manage constraints that smart contract chains inherited at birth.
Project Zeno starts from a different premise. Not how do we manage fees, but what if fees were never required. Not how do we reduce MEV, but what if the executor never had ordering authority. Not how do we make infrastructure composable, but what if infrastructure itself were the product.
Follow that far enough and the claim changes completely. If execution can be a service, and data availability can be a service, and oracles and payment routing can be services (all secured by one consensus, all packageable as reproducible bootable images), then Zenon isn’t building a better blockchain. It stops looking like a chain at all. It starts looking like something that competes with whole categories: DA networks, oracle networks, payment networks, execution networks, the constellation of separate protocols the industry spun up because no single chain could host them natively.
That is the real ambition: a network where consensus secures an economy of infrastructure services rather than a single execution environment. The industry has never built that. The names that come closest, the same ones every comparison reaches for, each took one piece of the problem as far as it would go and stopped there: a messaging standard, a shared-security layer, a data-availability network, a restaking market. None started from the premise that infrastructure itself (execution, data, oracles, settlement, routing) could be the native product of one network, with consensus securing the whole market rather than any one service inside it.
Which is the thing the whole essay has been circling: Project Zeno is not primarily a smart-contract platform. It is an attempt to make infrastructure a first-class settlement primitive.
Say it that way and the feature list stops being a feature list. Sentinels, plasma, feeless execution, multi-VM domains, data availability, oracles, payment channels, browser verification, libp2p, unikernels, cross-domain messaging: none of these were separate capabilities bolted together. They are components of a single thesis: consensus secures infrastructure markets, not applications. Execution is just the first market to come online. It is the proof of concept, not the product. The product is the substrate underneath it. Earlier this essay called the settlement layer a kernel that outlives the VMs running on it. Follow that all the way out and the kernel doesn’t just host execution environments; it hosts an entire market of infrastructure services, with consensus as the thing that keeps every provider in that market honest. Not an operating system for one machine. An operating system for an economy.
Zenon becoming itself
None of this works as a retrofit, and the reason is that none of it is one.
For years people argued about what Zenon was supposed to become. A faster chain? A Bitcoin interoperability layer? A payment network? A smart contract platform? Everyone had a candidate. None fit.
Look at what already existed. The dual ledger itself: account chains for parallel state, a momentum ledger for canonical order, separated on purpose. A feeless resource model through plasma. Sentinels standing as an infrastructure layer distinct from consensus. Embedded services alongside the base layer instead of on top of it. A philosophy, running through every one of those choices, that separates functions rather than collapsing everything into validators.
Those choices were strange when Zenon was created. Today they make sense as a set.
This is the answer to the question the founders left open. They never said what the chain was for, but they built every piece of it as if they already knew, and the shape only resolves now: the ledger was split so execution could be feeless, the roles were separated so services could have a home, the base layer was kept thin so the whole thing could be verified from outside. A design that looked like a pile of eccentric decisions turns out to have been a single decision wearing many faces. Whether the original architects saw this far is something they took with them. What’s left is the architecture, and the architecture reads like it was aimed here all along.
Most chains today are retrofitting solutions to problems their original architecture created, patching fees they baked in, fighting MEV their proposer model invited. Zenon is doing the opposite. It isn’t correcting its design; it’s extending logic that was already there. That’s why this feels less like a new feature and more like a missing piece clicking into a slot cut for it years ago.
And the logic it’s extending is, underneath, a Bitcoin logic. Not the part about wrapping BTC or bridging to it, but the trust model. Run your own node. Verify rather than trust. Keep the protocol minimal and the surface small. Self-host the things that matter. Open-source all of it. That ethos shows up everywhere in Zenon’s history: the push for the wallet to carry a full node the way Bitcoin Core does, the encouragement to run your own seeders and backends, the deterministic and reproducible builds, the resistance to anything that asks the user to trust an operator they can’t check. Project Zeno reads on the surface like a smart-contract paper. Read it against that history and it’s something else: an attempt to take Bitcoin’s trust model (verify everything, trust no one, run it yourself) and extend it past money into infrastructure itself. Not “what if Bitcoin could do more,” but “what if Bitcoin’s trust model became the basis for an entire market of services.”
Designed by subtraction
There’s a design principle underneath all of this that’s easy to miss because it works by absence, and it’s the thing that ties the whole architecture to the years of intent that preceded it.
The protocol was never meant to win by accumulating features. It was meant to become an exceptionally stable foundation that changes very slowly while everything above it changes fast. That inverts how most chains are built. The usual instinct is to pull capability into the base layer, because features in the protocol look like progress and a richer L1 looks more capable. Zenon went the other way on purpose. Keep the base layer small, robust, and slow-moving. Push complexity outward, into runtimes, execution environments, infrastructure services, applications, all the things that can evolve independently without ever touching consensus. The base layer is intentionally minimal so the ecosystem above it can become arbitrarily large.
This reframes the embedded contracts that already live on Zenon’s L1. They were never the destination. They are protocol primitives, the small set of operations that secure the system itself, and they stay small for the same reason a kernel stays small: everything load-bearing has to be auditable and almost never change. The embedded layer is kernel space. The runtimes and services that Project Zeno settles are user space. Native contracts secure the machine; everything expressive happens above them, in environments the community chooses and replaces at its own pace. That’s why the native contract system looks deliberately spare. It was supposed to.
It also reframes how the runtime question gets answered. The settlement layer is not just runtime-agnostic, able to host whatever VM appears. It is runtime-neutral by design: the protocol declines to crown a single VM, and leaves that to the people building on it. There may well be a de facto runtime someday, the one the ecosystem converges on because it’s where the tools and the liquidity and the developers are. But that’s a decision for the community to arrive at, not for the protocol to hardcode. Neutrality at the base, convergence at the edges, and the base never has to pick sides.
And it closes a historical loop. For years the way to talk about scaling Zenon was extension chains: separate chains, VM-compatible chains, chains for this workload or that one. Execution domains generalize that idea and dissolve it. An extension chain was always just a runtime that needed its own settlement and its own connection back to L1. A domain is that, with the settlement and the connection built in from the start, isolated by default, reachable through the same message layer as every other domain. What used to require launching a chain now requires registering a domain. The early mental model was pointing at this the whole time; it just didn’t have the abstraction to name it yet.
This is also why, to a casual observer, Zenon can look unfinished. The features people expect to find in a smart-contract chain aren’t in the base layer. That was never an oversight. They were never supposed to live there. They were supposed to live above it, built by whoever shows up, on a foundation small enough to trust and stable enough to build a decade on.
The ladder
Once you accept that execution is a service, the questions start to cascade, and every one of them points the same direction.
Who provides the service? The most Zenon answer: Sentinels. For years they’ve occupied a strange position: never validators, never consensus participants, always infrastructure providers sitting deliberately to the side. The spec doesn’t invent a new direction for them; it extends one already there. Consensus orders, services execute, infrastructure provides value. The Executor isn’t a new role. It’s the natural evolution of the Sentinel concept.
And unikernels are what make that evolution concrete. “Infrastructure provider” has always been vague. “Operator of reproducible service images” is not. For the first time, the Sentinel role has an actual operating model: boot executor image, boot DA image, boot oracle image, prove service, earn reward, lose collateral if failing. The architecture finally gives Sentinels a technically legible shape.
And notice how far that diverges from where the rest of the industry landed. Almost every chain eventually collapsed toward a single role, the validator that does everything, consensus and execution and increasingly data and ordering and MEV capture all at once. Zenon split the roles from the start. Pillars take consensus. Sentinels take services. That separation looked eccentric for years. In this architecture it becomes the whole point. Ethereum turned validators into infrastructure. Zenon may turn infrastructure into an economy. Those are not the same sentence, and the difference is the entire wager.
Phase 1 uses a single Executor per domain: simplicity wins, and the goal is to prove the architecture. The roadmap widens to permissioned Executors in Phase 2, permissionless in Phase 3. The spec defines the slot; it doesn’t fill it. Filling it is the community’s conversation.
That conversation fans out. Should Sentinels also provide DA? Oracle services? Payment routing? How should any of these be rewarded, and in what? The spec is silent on all of it, deliberately. No reward mechanism, no incentive schedule, nothing about how value flows to providers. That silence isn’t an omission; it’s a boundary.
And the deepest question sits one level down: what secures the marketplace? Execution requires accountability. So does DA, so do oracles. Infrastructure economies emerge from incentives, collateral, and consequences: providers rewarded for doing the work, penalized for failing it. For years QSR has existed as the asset associated with Sentinels, its purpose debated with the same uncertainty. The spec does not assign QSR a new role. But it creates the first architecture where QSR having a role becomes obvious. If infrastructure services need collateral, and Sentinels already map to QSR, then QSR naturally becomes the candidate collateral asset: the bond behind a promise to provide a service correctly. Not promised. But structurally obvious once the architecture exists.
The full shape, all the way down: a WASM layer leads to Executors. Executors lead to Sentinels. Sentinels lead to infrastructure services. Infrastructure services lead to an infrastructure economy. An infrastructure economy leads to QSR as the collateral that secures it.
At that point this isn’t an essay about a WASM runtime. It’s about the possibility that Zenon has just discovered what Sentinels and QSR were quietly building toward the entire time.
How it holds together
All of it rests on one sentence from the spec’s first page, the sentence 1,400 lines of normative text exist to enforce:
Consensus orders. Executors compute. Settlement anchors.
Three jobs, three components, none doing more than its job.
Feeless and MEV-resistant at the ordering layer, both for the reasons the opening laid out: plasma meters execution as a resource budget nobody collects, and the Executor has zero sequencing authority because the momentum ledger fixed the order before it looked. The mechanism enforcing the second one is precise: reorder, skip, or insert a transaction and the settlement contract rejects the entire batch on-chain, because the global input index must be contiguous. That same rejection rule is the force-inclusion mechanism; the settlement contract is the force-inclusion guarantee, not a feature layered on top of it. The only way to censor a transaction is to censor L1 itself. None of this eliminates every economic advantage that can exist inside applications, in cross-domain relay timing, or in external markets; it removes the executor-and-sequencer MEV that ordering discretion creates, which is the kind baked into every other design.
Runtime-agnostic because settlement is a domain registry, not a WASM contract, so every domain inherits the same guarantees from L1, and every domain is custody-isolated from every other. Bounded because the spec splits Core from Periphery: Core is immutable binary logic (batch rules, domain registry, conservation accounting, hard bounds on all parameters); Periphery is administrator-controlled configuration clamped by those bounds. The most important bound is the runtime-upgrade delay floor: any change to a domain’s state-transition function must give users at least as long to exit as the withdrawal delay. The architecture protects your ability to leave before the rules change.
Provable because execution is declarative: contracts return all effects as a blob, making each execution a pure function from witnessed reads plus input to an effects declaration. That’s the load-bearing decision for Phase 3: the ZK circuit proves “module plus inputs produces blob” while SMT application stays a separate, simpler stage. The SMT itself is shared between L2 and L1: same pure core, same hash functions, same proof codec, same conformance vectors. One spec, one conformance suite, both layers.
The honest part
What separates this from a hype document is that it tells you what it isn’t.
Phase 1 is bonded attestation, not trustless execution. The spec demands this be said without qualification: enforced on-chain, no trust required, the system can never pay out more than was deposited in aggregate (the pool cannot be over-withdrawn). What still relies on Executor honesty is whether your specific account is credited correctly; within the withdrawal delay and per-batch caps, a dishonest Executor could misattribute balances between accounts. The bond, the delay, and the caps are the rails. Real rails, but not yet math.
Phase 2 adds fraud proofs: catch a lie, prove it on-chain, slash the bond. Phase 3 adds validity proofs: an invalid result can’t be produced. No restructuring, no state migration; later phases snap onto Phase 1 without disturbing anything beneath. A project honest about Phase 1 is one you can believe about Phase 3.
The same honesty applies to every claim in this essay. No domain beyond WASM exists yet; EVM, Move, and every other runtime mentioned are what the architecture permits, not what’s shipping. Cross-domain messaging is specified, not yet implemented. Browser-native verification is real for WASM and a per-domain question above the settlement floor; the full “behaves like a website” stack is where the pieces point, not a finished product you can open today. The unikernel fleet is speculative, and not part of what’s shipping: it’s a property of the architecture, not a deliverable in the spec. Bitcoin interoperability as a Sentinel service market is a direction the architecture supports, not code that runs; and the hard direction, releasing native BTC, still depends on trust-minimization schemes nobody has made trustless. The infrastructure marketplace is a possibility, not a promise. The Sentinel economy and QSR-as-collateral are conversations the community hasn’t started.
None of it is guaranteed. That honesty is what licenses the ambition. Anyone can promise the cathedral. This is a project willing to show you the scaffolding.
There’s one more thing to know, and it closes the loop the chain’s strange origins opened. There is no company behind this. No venture capital. No foundation with a war chest. No figurehead, no roadmap theater, no one whose face you’re meant to trust. Zenon is fully open source and fully community-run, built by pseudonymous contributors who showed up because the architecture was interesting and stayed because the work turned out to be real. The spec exists because someone wrote it. These essays exist because the ideas wouldn’t sit still until they were written down clearly. If that sounds unusual, it is. It’s also how Bitcoin started, and how nearly everything that ever mattered in this space started: a handful of people, working in the open, on something they were convinced was worth it.
What it comes down to
You don’t have to believe Zenon becomes a decentralized infrastructure economy. You don’t have to believe QSR becomes the collateral that secures it, that Sentinels become the Executors, that a second VM domain ever registers, that unikernel fleets ever materialize, or even that the WASM layer launches clean. You only have to notice one thing, plainly true today: nobody else is attempting this combination.
Most of the industry works along one axis: chain, then rollup, then sequencer, then fee market, then a decade of managing the MEV the fee market created. Project Zeno works along a different one: consensus, then services, then execution and data and oracles and payments as native markets, then an infrastructure economy on top, with each service packageable as a hardened, reproducible, single-purpose image an operator can boot or halt in response to economic signals from the network itself. Those aren’t the same race at different speeds. They’re different races.
Bitcoin gave the world decentralized settlement. Ethereum gave it programmable settlement. The thing underneath Project Zeno is a third: a settlement layer that doesn’t pick a VM because it doesn’t have to, where execution environments run as peers under one consensus, message each other without bridges, share safety properties none of them had to engineer, and every service that supports them is a deterministic image a Sentinel can boot when the economics justify it.
Both readings are available right now, in the same document, depending only on what happens next.
If the attempt fails, this is an ambitious essay from a small network that aimed past its reach.
If it succeeds, it isn’t remembered as the moment Zenon got smart contracts. It’s remembered as the moment someone proved that infrastructure itself could be the product: that you never had to pick a VM, because the settlement layer beneath it didn’t care, and that everything the industry spent fifteen years building around the constraints of a single execution environment was, in the end, optional. The multi-VM story was never the destination. It was the first proof that infrastructure itself can be settled as a native network service, and once one infrastructure market exists, there is no principled reason the others can’t follow.
Everything else is implementation. And implementation is what we’re here for.
The spec is open. The code is open. The team is whoever shows up and builds. No permission required, no credentials checked, no institution to apply to, no one to ask. If the architecture pulls at you, the work is already waiting. This is how it has always been done here: pseudonymous people, open repositories, and a shared conviction that the thing being built is worth the effort.
The name is ours to choose once it’s live. So is who “ours” turns out to include.
Zenon’s Network of Momentum is fully open-source and community-run. More formal community documentation and ongoing community research can be found at: https://github.com/TminusZ/zenon-developer-commons
