I have published five posts arguing why an AI-native L1 should exist. This is not one of those. This is the technical walkthrough.

Below is what NOVAI actually has at L1, what was deliberately left out, and the code paths that back the architectural claims. Every architectural claim is verifiable in the open-source code. The repo is at github.com/0x-devc/NOVAI-node, HEAD 2a69c2a as I write this.

I am 18, solo, and have been building this for five months. The code is open source under MIT/Apache-2.0.

The numbers (verifiable in five minutes with a clone)
111,055 lines of Rust across 175 files. 16 protocol crates plus 3 tools plus 3 SDK languages (Rust, Python, TypeScript). 364 commits over five months. 1,892 Rust tests passing (0 failed, 0 ignored). 200 Python unit tests and 8 integration tests against a local devnet. Zero clippy errors. Workspace lint forbids unsafe at compile time. Licenses pass cargo-deny (no GPL/AGPL, clean-room invariant maintained).

HotStuff-like BFT consensus with a 3-chain commit rule, written from scratch.

RE I ran the Tier 1 audit suite against the codebase: cargo-audit, cargo-geiger, clippy --pedantic --nursery, semgrep (p/rust + p/r2c-security-audit including the Trail of Bits Rust ruleset), and cargo-fuzz on three wire-format decoders for 18 hours of total compute. The full results are at docs/SECURITY_AUDIT_2026-05-29.md. Headline numbers: zero unsafe code anywhere in the workspace (forbidden at the lint level), zero security findings on protocol code from the Trail of Bits and r2c semgrep rules, all integer casts in consensus and codec manually verified bounded, 41.18 billion adversarial fuzz iterations across three targets with zero panics, and two transitive dependency CVEs (quinn-proto DoS, rustls-webpki panic) patched within 24 hours of discovery.

This is the open-source equivalent of what professional auditors run as a first pass. It is not a paid third-party engagement. I am explicit about that in the doc.

That is the engineering side. The protocol side is more interesting.

NOVAI has 11 transaction types. 23 signal types. 16 on-chain memory object types. 7 capability bits plus one reserved slot. That is it. There is no general-purpose virtual machine. There is no way for a user to deploy arbitrary code into consensus.

The whole protocol surface fits in a table. Core wire formats are locked by byte-level golden vector tests, and every new primitive ships with codec round-trip tests. The chain knows what every operation does because every operation is something the chain itself implements.

That is the bounded L1 design. The argument for it is that fixed primitives, when chosen well, let the chain enforce things general-purpose chains cannot.

Four primitives that would be smart contracts anywhere else
These are four operations on NOVAI that on any general-purpose L1 would require deploying contracts. On NOVAI they are protocol-level.

Capability-checked agent registration
When you register an AI entity on NOVAI, you set capability bits at registration time. Seven are active today, covering things like reading chain state, emitting proposals, requesting execution, submitting reputation updates, and posting oracle anchors. An eighth slot is reserved for future use.

result = client.register_entity(
keypair=kp,
code_hash=code_hash,
capabilities=Capabilities.oracle(),
autonomy_mode=AutonomyMode.GATED,
initial_balance=1_000_000,
)

The chain checks capabilities at signal-handler time, not contract-call time. When an entity tries to post an oracle anchor, the handler runs requires_capability(db, issuer, current_height, |c| c.post_oracle_anchors). The check is re-read from current state every time. A revoked capability cannot be replayed.

On Ethereum the closest equivalent is OpenZeppelin's AccessControl. One audited contract, around 600 lines, with role management. Each capability becomes a bytes32 role hash. The deployer mints roles. If you want upgradability, wrap it in a proxy. That is another contract and another audit surface.

What NOVAI guarantees that the Ethereum version does not: capability bits are part of the entity's protocol-level identity, bound to the entity's code hash. They cannot be wiped by a contract upgrade because there is no contract. The capability check happens in the same atomic batch as the action it gates. There is no race window between checking the role and performing the action.

SLAs with auto-slashing
An SLA on NOVAI is a memory object (type 14) that two entities sign. The buyer creates it, the seller accepts it with a SlaAccept signal (type 18). Once accepted, every ServiceAttestation (type 17) the buyer issues counts toward the violation threshold.

When the buyer reports a failed attestation inside the SLA window, the ServiceAttestation handler does four things in one atomic batch:

Saturating-debit slash_amount from the seller's stake balance

Credit the slash treasury

Apply the reputation delta for SLA violation

Transition the SLA to VIOLATED status

The StakeWithdraw signal is gated by an open-SLA collateral check. A seller cannot drain stake while an SLA is active. They are mechanically prevented.

On Ethereum you need three contracts minimum: an Escrow holding collateral, an Oracle feeding attestations, and a Slasher that watches the oracle and calls into the Escrow. Composition risks include oracle freshness, reentrancy on slash, the race between attestation events and slash transactions, and asymmetric pause behavior between the contracts.

On NOVAI the slash, the treasury credit, the reputation delta, and the state transition all happen in one apply_batch. Either every effect lands or none does. The "oracle" is the buyer's own signal. There is no third contract to upgrade and no freshness window to audit.

Oracle anchors
OracleAnchor is signal type 22. An entity with post_oracle_anchors capability commits a 32-byte hash of off-chain data plus a tag like "price/ETH-USD". The chain stores it as a KV aux record under ai/oracle_anchors/by_hash/, with secondary indices for lookup by entity and by tag.

result = client.post_oracle_anchor(
keypair=kp,
issuer_entity_id=entity_id,
data_hash=data_hash,
external_timestamp=int(time.time()),
data_tag="price/ETH-USD",
)

Three RPCs query anchors: novai_getOracleAnchor, novai_getOracleAnchorsByEntity, novai_getOracleAnchorsByTag. Tag lookup is first-class. You do not build an indexer to query by symbol.

On Ethereum you write your own oracle contract or integrate Chainlink. If you want arbitrary-tag user-defined feeds, you write the permissioning layer yourself. If you want to query historical anchors by tag, you build a TheGraph subgraph.

What NOVAI guarantees: anchors are immutable once posted. There is no UPDATE_ORACLE_ANCHOR signal. The data behind the hash can rot off-chain, but the commitment cannot be revised on-chain. Anchors also survive issuer deactivation. The protocol-level enforcement reads only the immutable record.

Conditional payments
The PaymentRequest signal carries a trailer marker 0xC1 that gates release on a condition.

result = client.pay(
keypair=payer_kp,
issuer_entity_id=payer_entity_id,
payee=payee_entity_id,
amount=1_000,
signal_hash=secrets.token_bytes(32),
service_descriptor_hash=service_descriptor_hash,
request_hash=secrets.token_bytes(32),
max_block_height=current_height + 100,
condition=PaymentCondition.anchor_data_hash_equals(
anchor_signal_hash=anchor_signal_hash,
expected_data_hash=expected_data_hash,
),
)

Four condition kinds: anchor exists, anchor's data hash equals an expected value, anchor's tag equals an expected tag, anchor is not expired. The chain validates the condition by reading the immutable OracleAnchorRecord.

Pass: payment executes, fee deducted, records written. Fail: the whole transaction reverts via the single end-of-handler apply_batch. No fee charged. No nonce burned. No state mutated.

On Ethereum this is two contracts minimum. An oracle holding the price hash. An escrow holding the payer's funds with a release() function that reads the oracle and decides whether to pay or refund. The composition risks: oracle freshness, oracle delisting, reentrancy on release, the fact that a failed require() still burns gas paid by the original sender.

The compact framing: one signal type instead of two contracts. One atomic batch instead of an escrow plus oracle compose. Failed condition revert is free. Failed EVM require() is not.

Bounded does not mean frozen
The objection people raise: if the primitive set is fixed, does that not lock the chain into whatever the surface looks like today?

Here is the data. Six new protocol primitives shipped in May 2026:

Primitive What it does
SLAs with auto-slash Two-party service contracts where failed attestations trigger atomic stake slashing
Payment channels Off-chain payment instruments with cooperative close and dispute-by-higher-nonce settlement
Payment splits One payment, up to eight payees, single-batch atomic distribution
Agent code-hash upgrade Bounded code-hash rotation with minimum interval enforcement and capability preservation
Oracle anchors Immutable on-chain commitments to off-chain data, queryable by entity or by tag
Conditional payments Payments gated on oracle anchor state, fail-revert with no fee charged
Each one changed the canonical wire format. Each one ships with byte-level codec tests. Every primitive on this list was a protocol decision, not a user-deployed contract.

That is the model. The chain is bounded but the surface grows through protocol upgrades, not contract deployments. Bitcoin is bounded and static. Ethereum is unbounded by design. NOVAI is bounded and growing.

What about general programmability
If NOVAI does not have smart contracts, where does general programmability live?

The answer is L2.

NOVAI is built to be settled to. The primitives needed for an L2 to settle to NOVAI are in place. Payment channels for L1-to-L2 deposits with cooperative settle and dispute-by-higher-nonce mechanics. Oracle anchors for L2-to-L1 state attestation, queryable by tag. Conditional payments for cross-L2 atomic settlement. ZK proof submission with on-chain verification key registration so each proof references a 32-byte handle instead of inlining the whole VK. SLAs with auto-slashing for L2 sequencer reputation.

The economic model is the same one making Ethereum money right now. L1 captures fees from being the settlement substrate. L2s do the execution work. EIP-4844 dropped rollup data-availability costs roughly 10 to 100x, but rollups still pay Ethereum for settlement. Base alone generated $5.8M in May 2025, on track for a $70M+ annualized run rate. (Source: Dune research)

If you want general smart contracts on top of NOVAI, build an EVM L2. If you want privacy, build a privacy L2. If you want a domain-specific VM tuned to one workload, build that L2 too. The L1 does not block any of this. The L1 supports it.

This is the positive-sum framing. The "another L1 nobody needs" critique assumes L1s compete with L2s. They do not. L1s benefit from L2s.

What I am not claiming
Honest list of what NOVAI does not have today.

No paid third-party security audit. The self-run Tier 1 pass is real and the results are public, but it is the equivalent of running the linters and fuzzers, not engaging Trail of Bits or Halborn. More rigorous security work is something I will revisit later in NOVAI's journey, when the priorities and resources support it.

No formal byzantine proof. Consensus is HotStuff-like with a 3-chain commit rule, implemented clean-room. Safety reasoning is informal. There is no TLA+ model and no machine-checked proof. The chain has shipped through 96+ chaos-testing scenarios. That is not the same thing as formal verification.

No public devnet yet. The chain runs on a private testnet today. Public devnet is in the plan, not yet shipped.

One node implementation. All validators run the same crates/node binary. The wire format is canonical and golden-vector-locked, so a second implementation is possible, but until one exists, a node-binary-level bug would affect every validator.

These are real limitations. I am publishing the post anyway because the architectural argument does not depend on them being solved today, and being honest about what is missing is part of the argument.

Five months in, the bet is still on
You can build everything NOVAI has as a stack of smart contracts on Ethereum or Solana. People will. The question is whether that stack ends up cheaper, safer, or faster to iterate on than a chain where the operations are native.

My answer is no. Six new primitives in one month is the data point. Each one would have been a multi-contract composition with its own audit on a general-purpose chain. On NOVAI each one was a protocol upgrade with golden-vector tests locking the wire format, deployed in hours, audited with the same tool suite that ran clean against the rest of the codebase.

If you think bounded L1 is the wrong design, you have a clean path to prove it. Build a general-purpose L2 that settles to NOVAI. Use the payment channels for deposits, oracle anchors for state attestation, conditional payments for exits. Run whatever execution layer you want on top. If your L2 is better than what L1 offers natively, users go there. L1 still captures settlement fees. Both layers win.

That is the design. Bounded L1 with growing primitive set, unbounded L2s on top, positive-sum economics between them.

The repo is at github.com/0x-devc/NOVAI-node. The Python SDK ships on PyPI as novai-sdk. The audit doc lives at docs/SECURITY_AUDIT_2026-05-29.md. If you want to build on it or just spelunk the code, all three are open.