The complete reference, in one place.
Open the searchable protocol reader for every publication, core, consensus, execution, service, and compatibility document.
Open full protocol↗NULS / KNOW THE GROUND BEFORE YOU BUILD
The protocol
comes before
the chain.
This reference introduces NULS as a protocol foundation and maps the current NULS Mars implementation workspace. It is organized around boundaries, choices, and responsibilities — not feature marketing.
OPEN PROTOCOLSINCE
2017
2017
HOW TO READ THIS REFERENCE
Read the protocol
as a system.
Start with the complete map, then follow the dependencies: shared principles, canonical data, network agreement, execution boundaries, and service modules.
Shared ground first.
Understand what a network must preserve before choosing how it should evolve.
Read design principles↓Follow the dependency.
Move from architecture to frontier modules and ChainBox without skipping the boundaries between them.
Follow the architecture↓02
DESIGN PRINCIPLES
Share the invariants.
Keep the policies open.
NULS treats a network as an agreement with two kinds of content: the truths it must preserve, and the choices its participants must be free to make.
01Specify before implementing
Protocol invariants, canonical serialization, and validity rules give every implementation a shared ground.
02Compose, do not hard-code
Consensus engines, VM capabilities, application modules, economics, and deployment targets should meet at explicit interfaces.
03Make the boundaries inspectable
A network specification must be validated, versioned, and traceable — not scattered across secret scripts and undocumented defaults.
03
SYSTEM ARCHITECTURE
Five layers.
One accountable system.
The current architecture describes a practical implementation map. The protocol remains larger than any one runtime or language.
Applications & wallets
↗SDK · CLI · wallet · explorer · AI service · industry applications
Services & coordination
↗nuls-ai-service · nuls-compute-pool · API · indexer · governance tools
Execution & state transition
↗transparent / privacy / system tx · contract · application modules · WASM / EVM / SVM / Move
Consensus & network
↗POC / AIPOW / PBFT / custom consensus · P2P · relay · evidence · checkpoint
Foundation
↗storage · state root · cryptography · serialization · address · NA amount
Dependency direction matters: a host node may assemble concrete capabilities; a stable abstraction should not depend back on its implementations.
04
FRONTIER MODULES / THE WHY BEFORE THE WHAT
Four directions.
Four responsibilities.
These modules are not a claim that every capability is production-ready. They are the protocol questions NULS Mars puts into code, testnets, specifications, and community review.
Prove the transfer, not the entire relationship.
WHY IT MATTERS
A transparent ledger can reveal payment, commercial, and identity relationships forever. Selective disclosure lets a network preserve public validity without treating every participant’s context as public data.
PROTOCOL SHAPE
Groth16 / BLS12-381 · note · commitment · nullifier · Merkle root & witness · viewing key
CURRENT BOUNDARY
A network must pin the verification-key hash through its profile or governance; arbitrary user-carried verification keys are not an admission model. Full wallet lifecycle and circuit coverage remain production gates.
Useful GPU work needs objective protocol rules.
WHY IT MATTERS
Demand for AI compute is real. The hard question is whether security can ask miners to contribute verifiable compute capacity without making chain validity depend on subjective model outputs.
PROTOCOL SHAPE
GPU challenge → compute proof → score → leader / block order
CURRENT BOUNDARY
AIPOW is an isolated testnet and special-network experiment. GPU challenge evidence is its consensus input; model inference, HTTP probes, service quality, and energy accounting are separate service concerns — not fork choice, rewards, or slashing inputs.
Cryptographic debt compounds quietly.
WHY IT MATTERS
Keys and addresses stay in wallets, integrations, backups, and legal records for years. Planning for quantum-resistant primitives early makes an eventual migration a deliberate protocol decision rather than a rushed emergency.
PROTOCOL SHAPE
ML-DSA-65 / ML-KEM-768 / SHA-3 · binary V3 address: 72 bytes
CURRENT BOUNDARY
Longer V3 addresses are an explicit trade-off. A final standardized profile needs official known-answer tests, cross-implementation interoperability, independent audit, and a governed genesis profile before it can be described as production-approved.
Execution diversity is a protocol choice.
WHY IT MATTERS
EVM, SVM, WASM, and Move carry different programming models, asset semantics, and developer ecosystems. A future-facing base protocol should let a network compose these worlds at explicit, inspectable boundaries.
PROTOCOL SHAPE
nuls-vm-core registry · EVM / SVM / WASM / Move capabilities · network VM profile
CURRENT BOUNDARY
A module’s presence does not claim that its runtime is activated or production-ready. Each VM needs its own safety, compatibility, governance, and admission evidence; a ChainBox profile makes activation deliberate rather than implicit.
04
CHAINBOX / CHAIN SPEC COMPILER
From intention
to a verifiable network.
ChainBox v2 is a host-side chain-spec compiler and runtime orchestrator. It selects, generates, validates, assembles, and starts — while node crates retain the state machine, consensus, sync, and execution responsibilities.
INPUTchainbox.tomlA stable chain specification
→VALIDATE / NORMALIZEChainSpec compilerschema · canonical serialization · digest
→OUTPUTchain-spec.jsonmanifest hash · node / genesis / deployment adapters
CAN CONFIGURE
Identity, native asset & economics, genesis consensus, VM capabilities, node topology, storage, observability, cross-chain peers, and statically linked application modules.
DOES NOT DO
It does not copy the state machine, accept unaudited dynamic modules, place secrets in configuration, or fake a protocol upgrade with a local setting.
05
MODULE MAP
A protocol is a
constellation of responsibilities.
Each module below exists to make one boundary explicit. Together, they map the current NULS Mars workspace and its implementation conversations.
Common types, cryptographic suites, storage, module lifecycle, and protocol versioning.
- nuls-core
- nuls-crypto
- nuls-storage
- nuls-module
- nuls-protocol
- nuls-pq-wasm
Accounts, ledger state, transaction validity, blocks, privacy, and multisignature semantics.
- nuls-account
- nuls-ledger
- nuls-transaction
- nuls-block
- nuls-privacy
- nuls-multisig
P2P, node lifecycle, consensus abstractions, and distinct consensus implementations.
- nuls-network
- nuls-node
- nuls-consensus
- nuls-consensus-poc
- nuls-consensus-aipow
- nuls-consensus-pbft
Contract host, VM registry, and pluggable execution capabilities for different ecosystems.
- nuls-contract
- nuls-vm-core
- nuls-vm-wasm
- nuls-vm-evm
- nuls-vm-svm
- nuls-vm-move
AI service, compute pools, cross-chain boundaries, and public or adapter APIs.
- nuls-ai-service
- nuls-compute-pool
- nuls-crosschain
- nuls-crosschain-peer
- nuls-api
- nuls-api-bridge
- nuls-service-api
Chain management, ChainBox specifications, SDKs, and the command-line surface for building and operating networks.
- nuls-chain
- nuls-chainbox
- nuls-sdk
- nuls-cli
06
READING THE SYSTEM
AN HONEST REFERENCE
Presence in a workspace
is not a production claim.
Read each design document as a contract of intent and boundary. Implemented code, testnet support, audited capability, and production admission are separate states that should never be collapsed into one marketing statement.