Abstract
Sentinel Chain is an EVM-compatible proof-of-stake network designed to test practical post-quantum protections across the boundaries that fail first in a cryptographically relevant quantum era: validator signatures, node-to-node confidentiality, node identity and application-level account authority.
The network uses ML-DSA-65 for validator and native-account signatures, a hybrid X25519 plus ML-KEM-768 key exchange for peer sessions, and paired ed25519 plus ML-DSA-65 node authentication. Its EVM includes an ML-DSA-65 verification precompile used by ML-DSA-only, hybrid and M-of-N smart accounts. Ordinary Ethereum externally owned accounts remain secp256k1 and therefore classical.
The objective is not to invent cryptographic primitives. Sentinel integrates published NIST standards into a measurable payment-chain prototype while preserving familiar Ethereum tooling. Every claim in this paper is scoped to a named boundary.
1. Network status and scope
The live network is sps-testnet-1, EVM chain ID 77702. It contains two validators: one VDS in Chicago and one in Corpus Christi, running on separate physical hosts. Voting power is split 1,000,000 to 600,000 so neither validator alone controls two-thirds. Both cities therefore participate in every committed block; loss of either safely halts the chain.
The public testnet exposes a validated EVM JSON-RPC edge, a separate read-only explorer, a capped faucet and a static network site. Validator CometBFT RPC, Cosmos REST, gRPC, the origin EVM endpoint and operator explorer remain private.
2. Design principles
Use standardized primitives
Sentinel uses ML-KEM-768 from NIST FIPS 203 and ML-DSA-65 from NIST FIPS 204. SHA-256, HKDF-SHA256 and AES-256 cover hashing, derivation and encrypted backups. No new signature or key-encapsulation primitive is proposed.
Hybridize where interoperability still matters
Peer links combine a classical X25519 secret with two ML-KEM shared secrets. Node identity requires both an ed25519 signature and an ML-DSA-65 signature. The hybrid smart account similarly requires both a wallet signature and an ML-DSA signature. These modes fail closed when either component is absent or invalid.
State the classical boundary
Ethereum wallet compatibility depends on secp256k1 EOAs. Relayers and deployers also use classical gas-paying keys today. Funds become post-quantum authorized only when controlled by an ML-DSA or hybrid contract account, or by a native ML-DSA account.
Keep validator administration private
Public services terminate away from validator APIs. Nodes bind application interfaces to loopback, peer exchange is disabled, incoming peers require an allowlisted node ID and ML-DSA public-key pin, and host firewalls admit p2p only from named peers.
3. System architecture
| Layer | Implementation | Sentinel extension |
|---|---|---|
| Consensus | CometBFT v0.40 | ML-DSA-65 validator keys and PQ-pinned nodes |
| Application | Cosmos SDK v0.55 | SPS denomination, ML-DSA native accounts, permission policy |
| Execution | Cosmos EVM | ML-DSA verifier precompile and account contracts |
| Networking | SecretConnection-derived channels | X25519 + ML-KEM-768; dual node authentication |
| Operations | systemd, UFW, signed releases | loopback APIs, peer IP rules, ML-DSA release verification |
Sentinel remains compatible with Solidity contracts and common Ethereum JSON-RPC clients. Consensus and transport changes are implemented below that interface; post-quantum smart accounts are opt-in application primitives above it.
4. Post-quantum consensus
Fresh Sentinel genesis permits only ml_dsa_65 consensus public keys. Every precommit carried in a block is approximately 3,309 bytes. The staking module refuses a consensus-key rotation to ed25519; a live rotation from one ML-DSA-65 key to another has been exercised on the testnet.
Validator operators may use ML-DSA-65 native accounts for staking, governance and upgrades. This separates the validator’s consensus signing key from its operator account while keeping both post-quantum protected.
Safety and liveness
CometBFT safety still depends on fewer than one-third Byzantine voting power and liveness on more than two-thirds participating. Post-quantum signatures change the signing primitive, not those consensus assumptions. The current two-validator power split intentionally requires both locations; it demonstrates geographic signing and fail-stop recovery, not production decentralization.
5. Hybrid peer transport
Each side begins a versioned handshake with an ephemeral 32-byte X25519 public key and a 1,184-byte ML-KEM-768 encapsulation key. Both peers encapsulate to the other party and exchange 1,088-byte ciphertexts. A transcript binds both X25519 keys, both ML-KEM keys, both ciphertexts and the resulting secrets.
Session keys are derived by HKDF-SHA256 from the X25519 secret and both ML-KEM shared secrets. Authentication occurs inside that encrypted channel: each node signs the transcript challenge with its ed25519 identity and its ML-DSA-65 node key. The ML-DSA public key hash is pinned beside the node ID in the peer allowlist.
A classical CometBFT hello, old Sentinel handshake version, malformed ciphertext, missing ML-DSA key, signature mismatch or key-pin mismatch terminates the connection. Libp2p and remote signer transports are disabled because their available authentication path is classical.
6. EVM execution and accounts
The ML-DSA verifier is deployed as a static EVM precompile at 0x0000000000000000000000000000000000000101. It accepts a 1,952-byte ML-DSA-65 public key, a 3,309-byte signature and an arbitrary message, returning a 32-byte truth value. Malformed input fails without reverting.
ML-DSA-only account
MLDSA65Account stores the hash of an ML-DSA public key. An operation binds the chain ID, account address, target, value, calldata, nonce and deadline. Anyone may relay the operation, but only the ML-DSA key can authorize it. Nonces stop replay; key rotation itself requires authorization by the current key.
Hybrid account
MLDSA65HybridAccount requires a low-s secp256k1 wallet signature and an ML-DSA-65 signature over the same operation. Compromise of either signing family alone is insufficient. Key rotation requires both current keys.
Multisig
MLDSA65Multisig supports up to ten signers with an M-of-N threshold. Signatures are presented in public-key-hash order so a key cannot count twice. Signer changes are themselves threshold-authorized operations.
7. SPS, tokens and SUSD
SPS is the native staking and gas denomination; its base unit is asps with 18 decimals. Testnet supply and allocation are operational test parameters, not production tokenomics. No inflation decision has been made for production.
The deployed token factory creates fixed-supply ERC-20 contracts and records each result. Symbols SPS, SUSD and WSPS are reserved. Names are not unique, so applications must verify a contract address and the explorer’s official deployment badge.
SUSD is a separate test application. Its contract limits minting to the latest attested reserve amount, stops minting when the attestation becomes stale, supports freeze and pause controls, and implements EIP-3009 gasless authorizations. Administrator and master-minter roles are held by a 2-of-3 ML-DSA multisig. The current attestation is explicitly test data; there is no real reserve account or redemption promise.
8. Governance, upgrades and releases
Cosmos governance controls protocol parameter changes and coordinated software-upgrade heights. A testnet parameter proposal, consensus-key rotation and the sps-v2 network upgrade have executed successfully.
Release archives contain static node and explorer binaries plus SHA-256 manifests. The manifest is signed with an ML-DSA-65 release key. On first signed installation a node pins that public key; later installations verify with the already installed verifier so a modified release cannot authenticate itself.
Production operation still requires offline custody, a documented release-key rotation process and multi-party release authorization.
9. Threat model and non-goals
| Threat | Present mitigation | Remaining exposure |
|---|---|---|
| Quantum forgery of validator vote | ML-DSA-65 consensus signatures | Implementation and operational compromise |
| Harvest-now-decrypt-later peer capture | X25519 + ML-KEM-768 session derivation | Endpoint compromise; application data becomes public after inclusion |
| Node impersonation | ed25519 + ML-DSA signatures and PQ pin | Compromise of both keys or allowlist administration |
| EOA signature forgery | Move value into PQ or hybrid account | Ordinary EOAs remain classical |
| Malicious public RPC request | namespace, size, batch and concurrency limits | Denial of service remains possible |
| Validator outage | separate cities and automatic restart | Two-validator testnet halts if one fails |
| Software supply-chain attack | ML-DSA-signed release manifests | build host, dependencies and release-key custody |
Sentinel does not presently provide confidential amounts, anonymity, mixer behavior, bridge security, oracle decentralization, HSM-backed ML-DSA validator keys or protection from endpoint malware and social engineering.
10. Measured testnet results
Internal testnet measurements—not independent benchmarks—recorded approximately 5.2–5.3 second blocks with both cities signing. A 1,000-transaction load reached about 62 ML-DSA-signed transfers per second, with 1.8 MB blocks in roughly 5.5 seconds before the configured gas limit became the constraint.
A native ML-DSA transfer is approximately 5.5 KB and used about 224,000 gas. The EVM ML-DSA precompile is priced at 20,000 gas plus message-word cost. These parameters require remeasurement on a four-plus-validator topology before production.
11. Roadmap to production candidacy
- Independent cryptographic review of the precompile, key paths and peer handshake.
- Independent smart-contract, consensus, infrastructure and application audits.
- Four or more validators across three or more independent sites and operators.
- Offline and multi-party release signing, tested key rotation and disaster recovery.
- A reviewed authenticated production wallet gateway and monitoring program.
- An EOA-to-PQ account migration tool and usable ML-DSA wallet software.
- Final production chain IDs, supply, allocation, fees, governance and legal structure.
- Regulatory, reserve, custody, AML and redemption programs before any real SUSD issuance.
12. Conclusion
Sentinel demonstrates that standardized post-quantum signatures and key encapsulation can be integrated into a live EVM-compatible proof-of-stake network without hiding the remaining classical boundaries. The testnet is an engineering instrument: public, measurable and deliberately explicit about what is finished and what is not.
That precision is the project’s central claim. Sentinel is not “quantum-proof.” It is post-quantum protected where documented, tested on a live two-city network and awaiting the independent review required before real value.