# Zenon’s Guide to the Galaxy

**URL:** http://forum.zenon.org/t/zenon-s-guide-to-the-galaxy/2132
**Category:** Development
**Created:** [November 25, 2025, 3:43pm UTC](http://forum.zenon.org/t/zenon-s-guide-to-the-galaxy/2132 "2025-11-25T15:43:17Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![KayRSwon](http://forum.zenon.org/letter_avatar_proxy/v4/letter/k/6f9a4e/32.png) [@KayRSwon](http://forum.zenon.org/u/KayRSwon)
#### Post date: [November 25, 2025, 3:43pm UTC](http://forum.zenon.org/t/zenon-s-guide-to-the-galaxy/2132/1 "2025-11-25T15:43:17Z")

</div>

Nice, this is a fun one. Let’s treat this like wiring up a circuit:

Goal: map exactly how a user action in a Zapp turns into a finalized state change at pillars (consensus), with sentinels in the middle.

I’ll break it into:

1. The cast (who does what)

2. The full request path: Zapp → light node → sentinels → pillars → consensus

3. The response path: pillars → sentinels → light node → Zapp

4. How this extends to WASM / rollups later

**1. The cast: who are the actors?**

**🧑‍💻 Zapp**

- Runs in the browser (or mobile / desktop).

- Written in JS/TS (plus maybe Rust/WASM pieces).

- Talks to the Zenon network through the SDK (JS/Python/Rust).

- Does app logic: UI, business logic, encryption, local state.

**🌐 Light client (inside/alongside the Zapp)**

- Also in the browser (or lightweight native).

- Uses:

- 
- Responsibilities:

- 

**🛰 Sentinels**

- Lightweight network nodes.

- Roles:

- 

Think of them as: very smart routers + oracles.

**🗼 Pillars (full nodes / validators)**

- Full nodes with consensus power.

- Hold the full DAG/account-chain ledger.

- Maintain mempools, validate transactions, produce & sign momentums.

- Can act as TSS signers (e.g. BTC vaults).

- They are the ones that really “lock in” state transitions.

**2. Forward path: Zapp → light node → sentinels → pillars → consensus**

Let’s walk a single transaction all the way through.

**Step 0: User does something in the Zapp**

Example: in a browser-based DEX/messenger/payment Zapp, user clicks:

- “Send 10 ZNN to Alice”

- or “Place limit order”

- or “Send encrypted message”

The Zapp:

1. Collects input (amount, recipient, etc).

2. Runs local validation (is amount positive? fields filled?).

3. Calls the Zenon SDK to create a transaction intent.

**Step 1: Light client builds & signs the transaction**

The light client layer (SDK + crypto):

1. Fetches current account nonce / balance (from cached state or by asking the network).

2. Builds a raw transaction object:

3. 
4. Serializes it into the wire format expected by pillars.

5. Signs it with the user’s private key (stored locally, e.g. in browser keystore or hardware wallet).

Now we have a complete, signed transaction in the browser.

**Step 2: Broadcast via libp2p → sentinels & full nodes**

The light client:

1. Uses libp2p + WebRTC to connect to:

2. 
3. It publishes the signed transaction on a gossip topic (e.g. tx\_gossip).

At this point, the transaction leaves the user’s machine and enters the NoM (Network of Momentums).

**Step 3: Sentinels receive, check & relay**

When a sentinel sees this transaction:

1. Basic validation:

2. 
3. If it passes:

4. 
5. If the tx type requires oracle data (e.g. price feed, event data), sentinels may:

6. 

Sentinels do not finalize anything. They just make sure the tx reaches enough pillars and is enriched with any needed external data.

**Step 4: Pillars receive the tx and put it into consensus flow**

Each pillar:

1. Receives the transaction from:

2. 
3. Runs full validation:

4. 
5. If valid:

6. 

If multiple pillars have different mempool contents, the consensus algorithm and chain selection rules determine which set of txs get into momentums.

**Step 5: Consensus: from mempool → momentum → finality**

At consensus time (simplified):

1. Pillars propose or assemble candidate momentums (ordered sets of transactions + state transitions).

2. Gossip these candidates to each other (via P2P).

3. Validate each other’s proposals:

4. 
5. Once consensus is reached:

6. 

This is the point where your transaction has been accepted by consensus.

**3. Backward path: Pillars → sentinels → light node → Zapp**

Now we go in reverse, so the user’s app knows what happened.

**Step 6: Pillars broadcast the new momentum**

Once a pillar finalizes a momentum:

1. It broadcasts the new momentum header + relevant body info to:

2. 
3. This is done over the same libp2p P2P mesh:

4. 

**Step 7: Sentinels relay (and optionally index) the new state**

Sentinels:

1. Receive the new momentum and:

2. 
3. They then:

4. 

Sentinels = high-availability access layer for light clients.

**Step 8: Light client verifies and updates local state**

In the browser, the light node:

1. Receives:

2. 
3. Verifies:

4. 
5. If the user’s transaction was included:

6. 
7. Updates local minimal state:

8. 

**Step 9: Zapp updates UI and logic**

Finally, inside the Zapp:

1. SDK tells the app:

2. 
3. The Zapp:

4. 

From the user’s perspective:

Click in browser → short wait → finalized on-chain, cryptographically verified in the browser.

No Infura. No trusted RPC. No central backend.

**4. Where WASM / rollups / extension chains fit in**

Everything above works even before we talk smart contracts & rollups.

Now layer in Kaine’s “modular execution” ideas:

**A. WASM extension chain**

- Zapp tx might target a WASM execution zone instead of pure L1.

- Off-chain or sidechain node(s) execute contract logic in WASM.

- Pillars only see:

- 

But the flow is broadly the same:

Zapp → light client → sentinels → WASM-exec node(s) → pillars finalize state commitment → back via sentinels → light client → Zapp.

**B. ZK-rollups (future / R&D)**

For zero-sync or compressed-history modes:

- A Prover (or a prover network) runs many txs off-chain.

- Generates a zk-proof that “this whole batch was computed correctly.”

- Pillars include the proof + new state root in a momentum.

- Light clients just verify one proof instead of thousands of txs.

Sentinels still relay proofs + roots.

Zapps still interact through txs.

Pillars still finalize.

The main difference:

Light clients don’t even need the full transaction list; they just need:

- proof

- new root

- Merkle/accumulator proof for their accounts.

**5. Short mental summary you can give others**

Zapp runs in the browser and uses a light client to talk to the network.

The light client sends signed txs into the P2P mesh via libp2p/WebRTC.

Sentinels act as relays/oracles, pushing those txs to pillars.

Pillars run full validation and reach consensus, producing a new momentum.

That momentum flows back out via sentinels to light clients, which verify it and update local state.

The Zapp then updates its UI, all without any centralized services.

That’s the clean “zApps → sentinels → pillars → consensus → back” story.