Proposed Phase 1 Roadmap: Toward a Browser-Native Zenon
Context
What follows is an attempt to translate the scattered Phase 1 items into a rough roadmap with a clear end-state: a network that someone can use by opening a website. It covers two tracks: the browser-native work that gets ordinary users onto Zenon, and the WASM smart contract layer that brings programmability — sequenced so the second builds on the first rather than competing with it.
The Core Thesis
The discovery of the Sentinel design right under our noses, changes the math a little. With Sentinels acting as gateway infrastructure, plus libp2p and Dynamic Plasma largely complete and ready for testing, the network is closer to browser native applications than to trust minimized Bitcoin settlement.
Bitcoin interoperability remains valuable, but realistically it is years of effort that may depend on new opcodes and that only pays off once an ecosystem exists to benefit from it. SPV and PTLCs are infrastructure for a network that already has users. We do not have that yet.
Browser light clients are the inverse. They change the user experience from
install software, configure infrastructure, learn crypto tooling, then use an application
to
open a website and use the application
That is a different adoption curve, and it is achievable on a much shorter horizon than any bitcoin bridge primitive. Attacking the SPV first, given the current state of the network, is likely the wrong sequence. The most valuable move now is to focus almost exclusively on getting browser light clients running on top of Sentinels.
Where the WASM Smart Contract Layer Fits
The WASM layer is the programmability story, and the design direction is clear: execution does not belong on the consensus layer. Contracts run off-chain in a deterministic WASM runtime; the base chain stays a verification surface that anchors commitments. Account chains remain the settlement surface, momentums remain ordering and commitment, Pillars remain consensus, and execution sits outside the base consensus path.
This matters for sequencing because the WASM layer is not a single deliverable. It is a three-rung ladder where each rung trades trust for engineering:
| Rung | Trust model | What it needs |
|---|---|---|
| WASM Phase 1 — attestation | Bonded single executor + credible threat of future fraud proofs. Not trustless. | A new spork-gated Settlement contract, a wazero-based executor binary, an SMT state model. No consensus change beyond the spork. |
| WASM Phase 2 — fraud proofs | One honest challenger; anchored to a momentum state root. | A data-availability solution (hard prerequisite — see below), the momentum state root (a consensus change), a dispute/bisection game, and slashing. |
| WASM Phase 3 — validity proofs | Trustless on submission; no challenge window. | A ZK verifier that fits embedded-contract execution and the 16KB account-block data cap. Directional, not scheduled. |
The single most important scheduling insight is the shared dependency: the authenticated momentum state root that WASM Phase 2 requires for fraud proofs is the same primitive the browser-native roadmap needs for light-client proof generation, verification, and serving. It is independently motivated — light clients, state-sync, and fraud proofs all consume it — so building it once unlocks both tracks. That is the hinge this roadmap is organized around.
Proposed Sequencing
The browser-native track stays the spine and the near-term priority. The WASM track runs in parallel, but its heavy, trust-minimizing work is deliberately gated behind the state-root primitive that the browser track wants anyway.
Track A — Browser-Native (primary)
Phase 1A — Foundation
-
Governance
-
libp2p
-
Dynamic Plasma
-
Critical go-zenon fixes
Note: All this work is essentially done.
Goal: Restore the upgrade path and modernize networking. This is the work that proves to the community that the chain is still moving.
Phase 1B — Sentinel Gateway MVP
-
Public libp2p endpoint
-
Account data serving
-
Frontier and momentum serving
-
Unreceived block serving
-
Transaction relay
-
Short-lived message relay
-
Browser SDK support
Goal: Public gateway nodes capable of serving browser clients. No consensus redesign. Just make Sentinels useful first.
Open Question: How do we incentivize Sentinels during this phase? More on that below.
Phase 1C — Browser Access Layer
-
TypeScript SDK (@digitalSloth already finished it)
-
Browser Wallet (NoM Web Wallet — @digitalSloth has already built a browser-native wallet; a browser extension is in development now)
Goal: Connect to Zenon from a browser without running a node.
Phase 1D — Browser-Native Applications
-
Payments (in-browser payment channels via Sentinel relay)
-
Messaging
-
Identity
Goal: Demonstrate browser-native applications that ordinary users can actually access.
Track B — WASM Smart Contract Layer (parallel)
Smart contracts run off the consensus layer. Instead of every node re-running every contract (which bloats the base chain), contracts execute off-chain in a sandboxed WASM environment, and the chain only stores and verifies the results. The base chain stays lightweight; programmability gets added on top.
This arrives in three steps, each one trading more trust for more engineering. We start simple and harden over time.
WASM Phase 1 — Get it working
A bonded operator runs contracts off-chain and posts the results to a new on-chain settlement contract. We can build this on the network essentially as it stands — every piece it needs already exists as a proven pattern (the spork upgrade mechanism, bonded registration like Sentinels, on-chain anchoring). It’s a single operator backed by a bond, so the chain is trusting that operator to be honest and only checking that the commitment is well-formed — it does not re-run the contracts or verify the results are correct. This is bonded off-chain execution anchored to Zenon, not trustless smart contracts. We should describe it as attestation; the word “verified” only earns its place from Phase 2 onward. It’s a legitimate way to bootstrap — several rollups started exactly here — and it gets real smart contracts live with something to build on.
The single operator is a starting point, not the destination. The long-term direction is a competitive market of bonded executors, so we’ll design the settlement contract from day one so it doesn’t lock us into one operator forever.
Roughly 2–3 months of work, and no hard fork beyond the spork to switch it on.
The shared piece — an authenticated state root
To make the WASM layer trust-minimized, the chain needs a way to prove “this value is really in the state” to anyone holding just a block header. Today it can’t do that. Adding it is a consensus change of around 2–3 months.
The key point: this is the same piece browser light clients need. The browser track wants it so Sentinels can serve proofs to lightweight clients; the WASM track wants it so anyone can challenge a dishonest operator. Both roads lead to the same infrastructure, so we build it once and both tracks benefit. This is the hinge the whole roadmap turns on.
WASM Phase 2 — Make it trust-minimized
Once the state root exists, we add fraud proofs: if an operator posts a wrong result, anyone can challenge it on-chain and the operator loses their bond. This removes the “just trust the operator” assumption — you only need one honest watcher.
One hard prerequisite has to be solved first: data availability. A challenger can only prove an operator cheated if it can independently get the inputs and prior state the operator used. If the operator is the only party holding that data — and also the party being accused — there’s nothing to challenge with. So before Phase 2 is real, we have to decide how that data is published (on-chain with each batch, to a separate availability layer, or via bonded redundancy). This is not a detail to sort out during implementation; it determines whether fraud proofs are possible at all.
For that reason the timeline here is a rough order of magnitude — call it several months on top of Phase 1 once data availability and the open questions below are settled — rather than a firm estimate. The state-root work can run in parallel.
WASM Phase 3 — Make it trustless (later, directional)
Eventually, replace the challenge process with validity (ZK) proofs, so results are provably correct the moment they’re posted and the waiting period disappears. This depends on proving technology maturing, so it’s a direction rather than a scheduled item. Nothing built in Phases 1–2 is wasted when we get here.
Open questions before WASM is build-ready
This is a strong direction, not a finished spec, and it’s worth being upfront about what still has to be nailed down before Phase 1 can be called build-ready:
-
Who is the executor, how are they selected, and what’s the recovery procedure if the single operator goes offline.
-
Data availability for Phase 2 — which of the three approaches above we commit to. This should be chosen before Phase 1 ships so Phase 1’s design doesn’t quietly rule out the options.
-
Determinism rules for the WASM runtime (version, host calls, gas/metering) must be fixed and published, or a second party can’t reproduce a disputed batch.
-
Receipt and outbox formats — what a browser reads to see success/failure, and how a withdrawal is guaranteed to process exactly once.
-
The Phase 1 → Phase 2 path — whether adding the dispute game is a spork or a hard fork, and whether the spork can be rolled back if something breaks post-launch.
Naming these now is what keeps the early choices from becoming later constraints.
Later
-
Sentinel reward conditionality based on measured usefulness
-
Bitcoin interoperability (SPV, PTLCs, trust-minimized settlement)
-
Permissionless / multi-operator executor set with leader rotation
-
L2-native tokens, executor state migration across code upgrades
Note: proof generation, verification, and serving are not listed here. They are delivered by the shared momentum state-root primitive above, because both tracks depend on it.
Architecture
Browser
↓
Sentinel Gateway ──────────────► getProof / state-root reads
↓ ▲
go-zenon node │ (authenticated momentum state root)
↓ │
Zenon network (L1: account chains + momentums)
▲
│ SubmitBatch / Deposit / RelayMessage
│
Settlement Contract (embedded, spork-gated)
▲
│ commitments (input / state / receipt / outbox roots)
│
WASM Executor (off-chain, bonded) — wazero runtime, SMT L2 state
The early Sentinel is functionally an RPC node. It’s somewhat analogous to what MetaMask gets from Infura. The difference with Zenon is that feeless account-chain settlement combined with Dynamic Plasma and a Sentinel gateway layer can make browser payments feel native rather than bolted on. The feature is not “browser payments exist.” Other chains can build that. The feature is “browser payments without crypto friction.” Sentinels will not act like RPCs forever. Once usage is real, the requirements for proof generation, verification, and serving become observable rather than theoretical — and that is exactly the same state-root primitive the WASM layer needs to become trust-minimized. The two roadmaps converge on one piece of infrastructure.
On Sentinel Incentives
Operating the Orchestrators taught me one thing clearly: if there is no incentive, uptime is not a priority. Roughly two-thirds of the ~15 live Orchestrators are run by a handful of people. That is not a model that scales.
The simplest viable rule for launch:
Reachable = reward. Not reachable = no reward.
No slashing, no complex service-quality metrics, no consensus implications. Some operators will run Sentinels on goodwill, but goodwill alone will not produce a reliable gateway layer. Build the service first, learn from real usage, then harden it with proofs and tighter incentive conditions later. Designing economics around a theoretical service that does not yet exist is the wrong order.
The same discipline applies to the WASM executor bond: WASM Phase 1 uses the bond as a soft economic deterrent only (no slashing). Slashing arrives in WASM Phase 2 alongside the dispute game that gives it meaning. Designing slashing economics before fraud proofs exist would be the same mistake in a different layer.
On Bitcoin Interoperability
I believe Bitcoin interop should come off the near-term roadmap. Let’s be real, it’s a multi-year effort that only matters once the network has users. A growing ecosystem can justify the cost of building SPV and PTLC infrastructure. An ecosystem without users cannot.
On the State of the Community
The community is thin. Losing Vilkris was a significant blow. He could have plausibly taken on many of the Phase 1A items. We are down to a hand full of active community members plus rotating alts, and there is no realistic path to growth without visible, shippable progress.
libp2p, Dynamic Plasma, governance, and the critical go-zenon fixes are achievable in the coming months. Delivering them would do two things at once: stabilize the existing community by demonstrating that the chain is still moving, and lay the groundwork for the Sentinel and browser client work that can actually attract new users.
The WASM track is sequenced to respect this constraint. WASM Phase 1 is roughly a 2–3 month solo effort and depends on nothing beyond a spork, so it can start as soon as the browser MVP is stable without pulling people off the primary track. The expensive, trust-minimizing work (state root, fraud proofs) is explicitly gated and shares its cost with the browser roadmap, so we are not funding two separate multi-month consensus projects.
Suggested Immediate Next Steps
-
Small testnet covering governance, Dynamic Plasma, and libp2p, plus the go-zenon bug fixes
-
Extensive testing, then production
-
Define the Sentinel service role concretely (Gateway v0 scope above)
-
Integrate the NoM Web Wallet against the Sentinel gateway once that surface is stable, and support the browser extension already in development.
-
Browser light client MVP demonstrating in-browser payments via Sentinel relay
-
Settle the WASM open questions above — especially executor selection and the data-availability approach — before finalizing the Phase 1 design, since those choices shape the settlement-contract interface. Then scope a WASM attestation MVP on devnet (no slashing, single bonded executor)
-
Scope the Merkleized momentum state root as a standalone consensus project — it is the shared dependency for both browser light clients and WASM fraud proofs, and should be scheduled on its own merits
Closing
The roadmap is easier to understand now that Sentinels are closer than we thought. The dependencies are visible, the end state is identifiable, and the sequence has a clear rationale.
The WASM layer runs along the same grain. Programmability lands as an off-chain execution layer that keeps the base chain lightweight, and its path to trust-minimization runs straight through the same state-root primitive that browser light clients need. Build the browser-native experience first, ship a bonded attestation MVP for programmability, then invest once in the state root that makes both trustless.
Bitcoin interop is great, but not when you have 10 users who care. Let’s bring Zenon to a browser native experience that users can interact with easily. Prove we can deliver that and then iterate from there.