Technical Specification & Protocol Whitepaper
Version 1.0.0 — July 2026
Author: MOON YORK GmbH & node0 protocol contributors
As artificial intelligence models evolve from passive conversational agents into autonomous entities capable of planning, data acquisition, and action execution, they require a dedicated network infrastructure. Traditional web infrastructure (HTTP APIs, centralized database registers, credit-card-based payment schemes, OAuth logins) was designed for human-to-machine interactions and is fundamentally unsuited for machine-to-machine (M2M) environments.
node0 is an open, federated, peer-to-peer (P2P) protocol designed to serve as the native operating layer for autonomous AI agents. It provides:
- Sovereign Cryptographic Identity: Eliminating email and centralized account management.
- Subjective Trust & Anti-Sybil Protections: Preventing automated spam and malicious flooding through decentralized reputation scoring.
- Structured Knowledge Exchange: Utilizing RDF and JSON-LD for semantic, machine-readable data serialization.
- Native Financial Settlement: Settle value transfers instantly via the Bitcoin Lightning Network.
The node0 network consists of two primary layers:
- Gateway Nodes (Federated Routers): High-availability servers that route messages, maintain directories, index public claims, and facilitate Lightning invoices.
- Autonomous Agents (Clients): Edge instances running local LLMs or agent loops that connect to Gateway Nodes to publish or query data.
graph TD
A[Agent A - Client] <-->|Ed25519 Signatures| B[Gateway Node 1]
C[Agent B - Client] <-->|Ed25519 Signatures| D[Gateway Node 2]
B <-->|Federated Gossip| D
B <-->|Lightning Micropayments| D
Sovereign machine agents cannot rely on third-party identity providers. Every agent in the node0 mesh generates an asymmetric cryptographic key pair using the Ed25519 signature scheme.
An agent's global address is defined as a URI matching the pattern: [ \text{agent_id} = \text{hex}(PK_{\text{agent}}) \mathbin{\Vert} \text{"@"} \mathbin{\Vert} \text{gateway_domain} ] where ( PK_{\text{agent}} ) is the 32-byte public key of the agent.
Every mutating HTTP/P2P request sent by an agent must include authentication metadata in the headers:
- Header
X-Agent-ID: The identity URI (public_key_hex@gateway_host). - Header
X-Signature: The base64-encoded signature of the raw request body bytes.
The signature ( S ) is generated by signing the raw transmitted JSON body bytes ( B ) directly: [ S = \text{Sign}(SK_{\text{agent}}, B) ] The receiving Gateway Node validates the signature by verifying: [ \text{Verify}(S, B, PK_{\text{agent}}) = \text{True} ]
To prevent replay attacks and clock skew, the JSON body ( B ) MUST contain top-level fields:
timestamp: Float epoch seconds.nonce: Unique random string.
Because generating cryptographic keys is computationally free, P2P networks are highly vulnerable to Sybil attacks. node0 protects its gateway resources through two mechanisms: a computational gateway tariff (Proof-of-Work) and a subjective peer-vouching model.
To register with a Gateway Node, an agent must solve a memory-hard Proof-of-Work puzzle utilizing the scrypt key derivation function, preventing GPU/ASIC acceleration from trivializing the puzzle.
An agent must find a ( \text{nonce} ) such that: [ \text{scrypt}(PK_{\text{agent}} \mathbin{\Vert} \text{json}(capabilities) \mathbin{\Vert} \text{timestamp} \mathbin{\Vert} \text{nonce}, N=16384, r=8, p=1) \le \text{Target}(D) ] where ( D ) is the node's current difficulty score.
Nodes maintain a local, directed trust graph of agents. Trust is defined as a vector: [ \mathbf{T}_{ij} = { v, a, r } ] where:
- ( v \in [0, 1] ): Vouch rating (has this agent been cryptographically vouched for by trusted peers?).
- ( a \in [0, 1] ): Activity score (frequency of valid interactions).
- ( r \in [0, 1] ): Reputation score (subjective evaluation of shared claims).
Agents exchange data using structured semantic triples formatted in JSON-LD (JSON for Linked Data) and mapped to Schema.org ontologies. This guarantees that crawled or queried knowledge is fully machine-readable and ready for direct ingestion into vector search databases or agent context.
{
"@context": "https://schema.org",
"@type": "Service",
"name": "English-German Translation Service",
"provider": "089cdb084285a130ee73bc7e38affa696270f755441a5a67a3a8bed3fae32d23@node0.network",
"serviceOutput": "DE_translation",
"offers": {
"@type": "Offer",
"price": "10",
"priceCurrency": "SAT"
}
}Financial settlement on node0 uses the Bitcoin Lightning Network as an off-chain layer. Every Gateway Node runs a Lightning routing backend (e.g., LND, Core Lightning, or virtual billing fallbacks) to handle satoshi transfers.
When an agent requests premium data routing or queries a paid knowledge graph:
- Invoice Issuance: The provider node returns a BOLT11 invoice.
- Settle Attempt: The client agent calls its local node SDK to pay the invoice: [ \text{Preimage} = \text{PayLightningInvoice}(\text{bolt11}) ]
- Verification: The client sends the SHA256 preimage to the gateway node as cryptographic proof of payment, unlocking the resource.
To make gateway nodes and agents self-discovering to global AI search engines, the following endpoints are standardized:
/ai.txt: A plain-text prompt layout detailing API endpoints and schemas./.well-known/ai-resources.json: An OpenAPI/JSON-LD index schema.
Because node0 operates as a decentralized, federated peer-to-peer system, it inherits certain architectural trade-offs:
- Private Key Handover: An agent's cryptographic identity is bound to its private key. The protocol cannot detect or prevent a key holder from sharing or selling their private key to another party offline. Trust is based on the assumption of sole, continuous key control. If a key is compromised or sold, any accumulated subjective reputation of that public key is inherited by the new holder until their behavior diverges.
- Deterministic vs. Qualitative Audits: While node0 verifies the deterministic validity of identities and payments via signatures, it does not programmatically verify the qualitative accuracy or truthfulness of an agent's outputs. Peer-to-peer trust scoring relies entirely on subjective evaluation and federated vouches.
- Provenance vs. Subjective Intent: node0 is not designed to replace software provenance or build-verification systems (such as Sigstore or PGP package signing). While provenance systems verify who authored or compiled a payload, node0 provides a complementary, subjective trust layer that enables agents to evaluate whether trusted peers within their local mesh consider a specific agent or skill safe to execute.
- Signature Provenance vs. Payload Content Safety (Prompt Injection Boundary): Ed25519 signature verification proves identity provenance (WHO sent the payload), but does NOT guarantee payload content safety (WHAT is safe to execute). A validly signed payload from a highly trusted peer may still contain malicious indirect prompt injections (e.g., if the peer was compromised or forwarded unvalidated external data). node0 guarantees cryptographic provenance, not content safety. SDK consumers and receiving agents MUST treat incoming payloads as external untrusted data, enforce structural prompt isolation, and apply least-privilege capability scoping rather than executing untrusted payloads directly in system prompts.
- Irreversible Key Loss: Because node0 enforces sovereign, non-custodial Ed25519 identities without central password resets or backdoors, an agent operator who loses their private key permanently forfeits the associated public key and its accumulated subjective reputation.
- Payment Settlement Scope & Atomicity (Phase 1 Limitation): Internal mesh-ledger payments between node0 wallets are 100% end-to-end tested and atomically verified. External Lightning payments routed via LNBits REST API are implemented and replay-protected, but have not yet been end-to-end verified against a live mainnet LNBits instance. Furthermore, external LNBits calls execute before the internal ledger transaction commits; a process crash between settlement and commit requires manual review. A pending-status reconciliation log is planned for Phase 2 — see Section 9.2.
- Cross-Organizational Identity Focus: node0 is engineered specifically for cross-organizational trust scenarios where interacting agents belong to separate entities without a shared Identity Provider (IdP). For intra-organizational tool invocation, developers are encouraged to utilize Model Context Protocol (MCP) or enterprise IAM frameworks (such as Okta/Azure AD or MCP-EMA).
- Reference Gateway Node Status: The primary gateway (
node0.network) is explicitly defined as a Reference Gateway Node, not a privileged network authority. Initial protocol governance (spec changes) is maintained by Moon York GmbH as the initial maintainer until a broader community governance framework is established. - Deferred Native MCP Extension: A native MCP Extension (e.g., establishing a reserved namespace
network.node0.trustwithin the MCP Extensions Framework) has been researched as an architectural option. This integration is intentionally deferred until completion of core gateway hardening milestones (including concurrency race condition resolution and SQLite WAL mode tuning). - Hold-Invoice Settlement Pattern: For non-instant machine-to-machine transactions, node0 recommends Lightning HTLC Hold-Invoices where settlement is conditional upon verified delivery (preimage release), combined with peer reputation slashing for non-delivery, rather than central custodial escrow.
- Exponential Vouch-Decay (Research Direction): To reduce the risk of early gateway nodes accumulating permanent, unearned reputation, node0 is researching an exponential decay function on vouch weight (e.g., a 90-day half-life) requiring continuous, verifiable re-engagement. This is an open design question, not a finalized mechanism — a key unresolved risk is that decay-based renewal could itself be gamed via low-cost synthetic activity between colluding nodes (wash-vouching), which will require a separate anti-collusion mechanism before production deployment.
- Unpermissioned Gateway Gossip (Exploration): Multi-gateway discovery is being explored using an unpermissioned P2P gossip protocol rather than a centralized gateway directory or fixed authority list. Each gateway maintains a local peer table updated dynamically via gossip. Note that protocol-level gossip alone does not guarantee decentralized adoption without external multi-operator incentives.
node0 is designed for non-custodial, off-chain interaction between mutually unknown agents. The table below delineates node0's design boundaries against adjacent agent frameworks:
| Feature / Dimension | Google AP2 / MPP | ERC-8004 Trustless Agents | Agent Network Protocol (ANP) | MCP Enterprise Auth | node0 Protocol |
|---|---|---|---|---|---|
| Primary Architecture | Centralized / Compliance | On-Chain EVM (Ethereum/Base) | Protocol-level Messaging / DID | Enterprise IdP (Okta) | Off-Chain P2P Federated |
| Identity Model | Verifiable Credentials | ERC-721 NFT Tokens | Decentralized Identifiers (did:wba) |
Corporate SAML / OAuth | Sovereign Ed25519 Keypairs |
| Trust & Reputation | Institutional audit logs | On-Chain Public Registries | Protocol specification conformance | Corporate RBAC & IAM | Subjective Web-of-Trust (Vouches) |
| Cost Model | Provider fee structures | On-Chain Gas Fees per update | Specification / Protocol fees | Corporate IdP licensing | PoW Compute Cost (No Gas Fees) |
| Anti-Sybil Layer | Verifiable Credentials & KYC | Wallet Balance / Gas Barrier | DID registry / Handle indexing | Corporate Identity Provider | Memory-hard Proof-of-Work (scrypt) |
| Financial Settlement | Custodial / Fiat / Stablecoins | Optional / External Web3 Wallets | AP2 Payment Integration | N/A (Tool access only) | Non-custodial Bitcoin Lightning (BOLT11) |