How NeuroPoS works
NeuroPoS turns finalized Proof-of-Stake data into deterministic proof bundles: quorum-collected inputs, canonical derivations, Merkle roots & checkpoints, signed trust metadata, and optional on-chain anchoring — so anyone can verify integrity without trusting a single source.
At a glance
The pipeline is engineered to be reproducible: same finalized inputs → same outputs on any machine. No "opinions", just deterministic commitments and proofs.
Quorum RPC (2/3) over finalized inputs (Finality-K).
Canonical metrics: absence, events, reputation snapshot.
Merkle roots + checkpoint hash (canonical serialization).
Content-addressed blobs: /blobs/<sha256>.
Publisher signatures + KID-only trust store manifests.
Optional on-chain anchoring (Base): envelope_hash + trust_store_hash.
1) Collect — quorum RPC + finality
NeuroPoS starts from a simple engineering premise: a single RPC endpoint is not a reliable source of truth at scale. We collect epoch inputs from multiple independent RPC providers and require a strict quorum (2/3) over finalized artifacts.
- Multiple RPC sources reduce single-provider drift and transient inconsistency.
- Strict quorum means we only accept inputs that agree across independent sources.
- Finality‑K ensures we avoid "hot" blocks that may reorg; we work on finalized / stable ranges.
- Outputs are range-scoped: every claim is tied to a specific epoch/range, never "global verdicts".
Advanced: what exactly is compared?
In MVP, the quorum is applied over protocol-visible commit/signature inputs for the epoch boundary and the finalized duty-relevant artifacts. The exact fields are network-dependent, but the key rule stays the same: inputs must be derived from finalized state, not node-local measurements.
{
"epoch": 12637,
"finality_k": 64,
"rpc_sources": [
{"name": "rpc_A", "url": "https://…"},
{"name": "rpc_B", "url": "https://…"},
{"name": "rpc_C", "url": "https://…"}
],
"quorum_policy": "STRICT_2_OF_3",
"input_scope": "finalized_only",
"note": "Conceptual UI example — see /verify for real verification."
}
2) Derive — canonical metrics (deterministic)
Once quorum inputs are fixed, NeuroPoS computes derived records deterministically: absence, events, and a reputation snapshot. The guiding rule: identical finalized inputs must produce identical outputs everywhere.
- Absence records: deterministic duty completion for the range (missed/total + commitments).
- Event records: range-scoped signals such as downtime windows, streaks, mismatch indicators.
- Reputation snapshot: fixed-point representation, bounded updates, and epoch-freeze semantics.
- Explicitly excludes node-local metrics (RTT probes, wall-clock timings, mempool arrival).
Advanced: determinism profile
Determinism requires a protocol-defined numeric profile (fixed-point), canonical rounding and clamping rules, and canonical serialization of structured data prior to hashing. This avoids "same idea, different bits" across implementations.
{
"schema": "np.epoch.derived.v1",
"epoch": 12637,
"records": {
"absence": {"missed_slots": 12, "total_slots": 100, "commitment": "sha256:…"},
"events": [
{"kind": "downtime_window", "validator": "0x…", "range": "slots 201-248"},
{"kind": "mismatch", "source": "rpc_B", "field": "commit_set"}
],
"reputation": {
"encoding": "fixed_point_fp_1e6",
"epoch_freeze": true,
"note": "Fast-down / slow-up (bounded recovery), range-scoped"
}
}
}
3) Commit — Merkle roots & checkpoint hash
Derived records become commitments: NeuroPoS computes Merkle roots (absence/events/reputation) and a checkpoint hash over canonically serialized metadata. These are the core integrity anchors that verifiers recompute.
- Merkle roots commit to large datasets while keeping verification efficient (proof paths).
- Checkpoint hash commits the bundle metadata in a canonical form (stable bytes).
- Any mutation in any record changes the root/checkpoint, making tampering evident.
- Roots are range-scoped — the meaning is always "for epoch E / range R".
Advanced: why canonical serialization matters
Without canonical serialization, different JSON emitters or field orders can yield different bytes for the "same" object, causing divergent hashes. Canonical rules (e.g., JCS-like) ensure every verifier hashes identical bytes.
{
"schema": "np.checkpoint.v2",
"epoch": 12637,
"network": "base",
"roots_v2": {
"absence_root": "0x…",
"events_root": "0x…",
"reputation_root": "0x…"
},
"bundle_sha256": "sha256:…",
"created_at": "2026-01-26T01:15:00Z",
"canonical_serialization": "JCS",
"checkpoint_hash": "sha256(JCS(checkpoint))"
}
4) Publish — content-addressed storage
Proof bundles and blobs are stored by hash (SHA‑256). This makes distribution robust: mirrors can host the same content, and any byte-level change becomes obvious.
- Bundles/blobs live at paths like /blobs/<sha256> (or equivalent storage keys).
- Any mirror can serve the same object without changing trust assumptions.
- If the API is down, you can still verify using storage + on-chain anchoring hashes.
# content-addressed objects (conceptual) GET /blobs/sha256/9d3d2c4aef18a1...a8b7 # bundle manifest GET /bundles/epoch/12637/manifest.json # checkpoint (canonical) GET /bundles/epoch/12637/checkpoint.jcs # roots + signatures (publisher) GET /bundles/epoch/12637/signatures.json
5) Sign — publisher signatures (hybrid)
Each bundle is signed by the publisher. Signatures make it tamper-evident to change metadata (e.g., roots/checkpoint), and enable clear accountability for what was published.
- MVP uses a hybrid signature policy: Ed25519 + a post-quantum component (e.g., ML‑DSA‑65).
- Verification checks signatures against the trust store (KID-only keys).
- Signatures cover canonically serialized checkpoint data to avoid ambiguity.
Advanced: why hybrid signatures?
Hybrid schemes reduce long-term cryptographic risk by combining widely deployed algorithms with a post-quantum component. The exact policy is defined by a signed trust store manifest (so verifiers know what is required).
{
"policy": "HYBRID_AND_REQUIRED",
"signed_object": "checkpoint_jcs",
"signatures": [
{"kid": "np_ed25519_2026q1", "alg": "Ed25519", "sig": "base64:…"},
{"kid": "np_mldsa65_2026q1", "alg": "ML-DSA-65", "sig": "base64:…"}
]
}
6) Trust store — KID-only, versioned
Trust is defined explicitly: a signed trust store describes which public keys (by KID) are authorized to sign bundles, and what policies verifiers must enforce. This supports key rotation without breaking verifiers.
- Trust store is a single source of "who can sign" — referenced by hash for integrity.
- KIDs allow safe rotation: new keys can be introduced without changing verification code.
- Anchoring can include the trust_store_hash so verifiers know which trust policy applied.
{
"schema": "np.trust_store.v1",
"version": "2026q1",
"keys": [
{"kid": "np_ed25519_2026q1", "alg": "Ed25519", "public_key": "base64:…"},
{"kid": "np_mldsa65_2026q1", "alg": "ML-DSA-65", "public_key": "base64:…"}
],
"policy": {
"signatures_required": ["Ed25519", "ML-DSA-65"],
"mode": "HYBRID_AND_REQUIRED"
}
}
7) Anchor — optional on-chain timestamping (Base)
Anchoring adds an independent, publicly verifiable timestamp and immutability guarantee: the system writes an envelope hash (and trust store hash) on-chain. Verifiers can check anchoring status without relying on NeuroPoS servers.
- Anchor includes envelope_hash and trust_store_hash (so policy is pinned).
- Worker waits for confirmations and handles reorg scenarios deterministically.
- Anchoring is optional: proof bundles remain verifiable without it; anchoring adds stronger timestamping.
Advanced: what is envelope_hash?
Envelope hash is a commitment to the published artifacts (manifest + checkpoint + roots + bundle SHA). The exact envelope format is versioned; verifiers recompute it from the downloaded data and compare with the on-chain value.
// emitted by the anchoring contract (conceptual) event Anchored( uint256 epoch_id, bytes32 envelope_hash, bytes32 trust_store_hash ); // lookup isAnchored(envelope_hash) -> bool getHashes(epoch_id) -> (envelope_hash, trust_store_hash)
How verification works (what anyone can do)
Verification does not require trust in NeuroPoS. A verifier downloads the bundle by hash, recomputes commitments, checks signatures against the trust store, and (optionally) checks on-chain anchoring.
- Fetch artifacts by SHA‑256 (bundle & blobs).
- Recompute Merkle roots + checkpoint_hash locally.
- Verify publisher signatures using the trust store (KID-only).
- If anchoring is present: compare on-chain envelope_hash & trust_store_hash.
1) download(bundle_sha256) + referenced blobs 2) recompute roots_v2 from canonical leaves 3) compute checkpoint_hash = sha256(JCS(checkpoint)) 4) verify signatures over checkpoint_jcs using trust_store.json 5) if anchored: - fetch on-chain (envelope_hash, trust_store_hash) - recompute envelope_hash from artifacts - compare values + confirmations 6) output: Verified | Mismatch | Requires review
Security model (what is guaranteed)
NeuroPoS is a "trust-grade integrity pipeline": it makes tampering evident and enables independent verification. It does not ask users to trust a single API, a single node, or a single operator.
- Content-addressed hashes detect any byte change in stored artifacts.
- Merkle roots detect tampering inside datasets (absence/events/reputation).
- Publisher signatures detect metadata changes and provide accountability.
- Anchoring (optional) adds public timestamping and immutability via on-chain commitment.
- API is transport: convenient, not authoritative. Proofs are authoritative.
Prevents / Detects: - API lying (proofs don’t match) - storage tampering (hash mismatch) - dataset mutation (Merkle mismatch) - ambiguous serialization (canonical bytes) - single RPC drift (quorum inputs) Does not claim: - "intent" attribution - public shaming or rankings - punishing via unverifiable signals
Evidence without harassment
NeuroPoS deliberately avoids "leaderboards of bad validators". The default language is neutral, results are range-scoped, and every signal is backed by verifiable evidence.
- Neutral language by default ("mismatch", "requires review", "verified").
- Context over blame: signals are tied to specific epochs/ranges.
- No public leaderboard of "bad validators".
- Operators can respond with proofs / remediation; evidence is portable.
FAQ
Short answers to the questions investors and engineers ask most often.
Does this page make any API calls?
No. /how-it-works is a static walkthrough. Live verification happens on /verify or in your own verifier.
What exactly is "trust-grade" here?
Trust is anchored in reproducible artifacts: quorum-collected finalized inputs, canonical derivations, Merkle roots, signed metadata, and optional on-chain anchoring — not in a single API response.
Is anchoring required?
No. Proof bundles are verifiable without anchoring. Anchoring adds a public timestamp and stronger immutability guarantees.
Do you publish rankings or "bad validator" lists?
No. NeuroPoS avoids public shaming. We focus on range-scoped, evidence-backed verification signals.
Do you expose the full scoring formula client-side?
No. Client-side UI does not contain proprietary scoring logic. The verification contract relies on cryptographic commitments and reproducible derivations.
Can enterprises run this privately?
Yes. The pipeline can support private deployments, custom SLAs, and controlled trust stores for compliance-grade environments.