# Wer Sentinel?
**URL:** https://forum.hypercore.one/t/wer-sentinel/925
**Category:** Development
**Created:** [May 30, 2026, 10:34am UTC](https://forum.hypercore.one/t/wer-sentinel/925 "2026-05-30T10:34:35Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@0x3639](https://forum.hypercore.one/u/0x3639)
#### Post date: [May 30, 2026, 10:34am UTC](https://forum.hypercore.one/t/wer-sentinel/925/1 "2026-05-30T10:34:35Z")
## Prompt
You are investigating a specific, falsifiable claim about the Zenon ecosystem. Your job is
**forensic verification against source code** , not advocacy. The community wants to know
whether a long-standing narrative is actually true before investing effort, so a confident
“yes” that turns out to be wrong is worse than an honest “partly.”
### The claim under investigation
> **“The Sentinel node is already embedded in the Syrius wallet. The community only needs to finish the unfinished development in order to deploy Sentinels as live service nodes.”**
Sign #1
Sign #2
[ ](https://www.youtube.com/watch?v=ZdD9mgk4iqs)
Sign #3
> [@What is the difference between a Public Node and Public RPC Node in Zenon Network?](https://forum.hypercore.one/t/what-is-the-difference-between-a-public-node-and-public-rpc-node-in-zenon-network/924):
>
> " Public [protocol] nodes ARE the network in the most literal sense. They are the set of computers constantly in communication with each other to validate and broadcast chain data. For NoM, that would be momentums and account blocks (transactions). A public node must be running software which implements Zenon Network’s protocol, (currently only go-zenon’s znnd). It must be reachable (have a stable public IP address) and accept incoming connections on its protocol port (e.g 35995)." Source: [htt…](https://ask.zenon.wiki/questions/D1s3/what-is-the-difference-between-a-public-node-and-public-rpc-node-in-zenon-network)
---
### Author:  [@0x3639](https://forum.hypercore.one/u/0x3639)
#### Post date: [May 30, 2026, 11:14am UTC](https://forum.hypercore.one/t/wer-sentinel/925/2 "2026-05-30T11:14:15Z")
# The Sentinel framework is already inside Syrius — let’s finish it
**TL;DR:** Syrius doesn’t just _connect_ to a node — it already **runs a full go-zenon node
inside the wallet** and serves RPC from it. Add the live Sentinel staking UI, the node
manager, and an implemented-but-empty community-node discovery slot, and the foundation to
run a Sentinel **service node from inside Syrius** is already sitting in the codebase. The
Sentinel service layer was never finished, but finishing it is a buildable extension — and
the MVP needs **no consensus change**. Here’s the evidence, and here’s the work.
* * *
## Why Sentinels feel “vestigial” today
Right now a Sentinel is a staking position. You lock ZNN + QSR, register on-chain, collect
rewards, and… that’s it. The node does no measurable network service. That’s the gap
everyone senses.
But Zenon’s own docs (greenpaper) describe Sentinels as nodes that **improve relay
availability for light clients** — i.e., a public RPC / data-service edge that wallets and
light clients connect to. The interesting part: **almost all of the machinery to do that
already exists in Syrius.** It was just never wired together and switched on.
I went through the Syrius source (Flutter/Dart, SDK pinned at `znn_sdk_dart v0.0.7`) to
verify this claim against the actual code rather than vibes. Below, every assertion has a
`file:line` receipt.
* * *
## What’s already in Syrius (the receipts)
**1. Syrius runs a full node _in-process_.** This is the big one. Syrius bundles go-zenon
compiled as `libznn` and runs it via FFI inside an Isolate:
- `lib/embedded_node/embedded_node.dart:50-84` — loads `libznn.so/.dylib/.dll`, binds the
`RunNode`/`StopNode` entry points.
- `lib/utils/node_utils.dart:243` — `Isolate.spawn(EmbeddedNode.runNode, [''])` actually
starts it.
**2. That embedded node already serves WebSocket RPC.** Immediately after starting it,
Syrius connects to it:
- `lib/utils/node_utils.dart:235` connects to `kLocalhostDefaultNodeUrl`
- `lib/utils/constants.dart:123-124` → `ws://127.0.0.1:35998`
A Sentinel service node _is_ a public-serving full node. The engine to be one is **already
executing inside Syrius** — it’s just bound to localhost.
**3. The full Sentinel staking lifecycle is wired.** Register → deposit QSR → lock ZNN →
collect → revoke:
- `lib/widgets/modular_widgets/sentinel_widgets/*`
- SDK `api/embedded/sentinel.dart:17-67` (`getAllActive`, `getByOwner`, `register`,
`revoke`, `depositQsr`, `withdrawQsr`, `collectReward`, …)
**4. Node management already supports multiple node tiers + switching + validation.**
- `lib/screens/node_management_screen.dart` — embedded, localhost, user-added (`kDbNodes`),
and community nodes; URL validation; chain-ID mismatch warnings.
**5. There’s a discovery slot that’s fully implemented but empty.**
- `assets/community-nodes.json` = `[]`
- `lib/main.dart:180-192` loads it, validates each entry, builds the list
- `node_management_screen.dart:43` shuffles the pool (classic load-distribution over a
service tier)
The loader, validator, and shuffler are real. The slot is there. It just has nothing in it.
**6. The RPC consumer side is node-agnostic.** Every call Syrius makes goes through a single
`zenon!.wsClient` (`node_utils.dart:79-110`). Pointing it at a Sentinel-served endpoint is a
URL swap — **zero code change** on the consumer side.
That’s the framework. None of it is wishful thinking; it’s in the tree today.
* * *
## Being honest: what is _not_ there yet
I want this to be a credible pitch, not hype, so here are the two things the “just fill in
the JSON” framing glosses over:
**A. Syrius can’t currently configure its embedded node.** The FFI surface is `RunNode()`
and `StopNode()` with **zero arguments** (`embedded_node.dart:15-21`), and Syrius writes no
node config (the only `.znn` path use is for logs, `main.dart:56`). So the embedded node
runs with whatever config is baked into `libznn`, bound to localhost. Making it serve
**publicly** (bind `0.0.0.0`, enable `wss`/TLS, choose a port) is real work that lives in
**`libznn`/go-zenon** , not just Syrius UI.
**B. A desktop wallet is an awkward host for a 24/7 node.** Syrius is an interactive GUI app
(it holds a wake-lock only while running, `node_utils.dart:238`). A Sentinel is meant to be
always-on infrastructure. Nothing blocks running it from Syrius, but we’d need a
“serve / stay-alive / headless” mode that doesn’t exist yet.
Neither of these requires a protocol change. They’re just real engineering the spec doesn’t
currently cover.
One more honest note: a frequently-cited “clue” — a `SentinelsListBloc?` parameter
ghost-typed into the Peers widget — turns out to be **dead code** (`peers.dart:51`, unused,
and copy-pasted into two unrelated tables). It’s not evidence of half-finished Sentinel
wiring. The _real_ evidence is everything in the list above.
* * *
## The one true blocker for the _trustless_ version
If we want Syrius to discover Sentinels **trustlessly from the chain** , there’s a hard wall:
the on-chain Sentinel record has no network address. `SentinelInfo` contains only `owner`,
`registrationTimestamp`, `isRevocable`, `revokeCooldown`, `active` (SDK
`model/embedded/sentinel.dart`), and `register()` takes no endpoint
(`api/embedded/sentinel.dart:51`). The chain literally doesn’t store _where_ a Sentinel can
be reached.
**The good news:** this only matters for the fully trustless endgame. The MVP doesn’t need
it — we can ship a working service layer off-chain first (signed endpoint records +
health-checked node list) and add on-chain endpoints later via a spork.
* * *
## What needs to be done (proposed phases)
**Phase A — Make Syrius serve as a Sentinel (the new, load-bearing work).** _No consensus
change._
- Extend `libznn` (FFI args or a Syrius-written go-zenon `config.json`) so the embedded node
can bind publicly and enable `wss`/TLS.
- Add a “Run as Sentinel / serve publicly” mode in Syrius that keeps the node alive and
shows sync + reachability status.
**Phase B — Discovery + quality (per the Sentinel spec, off-chain).** _No consensus change._
- Signed off-chain service records: the Sentinel owner signs `{owner, endpoint, capabilities}`, tying an endpoint to an owner address without touching the protocol.
- Populate the discovery slot from those records (reuse the existing
loader/validator/shuffle).
- Health probing + scoring before offering a node (reuse `establishConnectionToNode` +
`getNodeChainIdentifier` + frontier-freshness + peer count), plus RPC failover.
**Phase C — Trustless (later, needs a spork).**
- Add an endpoint field to on-chain Sentinel registration + `SentinelInfo`.
- Move reward scoring from “registered long enough” to actual service quality
(reachability × sync freshness × correctness × uptime).
* * *
## Why this is worth doing
This turns Sentinels from a passive staking position into **useful public infrastructure**
that light clients, browser wallets, and dApps can lean on — and it does the first, useful
version with **no consensus changes and no protocol risk**. The hardest pieces (a full node
engine, RPC, the staking UI, a discovery scaffold) are already built and shipping in Syrius.
We’re not starting from zero. We’re finishing something that’s been sitting 80% done in the
codebase.
**What I’m looking for:** anyone who knows the `libznn`/go-zenon embedded-node config path
(does it already expose a public-capable RPC server, or is that new code?), plus Syrius
contributors who can scope Phase A. If we can confirm the go-zenon side, Phase A + B is a
realistic community build.
Receipts are all above — please verify them yourself against the Syrius source and poke
holes. That’s the point.
---
### Author:  [@Stark](https://forum.hypercore.one/u/Stark)
#### Post date: [May 30, 2026, 12:12pm UTC](https://forum.hypercore.one/t/wer-sentinel/925/3 "2026-05-30T12:12:27Z")
> [@0x3639](#):
>
> ### The claim under investigation
>
> > **“The Sentinel node is already embedded in the Syrius wallet. The community only needs to finish the unfinished development in order to deploy Sentinels as live service nodes.”**
The prompt specifies Syrius but why not build the sentinel into znnd and operate as a “producer” machine?
1. Doesn’t a normal znnd node already serve public RPC on its own?
2. Hosting it in Syrius means the machine has your staked keys on it. A “producer” node would avoid that, like pillars do.
Maybe run the prompt again and change Syrius to znnd?
---
### Author:  [@0x3639](https://forum.hypercore.one/u/0x3639)
#### Post date: [May 30, 2026, 12:19pm UTC](https://forum.hypercore.one/t/wer-sentinel/925/4 "2026-05-30T12:19:24Z")
ya, that is a bit of a concern having the sentinel, a public node, also hold a wallet with funds.
---
### Author:  [@Stark](https://forum.hypercore.one/u/Stark)
#### Post date: [May 30, 2026, 1:57pm UTC](https://forum.hypercore.one/t/wer-sentinel/925/5 "2026-05-30T13:57:44Z")
There’s also the GUI aspect of Syrius.
---
### Author:  [@0x3639](https://forum.hypercore.one/u/0x3639)
#### Post date: [May 30, 2026, 2:05pm UTC](https://forum.hypercore.one/t/wer-sentinel/925/6 "2026-05-30T14:05:50Z")
yes - might need to make it headless or have a headless version.
---
### Author:  [@digitalSloth](https://forum.hypercore.one/u/digitalSloth)
#### Post date: [June 2, 2026, 11:20am UTC](https://forum.hypercore.one/t/wer-sentinel/925/7 "2026-06-02T11:20:00Z")
I think Stark is right that this should be a separate machine running znnd much like a Pillar. If this is all in Syrius woudlnt the network looses stability if someone turns off their PC, theres no way to track uptime for rewards/slashing, and wouldnt it expose people’s home IPs if they get written to the community nodes file?
---
### Author:  [@0x3639](https://forum.hypercore.one/u/0x3639)
#### Post date: [June 3, 2026, 10:04am UTC](https://forum.hypercore.one/t/wer-sentinel/925/8 "2026-06-03T10:04:29Z")
I do think this is a fair criticism.
- Running a sentinel on a desktop PC on a home IP is not ideal. However, many bitcoin nodes do exactly this. Maybe there is a TOR layer, like Umbrel uses, to hide the IP. In fact, [Kaine recommended this](https://kaine.zenon.info/?session=d96b373c-40d0-4cf3-af1b-bf5c7d660638). This is another direct hint from Kaine that Syrius is to be used for the incentivized, p2p layer. And integrating Tor is a logical next step.
- Running a publicly accessible sentinel on infra that also has a wallet is not idea, but maybe rewards can be directed to a different wallet or swept. Again I’m proposing the easiest path to deploy an MVP sentinel. We can iterate and improve later.
What is the easiest way to create an MVP of an incentivized P2P layer? Extend Syrius to launch a functional Sentinel. We have the gui, the deploy sentinel feature, znnd, rpc, it’s all there. We can add Tor, health, and a node selection algo. Once we have a functioning network with real usage we can iterate on these basic concepts to eventually have a production grade sentinel that also does proof verification.
Maybe it’s important to also say, we should not prevent people from running the sentinel in a server. That would be my personal preference. Maybe there is a “hard mode” where a user can deploy a sentinel with the `controller`. I think the controller already has this option. We can extend it. I wonder how we can associate the server hosted sentinel to the sentinel deployed in Syrius. Might need the `producer` concept.