Why run a light node?
Every time your wallet or application queries a public RPC endpoint, it hands that provider a blank check. They can return the correct answer. They can also return a wrong one. You have no way to tell the difference. A light node changes that equation — not by eliminating trust entirely, but by moving it from "trust this company's server" to "trust a checkpoint and 2/3 of the validator set." That is a different, and more defensible, position.
This post explains what a Krypton light node actually is, what it verifies, what it does not, and why running one might be worth your time.
The problem with remote RPCs
When your dApp calls eth_getBalance against a remote endpoint, the response travels over TLS to your device. TLS protects the wire. It says nothing about whether the node at the other end is honest. A compromised or malicious RPC can serve a fake balance, hide a transaction, profile your address queries, or simply go down. You have no cryptographic recourse.
This is not a hypothetical threat. It is the architectural default for every application that delegates reads to a provider.
A light node does not require you to trust the upstream RPC. It uses the upstream RPC as an untrusted data source and verifies every answer before surfacing it. A malicious or offline upstream can withhold responses — it cannot forge one that passes verification.
What a light node actually is
A Krypton light node runs krypton-edge-light, a Rust binary. It holds no chain state, no private key, and no consensus weight. It does not validate, does not produce blocks, and earns no rewards — light and edge nodes are explicitly excluded from emissions. The honest one-line trust statement:
A self-hosted node that verifies the chain, trusting a checkpoint and 2/3 of the validator set.
When you start the node, it bootstraps from a weak-subjectivity checkpoint signed by a k-of-n quorum of known publisher keys. From that anchor, it verifies forward. It points at remote CL and EL RPC endpoints — ones you supply — and runs every read through a verification pipeline before your application sees the result.
The verification pipeline
Each eth_* response passes through this chain before being served on loopback :8645:
C1 — BLS commit verification. The node fetches the latest CometBFT commit and verifies that ≥2/3 of the validator set's BLS12-381 keys actually signed it. This is not a reputational check. It is a cryptographic check against the pinned validator set. A validator set swap fails closed.
C2 — EVM state root anchor. The SSZ-encoded SignedBeaconBlock is the first transaction of the CometBFT block, committed under the header's DataHash. The node recomputes that hash, confirms it matches the C1-verified header, then SSZ-decodes tx[0] to extract the execution payload's StateRoot. The EVM root is now bound to the verified consensus header.
C3 — Merkle-Patricia proof verification. The node calls eth_getProof (EIP-1186) against the untrusted upstream, then verifies the returned account and storage proofs against the C2-anchored StateRoot. A tampered value fails this check. The upstream cannot construct a valid Merkle proof for a value that does not exist in the committed trie.
C6 — Staleness gate. A head older than KRYPTON_MAX_STALENESS_SECS is rejected. An eclipsed upstream feeding a valid-but-old view — where every proof verifies cleanly but against a stale root — fails here.
Anti-eclipse is layered on top: configure ≥2 independent CL endpoints and set KRYPTON_MIN_SOURCES=2 to require multi-source head agreement before any read is served. An optional Bitcoin-anchor gate adds defense-in-depth on top of the k-of-n checkpoint.
Remote RPC vs. light node
| Remote RPC | Light node | |
|---|---|---|
| Trust requirement | Trust the provider to be honest and available | Trust a checkpoint and 2/3 of validators |
| Forged balance | Undetectable | Fails C3 (invalid MPT proof) |
| Stale head | Undetectable | Fails C6 (staleness gate) |
| Provider profiling | All queries visible to provider | Queries stay on your machine |
| Censorship / rate-limiting | Subject to provider policy | Independent of provider policy |
| Withholding data | Undetectable | Detectable (node stalls, does not serve bad data) |
| State storage | None (provider holds it) | None (light node holds no state) |
| Earning potential | N/A | None (explicitly excluded from emissions) |
| Hardware requirement | None | ~2 GB RAM; no SSD required in light mode |
What the node serves
The verified RPC is available on loopback 127.0.0.1:8645 (distinct from a full node's :8545). The served subset:
eth_getBalanceeth_getTransactionCounteth_getCodeeth_getStorageAteth_blockNumbereth_chainIdeth_call(verified via local re-execution overeth_getProof-verified state)
This is deliberately not the full surface. Historical queries, debug and trace endpoints, and archive depth are not served. For those, run a full node. The light node's surface covers the reads that wallets and application backends need for every transaction: balance, nonce, code, storage, and contract calls.
What a light node is NOT
Be clear about the boundaries before you run one.
It is not a validator. It has no stake, no key, and no influence over consensus. It does not earn block rewards or any per-node payout.
It is not a full node. It holds no chain state and cannot answer historical or archival queries. It depends on external CL and EL endpoints for data — it verifies that data, but it cannot conjure it if every upstream is offline.
It is not a security boundary for anyone other than its own operator. It verifies the chain for you. It does not make the network more secure for others.
It does not eliminate trust entirely. It relocates trust: from "believe what this RPC tells you" to "believe a signed checkpoint and a supermajority BLS commit." A ≥2/3 cartel of validators could finalize a bad state root that the light node would faithfully serve as verified. That is the chain's own BFT assumption. It is narrower than trusting a single RPC provider, but it is not zero.
Hardware and status
The reference appliance is a Raspberry Pi 4 or 5. In light mode, the SSD requirement is dropped — the node holds no chaindata. The same binary runs on x86-64, other ARM boards, VMs, and containers; build it with cargo build --release for your target.
Status: the verification pipeline is built and was validated end-to-end against the devnet (beacon-kurtosis-80087). A turnkey checkpoint bundle for the public testnet (chain-id 473374) does not ship yet — you supply the endpoints and a checkpoint produced from the live testnet. A live, reachable 473374 RPC fleet is the hard prerequisite before you can deploy.
The short version
A remote RPC asks you to trust it. A light node trusts a checkpoint and 2/3 of the validators, and verifies everything else cryptographically before your application sees it.
If you transact on Krypton and want balance, nonce, code, and contract-call reads that cannot be forged by an upstream, a light node is the right tool. If you need full history or archive depth, run a full node instead.
Details: Edge node documentation · Node type overview · RPC node