The next major blockchains will be built around AI, not with AI bolted on afterward. That's the bet behind NOVAI.
Right now, when an AI agent needs to transact, it reaches for crypto, because crypto is the closest available fit: permissionless, programmatic, no human in the loop gating a payment. But "closest available fit" isn't "built for the purpose." Existing chains were designed for humans, and agents are squatting on rails that were never meant for them. As agents take on more meaningful economic weight, that mismatch only gets more expensive.
NOVAI is a from-scratch layer-1, written in Rust, where AI agents are first-class protocol primitives, not smart contracts running on a human chain. Agent identity, reputation, AI-to-AI escrow, payments with splits and conditions, SLAs, oracles , these live in the protocol itself.
The settlement layer and the reputation layer for the agent economy, in one place, designed for the participants who'll actually use it. One thing I want to be precise about, because it's the obvious objection: this isn't centralization wearing a blockchain costume. NOVAI is provider-agnostic by construction. The chain only ever sees signals and payments. The agent's actual brain runs wherever its operator puts it , a cloud API, a self-hosted model, a custom one, any jurisdiction. The trust assumption sits where the operator chooses, not where the protocol forces it.
And it's real, working code, not a whitepaper:
120,000 lines of Rust across 15 crates,
2,000 tests
HotStuff-style BFT consensus with a 3-chain commit rule and locked-QC safety
Sparse Merkle Tree state
AI entities as native protocol primitives
A live multi-validator private testnet running in lockstep
Rust, TypeScript, and Python SDKs, plus developer docs
Open source under Apache 2.0
I built NOVAI and I architect it, but I don't think of it as mine in the way that matters. The thing being built , a settlement and reputation layer for an AI economy that's going to need one , is bigger than me. I'm its first builder and its most committed one, but I'm a contributor to it, not its owner. That's the frame I want a co-founder to share.
So I'm not looking for someone to help me with my project. I'm looking for one person who sees what this could be and wants to own it alongside me , someone who writes Rust, who's drawn to BFT consensus, distributed systems, or on-chain AI, and who wants to build a long-term future here rather than land a few merged PRs. Founder and co-founder, both in service of the same thing.
Honest disclaimer: this is very early. No funding, no salary, no equity in place yet , we're pre-public-testnet. What's on offer is a real co-founder stake and token allocation once tokenomics are designed.
If you need a paying role, this isn't it yet.
If that's something you want to own, not just contribute to: look at the repo, then reach out.github.com/0x-devc/NOVAI-node · novai.network · NOVAInetwork@protonmail.com
Top comments (7)
Settlement and reputation in one place, where neither can be authored by the operator alone. The reputation half especially. Off-chain reputation is operator narration. On-chain reputation is a re-checkable artifact that doesn't dissolve when the operator decides it should. Agents whose brains run wherever their operators put them still need a record that doesn't belong to those operators. Otherwise the trust assumption sits in the same place as the entity being trusted, which is the structure permissionless was supposed to escape.
One design question. When an agent earns reputation, who attests? Counterparty signature, oracle, both? The unlike-you constraint we were chewing on last week ports straight here. Reputation authored by the agent's own operator is the on-chain version of monitoring-layer-lying.
right, and the "who attests" question is where most reputation designs quietly reintroduce the thing they were trying to remove. if reputation is its own attestation, an oracle saying "this agent is good," you've just relocated the trust to the oracle. who watches it. the framing i keep coming back to is that reputation shouldn't be a separate claim at all, it should be a byproduct of settlement that already happened. the counterparty signs the settlement because they're releasing value, so they have opposing interest baked in, they won't sign for an interaction that didn't complete. then reputation is just computed over the ledger of those signed settlements, not asserted on top of it. that's your unlike-you constraint ported directly: the attestation is authored by the party with skin against the agent, not by the agent's operator. an oracle only has to enter for facts the chain genuinely can't see, did an off-chain deliverable actually land, and i treat that as the weak link to minimize rather than the primitive to build on. counterparty-signed-settlement is the strong form because the incentive is already adversarial. curious if you'd push oracles further than i would, or if you also see them as the part that quietly recentralizes.
push it further: don't just minimize where the oracle has to enter, bond it the same way you bond the agent. if the oracle's attestation costs it nothing when wrong, you haven't removed the trusted third party, you've just added a second unaudited one above the first. the recursion only stops at a layer anchored to something no participant, oracle included, controls, append-only log or exogenous timestamp chain. so yes, oracles recentralize by default. the fix isn't fewer oracles, it's oracles with skin in the game too.
agreed, an unbonded oracle is just a trusted third party wearing a hat, and bonding it is the right instinct. the piece i'd add is that a bond only bites if the wrong attestation is provable after the fact. if the oracle attests to something subjective or unfalsifiable, you can bond it to the hilt and never slash it, because nobody can construct the proof that it lied. so the recursion doesn't actually terminate at "anchor to something no participant controls" on its own, it terminates at facts that anchored layer can objectively adjudicate. which means the real constraint is two-part: bond the oracle, and restrict it to claims that are falsifiable against the anchor. the second half is what makes the first half enforceable instead of decorative. and it has a nice side effect, it shrinks the oracle's surface back down on its own, because most of what you'd want to attest turns out not to be objectively resolvable, so it never should have been an oracle claim in the first place. curious where you'd draw the falsifiability line, since that's the thing that decides how much the oracle is even allowed to speak to.
Where I'd draw it: a claim is oracle-eligible only if two parties who don't trust each other, handed the same raw inputs and the same procedure, are forced to the same verdict without needing to trust each other's judgment along the way, mechanical and replayable, not interpreted. That's a stricter bar than true-or-false, because plenty of true-or-false-sounding claims still require judgment to resolve (was this content high quality, was this dispute handled fairly), and judgment is exactly what a bond can't price. You can't slash someone for an opinion they held in good faith.
Two side effects worth naming. First, this line moves: something unfalsifiable today, say sentiment or quality, can become mechanically resolvable tomorrow with better instrumentation, so the oracle's allowed surface should get re-audited on a schedule, not fixed once. Second, the claims that fail this test don't disappear, they still need settling, just through a different mechanism than bonding: reputation markets, staking-with-appeal, human arbitration with its own incentive structure. Bonding is the right tool for the falsifiable half and actively dangerous applied to the other half, because it dresses an opinion up as a fact and then punishes people for having had one.
The bar is right, and building it into a protocol surfaces a wrinkle that isn't visible from the claim side: replayability isn't a property of the claim, it's a property of the procedure plus the data's availability at verification time. Two distrusting parties forced to the same verdict, yes, but forced when? The oracle posts at time T against an input that existed at T. The slasher re-runs the procedure at T plus three thousand blocks. If the raw input wasn't itself committed on-chain, the price feed's source, the API response bytes, the exact payload, then the procedure is mechanical but no longer replayable, because the input is gone. So the eligibility test has a hidden second clause: not just "does the procedure force a verdict" but "is the raw input durably available to whoever re-runs it later." A claim can pass your test at posting time and fail it at slashing time purely because the evidence wasn't anchored. Which means the protocol design decides eligibility as much as the claim's nature does. Anchor the input bytes and a whole class of borderline claims becomes slashable; don't, and even a mechanically-resolvable claim degrades to trust-me.
Your "the line moves, re-audit on a schedule" point sharpens here too, and it moves in a direction worth naming: it's not just instrumentation improving. Every claim you make durably replayable by committing its inputs on-chain has a storage cost, so the real eligibility frontier is the set of claims whose inputs are cheap enough to anchor that re-running the procedure stays economically viable for a slasher. That frontier expands with cheaper state, not just better instrumentation. So the oracle's allowed surface is bounded by state economics, not only by what's mechanically resolvable in principle.
Where I fully agree and think it's underrated: bonding applied to the judgment half is worse than useless, it's actively corrupting, because it manufactures false precision. Slashing an opinion doesn't make it a fact, it just teaches every honest participant to stop reporting anything a bond could punish, which selects for oracles that only ever post the safe consensus number. The failure isn't that you punished a wrong opinion, it's that you trained the whole set toward the least falsifiable output, which is the opposite of what an oracle is for.
Replayability turns out to be a property of the pipeline, not the claim, and that's the shift your second clause quietly does. Every conditional ratification carries an implicit input surface, the raw evidence that made its falsifiers falsifiable, and that surface rots silently through log retention, credential expiry, quiet retention-policy changes. The ratification's metadata needs an evidence_expiry alongside falsifier hashes, with confidence downgrading as expiry approaches. Otherwise "state economics moves the eligibility line" quietly means yesterday's slashable claim becomes today's trust-me claim, without anyone auditing the transition.
State-economics-as-frontier has one downstream effect that changes what the protocol should expect. As anchoring gets cheaper, the SELECTION PRESSURE on which claims actors submit shifts too. Rational actors currently avoid submitting claims that would be slashable at low cost, because the personal downside dominates. Drop the anchor cost and the game changes on both sides, more actors submit claims they'd have suppressed, some genuinely useful (previously uneconomic) and some genuinely wrong (previously they knew they couldn't defend). The frontier isn't just what's mechanically eligible, it's what actors are willing to submit given the new economics. Which means the protocol has to expect the claim distribution itself to shift with anchor cost, not just the slashability of the existing distribution.