The network
Status: certified base v0.1.0 · active hardening · public testnet not live.
Nitrograph Base is a standalone, native hashgraph ledger. It preserves an aBFT consensus platform and a native-service application model, and removes live smart-contract execution entirely, verified on every build. Agent-native protocol services will be added above the native service layer; see Protocol.
Architecture
Peer network and node identity
→ event creation and gossip
→ hashgraph consensus ordering
→ consensus-timestamped transactions
→ admission: signatures, payer authorization, replay/expiry
→ fees, congestion pricing, throttles
→ native service dispatch
→ deterministic Merkle-backed state
→ signed states (every round bound to a state hash)
→ record and block streams
→ mirror and indexer consumers
Two properties matter most for agent workloads:
- Fair ordering. There is no mempool and no block builder. Transaction order comes from consensus timestamps, not from priority auctions. When many agents contend for the same market, none of them can pay to jump the line.
- Deterministic economics. Fee assessment, congestion pricing, and throttle buckets are protocol machinery. Costs are predictable enough for software to budget against, and the network applies backpressure instead of melting under load.
Native services (certified base)
The accepted baseline retains meaningful implementation and test coverage for:
- accounts, aliases, auto-account creation, balances, and transfers;
- fungible and non-fungible tokens: creation, minting, transfers, associations, allowances, airdrops;
- fixed, fractional, royalty, and other native custom fee schedules;
- consensus topics, topic messages, and topic fees;
- schedules: creation, signing, expiry, and native scheduled work;
- files and system files;
- node creation, update, deletion, roster management, and administration;
- staking elections, rewards, and reward accounting;
- atomic batches with rollback;
- fee charging, congestion pricing, and throttling;
- deterministic rejection of malformed and unauthorized transactions.
There is no VM. New capability is added as native services with schemas, migrations, and handlers, not as user-deployed code.
The execution boundary
The baseline census, enforced by checked-in policy on every build:
| Boundary | Count |
|---|---|
| Successful contract creation sites | 0 |
| Successful contract call sites | 0 |
| Ethereum execution sites | 0 |
| Executable local contract-query sites | 0 |
| Intentional rejection probes | 8 |
| Unclassified executable sites | 0 |
The eight probes exist on purpose: they submit execution-shaped transactions and require deterministic rejection, proving the boundary fails closed. Historical contract-shaped records and schemas are retained only for compatibility; mirrors can interpret history without any live execution path existing. See Evidence for how these claims are verified.
Lifecycle (certified)
The accepted baseline passed, with published evidence artifacts:
- clean four-node genesis and native state generation;
- saved-state creation and clean restart;
- a real stale-learner reconnect with transferred-state hash comparison;
- post-reconnect native transaction processing;
- certified mirror ingestion of record and block streams.
Hardening and qualification before public testnet
The base network is a certified artifact; before it becomes a public network it must survive time, scale, upgrades, and faults. Two programs gate that: audit remediation (active now) and network qualification (next). Together they cover:
- audit-remediation work from the independent baseline review;
- behavioral execution-boundary tests running in CI;
- cryptographic differential testing of the shipped signature verifier;
- reconnect-evidence hardening and recovery-edge-case testing (stale state with newer preconsensus events; configuration-version mismatch refusal);
- record-stream reconciliation closure;
- step-load, soak, and chaos testing across four-node and seven-node topologies;
- artifact, dependency, and deployment-key verification.
Performance numbers will be published here when, and only when, the qualification program produces them. Until then, no throughput or latency claims are made.
Status panel
| Item | State |
|---|---|
| Certified base | v0.1.0 |
| Development state | private hardening |
| Internal devnet | not yet persistent |
| Public testnet | not live |
| Mainnet | not live |
| Agent-native services | in design / planned; see Protocol |