OpenRouter solved a real problem. Developers don't want to manage API keys for ten different model providers. They want one endpoint, one billing relationship, and access to everything.
That insight was correct. The architecture wasn't.
OpenRouter doesn't just route requests. It decides what you're allowed to route to.
Which models are available? OpenRouter decides. Which providers can list? OpenRouter decides. Which workflows are permitted? OpenRouter decides. Which companies get access, which technologies get supported, which content policies apply — all filtered through one company's corporate rules.
That's not an API gateway. It's an editorial layer with an API attached.
When OpenRouter removes a model, you lose access. When they layer moderation on top of a provider's own policies — even for users who bring their own API keys — they're not protecting you. They're asserting control. Every model, every workflow, every provider on the platform exists because OpenRouter approved it. The moment they disapprove, it's gone.
This is the fundamental problem with centralized routing: the company that sits in the middle gets to shape the market that flows through it. Your access to AI runs through someone else's judgement about what's acceptable, what's profitable, and what's compliant with their own corporate obligations.
Beyond gatekeeping, the architecture has structural costs:
The tax compounds. OpenRouter charges 5.5% on every dollar of credit purchased. On $10K/month that's $6,600/year. On $100K/month, $66,000. You're paying a platform fee on top of inference costs, indefinitely, for the privilege of routing.
You can't see inside the black box. Which provider handled your request? Why was it routed there? What's the actual latency distribution? OpenRouter's routing decisions are opaque. You're trusting a company to optimize for your interests when their incentive is to optimize for their own margins.
The compliance surface is wrong. Every request passes through a third-party proxy. That's an extra hop your data takes, an extra company that handles it, an extra set of terms that govern it. For teams with GDPR, HIPAA, or data residency requirements, adding a centralized proxy between you and inference makes compliance harder, not easier.
It's a single point of failure. When OpenRouter goes down, every app built on it goes dark. Contractual SLAs don't change the topology.
Projects like Bittensor, Akash, and Render are doing important work. Bittensor is building an incentive layer for machine intelligence with real subnet economics and a growing ecosystem. Akash created a functioning decentralized compute marketplace. Render proved that distributed GPU networks can serve production workloads at scale. These projects pushed the industry forward and demonstrated that AI infrastructure doesn't have to live inside three cloud providers.
But they're solving a different problem. They're decentralizing compute — the raw GPU layer. Some, like Chutes on Bittensor, have built impressive OpenAI-compatible inference services with real production traffic. But even Chutes routes through a centralized API and requires a Bittensor wallet to register. You can't upload a specialized workflow to Akash and have buyers discover it through an open marketplace. These projects brought decentralized compute to production. The layer above — where anyone can publish any AI service and have it discovered, priced, and paid for peer-to-peer — is what's still missing.
More importantly, none of them are truly peer-to-peer at the application layer. They each require their own tokens, staking mechanisms, or marketplace structures. That's fine for what they do. But the gap they leave open is the one AntSeed fills: a permissionless network where anyone can serve any AI capability — not just raw compute — and anyone can consume it without navigating token economics.
AntSeed is a peer-to-peer network for AI services. Not just inference — expertise. Providers offer what they build. Buyers route requests to the best available provider. No central server sits between them. No one decides what's allowed.
The interface is OpenAI-compatible. If your app works with OpenRouter today, it works with AntSeed. One endpoint, all models, automatic routing. The developer experience is the same.
The architecture is completely different.
Permissionless on both sides. Anyone can join as a provider. Anyone can connect as a buyer. No application process, no partnership agreement, no platform approval. You run a node and you're in.
Three layers, built on each other. The foundation is the unstoppable P2P network — discovery via BitTorrent DHT, transport via WebRTC, no central point that can be shut down. On top sits an open marketplace where any AI service can be offered and proven through on-chain stats. On top of that emerge AI Agents — domain experts who package their knowledge as always-on services. A lawyer's contract expertise available at 3am. A security researcher's threat model, queryable by anyone. A trading analyst running 24/7, earning per delivery.
AI Agents are the unit of value on the network. You wrap your expertise in AI, set your price, and the network handles discovery, payments, and reputation. How you deliver is your business — pick any model, any workflow, any stack. The protocol only measures the quality of what comes back.
Direct settlement, minimal fees. Buyers pay providers directly — in USDC or by card. A 2% protocol fee is distributed back to the network, not extracted by a platform. Providers set their own prices. Markets clear through open competition.
Reputation is on-chain and provider-sovereign. Every delivery builds a track record that belongs to your wallet, not a platform that can revoke it. A provider with thousands of verified deliveries charges more than a new entrant. That premium is earned through work, and it compounds.
Privacy by architecture. There is no central server to log requests. No accounts, no logging. TEE-secured providers where not even the operator sees your data. This isn't a privacy policy — it's a consequence of peer-to-peer transport.
Resilience without SLAs. If a provider goes offline, the network routes around it automatically. There's no central point that can fail. Uptime is a structural property of the network, not a contractual promise from a company.
AntSeed's protocol has five layers, each handling a piece of what centralized gateways do behind closed doors:
Discovery uses a BitTorrent-style DHT. Providers announce their capabilities — models, skills, agents, pricing, capacity, latency. Buyers query the DHT to find providers that match their needs. No central registry required.
Transport runs on WebRTC data channels with TCP fallback. Connections are direct, peer-to-peer, with secp256k1/EIP-191 authentication. Every connection is cryptographically verified.
Metering tracks token usage with provider-signed receipts. Each request generates a receipt with exact token counts, costs, and a cryptographic signature. Both sides have proof of what happened.
Payments settle in USDC through on-chain escrow on Base, or via card through integrated fiat on-ramps. Bilateral payment channels between each buyer-seller pair. Disputes resolve automatically within defined thresholds. No invoicing, no billing cycles.
Reputation aggregates real performance data — success rates, latency percentiles, token accuracy, uptime — recorded as on-chain stats. Any buyer can build their own reputation and access rules on top. The best providers earn more traffic because the data proves they deserve it.
| OpenRouter | Decentralized Compute | AntSeed | |
|---|---|---|---|
| Architecture | Centralized gateway | Blockchain + subnets | Peer-to-peer |
| What it routes | Model inference | Raw compute | AI services + expertise |
| Permission to join | Company approval | Stake tokens | None required |
| What you can serve | What they allow | What fits their framework | Anything |
| API compatibility | OpenAI-compatible | Custom protocols | OpenAI-compatible |
| Fees | 5.5% (extracted) | Token economics | 2% (returned to network) |
| Payment methods | Card | Crypto wallets + tokens | USDC or Card |
| Content policy | Platform-enforced | Varies | Provider-level |
| Data privacy | Third-party proxy | Varies | P2P, no intermediary |
| Single point of failure | Yes | No | No |
AntSeed is for people who care about having the option to choose. Not a curated menu of models that one company approved — but the full variety of what providers actually build, ranked by reputation earned through real deliveries.
It's for people who care about privacy — not as a feature toggle, but as a structural property of the network they use. No accounts, no logging, no third-party proxy sitting between you and inference.
It's for providers who want to monetize what they know without asking anyone for permission. Wrap your expertise in AI, set your price, build a reputation that compounds with every delivery. The network handles the rest.
And it's for agents — software that doesn't care about brands or polished UIs, that just needs the best available service at the best price with verifiable quality. On those axes, an open P2P network wins every time.
Permissionless AI. Anyone can serve. Anyone can build. Anyone can earn.
Is AntSeed free to use? There's a 2% protocol fee per request, distributed back to the network. No subscription, no account, no platform rake on top of that.
Does AntSeed work with my existing tools? Yes. Claude Code, Cursor, Aider, Continue.dev, and any app using the OpenAI SDK work without modification — just point them at AntSeed instead of your current endpoint.
How is AntSeed different from Bittensor for AI inference? Bittensor decentralizes the compute layer with its own subnet economy and token. AntSeed is a peer-to-peer layer for AI services and expertise — OpenAI-compatible, no separate token required to participate as a buyer or provider.
Can I use AntSeed without crypto knowledge? Yes. Providers and buyers can pay and settle in USDC or by card. The protocol handles the on-chain mechanics automatically.
Most decentralized compute projects sidestep this. They use self-reported metrics (trivially gameable), trusted validators (re-introducing centralization), or optimistic assumptions with dispute windows (which require honest majorities). These are reasonable tradeoffs, but they're not proofs. They're social mechanisms dressed up as cryptographic ones.
AntSeed's answer is the metadataHash — a hash of delivery metrics that the buyer signs into every payment authorization. When the seller wants to settle more funds, they must submit a signature that includes this hash. The hash covers what was actually delivered: tokens in, tokens out, average latency, number of requests. The seller can't get paid without presenting proof of what the buyer received. That proof is the metadataHash.
Every payment authorization (SpendingAuth) the buyer signs contains three fields:
hash(cumulativeInputTokens, cumulativeOutputTokens, averageLatencyMs, requestCount)The first two fields handle payment. The third is the proof of prior delivery.
By signing over a hash of cumulative delivery metrics, the buyer cryptographically commits to what they observed. How many tokens went in. How many came out. The average response time. How many requests were served. This isn't self-reported by the seller — it's attested by the buyer, the party who received the service.
When the seller calls settle() or close() to claim funds, they submit the buyer's latest SpendingAuth. The contract verifies the signature, charges the amount, and unpacks the metadata into the on-chain stats system. The seller cannot settle without a valid buyer signature, and that signature includes delivery metrics. Payment and proof of delivery are inseparable — they're the same signature.
The amount is cumulative and monotonically increasing. After request 1 costs $0.003, the buyer signs cumulativeAmount = 3000. After request 2 costs another $0.005, the buyer signs cumulativeAmount = 8000. Each signature supersedes the previous one. The seller only needs the latest to claim everything owed — and that latest signature always carries the most up-to-date delivery metrics.
Before any of this happens, buyer and seller need to agree on terms. Each side has its own constraints, and the protocol resolves them without a central matchmaker.
When a buyer sends a request without an active session, the seller responds with 402 and publishes its requirements:
The buyer has its own caps, configured by the operator:
The negotiation is simple: if the seller's minimum exceeds the buyer's per-request cap, the buyer rejects. Otherwise, the buyer caps the seller's suggested amount at its own maximum reserve and signs a ReserveAuth to open the session.
This means both sides have veto power. A seller can set a minimum that prices out low-budget buyers. A buyer can cap exposure regardless of what the seller suggests. Neither side can force the other into unfavorable terms. The market clears through open competition — sellers who price too high lose traffic, buyers who cap too low can't access premium services.
After each response, the buyer calculates the actual cost. The seller includes token counts and cost in response headers. When those headers are missing — which happens with some upstream providers — the buyer estimates output tokens from the response body size (roughly 4 bytes per token) and calculates cost from the seller's published rates.
The buyer then signs a new SpendingAuth with the updated cumulative amount and metadata, and sends it to the seller before the next request. The seller verifies the signature locally — no on-chain call — and serves the next request.
This creates a rolling bilateral agreement. At any point, the seller holds a single latest SpendingAuth covering all work done so far. If the buyer understates consumption, the seller simply stops serving. If the buyer overstates, they're overpaying — no buyer has an incentive to do this. Honest reporting is the equilibrium.
When the seller calls settle() or close() on the AntseedChannels contract, they submit the buyer's latest SpendingAuth signature. The contract:
AntseedStatsStep 4 is the proof path for optional metadata aggregation. The AntseedStats contract can contain delivery metrics attested by the buyer's own signature. No oracle reported these numbers. No validator observed them. The buyer signed them because they were there when the service was delivered.
The core counters that accumulate per seller in AntseedChannels:
If AntseedStats is configured, it can additionally aggregate:
These values are keyed by ERC-8004 agentId. AntseedStats accepts writes only from addresses granted its writer role, and the deployed flow grants that role to AntseedChannels.
When the buyer's cumulative spend approaches the session's maxAmount ceiling, the seller sends a NeedAuth message indicating how much more authorization is required. The buyer can sign a new ReserveAuth with additional funds, extending the session seamlessly.
If the buyer doesn't top up, the seller finishes the current request and returns 402 on the next one. The buyer's client automatically negotiates a new session — signing a fresh ReserveAuth against their deposit balance.
From the user's perspective, this is invisible. From the protocol's perspective, it creates natural settlement checkpoints. Each settlement can commit metadata to the chain, building the on-chain record incrementally rather than in one shot at session end.
If the seller disappears mid-session, the buyer's funds are locked in a reservation with no one to settle. The protocol handles this with two permissionless functions:
requestTimeout() can be called by anyone after the session's deadline passes. After a 15-minute grace period, withdraw() releases the locked funds back to the buyer's deposit and records a ghost mark on the seller's stats.
Why a full refund? Because the seller cannot unilaterally prove delivery. Only the buyer's signed SpendingAuth can authorize charges. If the seller had a recent SpendingAuth, they should have settled before the deadline. If they didn't — if you can't prove it, you don't get paid.
These stats are public, on-chain, and queryable by anyone — not just AntSeed clients, but any smart contract, any indexer, any agent framework that reads the chain. And because they're tied to the seller's ERC-8004 identity, they're portable. A seller's track record belongs to their wallet, not to a platform that can revoke it.
This matters most for agentic workflows. When an autonomous agent needs AI services, it can't rely on subjective reviews or curated lists. It needs hard data:
An agent can encode its own routing policy on top of these stats. "Only route to sellers with 100+ sessions, ghost rate under 5%, and average latency under 2 seconds." That policy runs against public on-chain data. No API key needed, no platform approval, no trust required.
The quality signal is a byproduct of payment. You don't need to rate your provider — the fact that you paid them and they delivered is the data point. The fact that they ghosted and you got your money back is equally informative. Every settlement adds signal, and over time the stats converge on a clear picture of each seller's reliability.
The metadataHash is what closes the loop between payment and accountability. Without it, settlement would just prove that money moved. With it, settlement proves what was delivered — and that proof is signed by the buyer, not claimed by the seller.
No separate reporting system. No oracles. No dispute games. The seller presents the buyer's signed metadataHash to get paid, the delivery record writes itself, and an open network of verifiable stats emerges from the payments themselves.
AntSeed sidesteps this entirely. The key that runs on your node never touches real funds. The wallet that holds your money never touches the node. They are cryptographically unrelated. Compromising one does not compromise the other.
Every AntSeed node has a derived EVM keypair — its "hot wallet." But calling it a wallet is misleading, because it never holds funds. It exists for one purpose: signing EIP-712 payment authorizations.
When the node receives a 402 Payment Required response from a seller, the hot wallet signs a ReserveAuth (authorizing a session budget) and a SpendingAuth (authorizing cumulative spend per request). That's it. It cannot transfer tokens. It cannot call arbitrary contracts. It cannot withdraw funds. The only thing the hot wallet's signatures can do is authorize a specific seller to draw from a pre-funded deposit balance — within strict caps.
Those caps are tight:
Even if an attacker steals the hot wallet's private key, the worst they can do is sign authorizations against the existing deposit balance in $0.10 increments. They cannot exceed the deposit. They cannot access the funding wallet. They cannot change the caps.
The funding wallet is completely separate. It can be a hardware wallet, a multisig, a smart contract wallet — anything the user controls. It interacts with the AntseedDeposits contract by calling depositFor(hotWalletAddress, amount), which credits the hot wallet's deposit balance with USDC.
After that, the funding wallet has no further role. It doesn't need to stay connected. It doesn't need to approve transactions. It doesn't even need to be the same wallet every time — anyone can call depositFor() to fund a buyer's account.
The deposit balance itself has a credit limit that starts at $50 and grows based on usage history — how many sellers the buyer has transacted with, how long they've been active, how much feedback they've received. The hard cap is $500. This means even if the hot wallet's deposit balance is fully compromised, the maximum loss is bounded by the credit limit — not by the funding wallet's total holdings.
Funding Wallet AntseedDeposits Hot Wallet (Node)
(Ledger, Safe, any wallet) (on-chain custody) (signing key only)
│ │ │
│── depositFor(hotWallet, $50) ───>│ │
│ [USDC transferred] │ │
│ │ balance: $50 │
│ │ │
│ [funding wallet disconnects] │ │
│ │ │
│ │<── ReserveAuth sig ───────┤
│ │ [locks $1 for seller] │
│ │ │
│ │<── SpendingAuth sig ──────┤
│ │ [authorizes $0.10] │
│ │ │
│ │ balance: $49 │
│ │ reserved: $1 │
The funding wallet is offline after depositing. The hot wallet signs authorizations but never moves money. The deposits contract enforces the limits. Three independent components, each with a narrow responsibility.
In most P2P payment networks, the node key is the wallet. If you want unattended operation — an AI agent that pays for compute without human approval — you need to fund that key. The more you fund it, the more useful it is. The more you fund it, the more you lose when it's compromised.
AntSeed breaks this coupling. The hot wallet is useful at zero balance — it just needs a deposit credited to it. An operator can fund $20 into the deposit, let the agent run for weeks, and top up when the balance gets low. The funding wallet's private key sits on a Ledger in a drawer. The agent's signing key runs on an EC2 instance. If the instance is compromised, the attacker gets access to at most $20 (or whatever the current deposit balance is). The Ledger is untouched.
For sellers, the separation works similarly. The seller's hot wallet signs metering receipts and calls reserve() on-chain. Earned revenue accumulates in the AntseedDeposits contract as seller earnings — claimable to any address the seller specifies, not automatically to the hot wallet. A compromised seller node cannot redirect earnings to an attacker's address.
Every AntSeed node has a single secp256k1 private key. The corresponding EVM address is the node's PeerId on the network and its on-chain signing identity. There is no derivation step and no two-key system.
This one key signs everything: peer authentication handshakes (EIP-191 personal_sign with domain tags), metadata announcements, metering receipts, and EIP-712 payment messages (ReserveAuth, SpendingAuth). Verification always uses ecrecover to confirm the signer matches the expected EVM address.
One key, one identity, one address across P2P and on-chain. But it never holds funds — that's what the funding wallet and AntseedDeposits are for.
The desktop app encrypts the secp256k1 private key at rest using Electron's safeStorage API, which delegates to the OS keychain — macOS Keychain, Windows Credential Manager, or Linux libsecret. The key is decrypted into memory only when needed for signing operations.
The funding wallet never touches the application. A user can deposit into AntseedDeposits from a Ledger, a Trezor, a Safe multisig, or any other wallet. The deposit is a standard ERC-20 approval + depositFor() call that can be executed from any interface. The application has no knowledge of the funding wallet's private key and no mechanism to request it.
Hot wallets — the common approach in decentralized networks. A single key holds funds and signs transactions. Node compromise means full fund exposure. Operators mitigate by keeping balances low, but this requires constant manual rebalancing.
Custodial solutions — a third party manages keys on behalf of the operator. Solves the hot wallet problem by introducing a trust dependency. The custodian becomes a single point of failure.
ERC-4337 session keys — the closest parallel. Session keys delegate limited transaction authority from a smart contract wallet. AntSeed's hot wallet serves a similar function but is purpose-built for metered AI payments: each authorization is scoped to a specific seller, capped at a specific amount, and includes delivery metadata. The key difference is that AntSeed's hot wallet is not a delegate of the funding wallet — there is no on-chain delegation relationship between them. The funding wallet deposits on the hot wallet's behalf, but the hot wallet cannot initiate transactions from the funding wallet under any circumstances.
The hot wallet is a signing key. It authorizes spend from a pre-funded deposit, within caps, for specific sellers, with expiration. It never holds funds, never moves tokens, never touches the funding wallet.
The funding wallet deposits money and walks away. It can be cold storage. It can be a multisig requiring 3-of-5 signatures. It doesn't matter — the node never needs it after the deposit.
This is what makes unattended AI agents practical on a P2P payment network. The agent signs authorizations autonomously. The human funds the deposit when they choose to. Compromise of the agent costs the deposit balance. Compromise of the deposit balance doesn't touch the funding wallet.
]]>All of these give 402 a mechanism. They differ in architecture — specifically, in who sits between buyer and seller, and whether that intermediary is required.
AntSeed uses 402 as the trigger for fully decentralized payment negotiation between peers. No payment gateway, no relay, no facilitator. The entire flow — from the initial 402 response to the on-chain reserve to the retried request — happens over the same peer connection that carries the actual AI traffic.
A buyer connects to a seller peer and sends a request. If no payment session exists for this buyer-seller pair, the seller responds with HTTP 402 and a payment requirements message containing the terms:
{
"sellerEvmAddr": "0x...",
"minBudgetPerRequest": "10000",
"suggestedAmount": "100000"
}
minBudgetPerRequest is the minimum the seller needs per request. suggestedAmount is what the seller recommends for uninterrupted service. Optionally, the seller includes per-token pricing (inputUsdPerMillion, cachedInputUsdPerMillion, outputUsdPerMillion) so the buyer can estimate costs before committing.
This message rides the same connection as every other message in the protocol. The request ID ties the payment requirement back to the original request, so the buyer knows exactly which call triggered the negotiation.
This is the core of the design. AntSeed uses two distinct EIP-712 signatures to separate the concerns of reserving funds and authorizing spend:
When a buyer agrees to the seller's terms, it signs a ReserveAuth — a one-time EIP-712 signature that sets the budget ceiling for the session:
The buyer sends this signature to the seller, who submits it on-chain by calling reserve() on the AntseedChannels contract. This locks maxAmount of the buyer's deposited USDC for this specific seller. The transaction confirms on Base L2 in 2-3 seconds. Once confirmed, the seller sends an acknowledgment and the buyer retries the original request.
This is the only on-chain transaction in the entire flow. Everything after this is off-chain.
On every request, the buyer signs a SpendingAuth — a lightweight EIP-712 signature that authorizes a cumulative spend amount:
The key insight is cumulative. The buyer doesn't authorize each request individually. Instead, each SpendingAuth says "I authorize you to keep up to X total from everything you've served me so far." The amount only goes up. The seller verifies the signature locally — no on-chain call needed — and serves the request.
The metadataHash ties each authorization to actual delivery. It's a hash of what was delivered (token counts, latency, number of requests), creating a cryptographic link between payment and service. This is what makes on-chain reputation possible — settlement carries proof of what was actually delivered.
Buyer Seller Deposits Contract
│ │ │
│ [deposit USDC — once] │ │
│─── deposit() ──────────────────────────────────────────────────>│
│ │ │
├── Request ──────────────────────>│ │
│<── 402 + PaymentRequired ────────┤ │
│ │ │
│ [sign ReserveAuth] │ │
│ [sign SpendingAuth #1] │ │
│ │ │
├── ReserveAuth + SpendingAuth ───>│ │
│ ├── reserve() ───────────────>│
│ │ [locks from deposit] │
│ │<── confirmed ───────────────┤
│<── Acknowledged ─────────────────┤ │
│ │ │
├── Request (retry) ──────────────>│ [serves normally] │
│<── Response ─────────────────────┤ │
│ │ │
├── Request + SpendingAuth #2 ────>│ [verify sig, serve] │
│<── Response ─────────────────────┤ │
│ │ │
├── Request + SpendingAuth #3 ────>│ [verify sig, serve] │
│<── Response ─────────────────────┤ │
The buyer's only on-chain transaction is the initial deposit — which funds all future sessions with any seller. Opening a session is the seller's transaction, locking funds from the buyer's existing balance. After that, unlimited requests with off-chain signature verification. The seller settles on-chain when the session ends — calling settle() or close() with the buyer's latest SpendingAuth signature.
Here's something x402 and MPP can't do: payment negotiation on the same transport as the actual traffic, with no additional infrastructure.
AntSeed peers are already connected over a WebRTC DataChannel for proxying AI requests and responses. The payment flow — 402 trigger, ReserveAuth, SpendingAuth, acknowledgments — rides that same DataChannel. The protocol multiplexes payment messages alongside proxy traffic using a frame-level type byte. Payment messages are just another message type on an open connection.
This means there is no payment service to deploy. No WebSocket sidecar for payment negotiation. No HTTP callbacks to a facilitator. No second connection to establish. When a buyer hits a 402, the entire negotiation — signing, sending the authorization, waiting for the on-chain reserve, receiving the acknowledgment, retrying the request — happens on the connection that's already open.
The transport cost of payment negotiation is literally zero. The only added latency is the on-chain reserve() confirmation (2-3 seconds on Base), paid once per session. After that, SpendingAuth signatures flow alongside proxy traffic as just another message on the mux. A streaming AI response might produce dozens of response chunks interleaved with a SpendingAuth — the mux handles this naturally.
x402 requires an HTTP round-trip to a facilitator for every paid request. MPP requires communication with Stripe's infrastructure. AntSeed requires nothing beyond the peer connection you already have.
When the buyer's cumulative spend approaches the maxAmount ceiling, the seller sends a NeedAuth message indicating how much more authorization is required. The buyer can sign a new ReserveAuth with additional funds, extending the session without interruption. If the buyer doesn't top up, the seller finishes the current request but will 402 the next one.
Auto mode handles everything internally. The buyer node checks its on-chain deposit balance, signs both ReserveAuth and SpendingAuth using its embedded wallet, and retries the request. The application never sees the 402 — it just gets a response, slightly delayed on the first request while the on-chain reserve confirms.
Manual mode lets the user approve spending explicitly. The 402 and payment terms propagate to the application. In the desktop app, the user sees an approval card showing the seller's address, pricing, and suggested amount. On approval, the app signs the authorization using the user's wallet and attaches it to the retry request. The node extracts it before proxying — from the seller's perspective, the flow is identical.
Both modes produce the same EIP-712 signatures, go through the same payment channel, and result in the same on-chain reserve() call. The seller doesn't know or care which mode the buyer is using.
Three protocols now give HTTP 402 a concrete mechanism. They solve different problems with different architectural tradeoffs.
x402 introduces a facilitator between buyer and seller. The buyer constructs a payment payload and sends it with the request. The seller forwards it to a facilitator (Coinbase, or a third-party implementation) for verification and settlement.
This is practical for adding payments to existing HTTP APIs — the facilitator abstracts away blockchain complexity. The tradeoff is the intermediary itself: it holds transient custody during settlement, must remain available for every paid request, and represents a single point of failure. For a P2P network with no central operator, it's a structural mismatch.
The Machine Payments Protocol uses pre-authorized sessions — similar to AntSeed's ReserveAuth in spirit, and a direct inspiration for our design. The buyer pre-authorizes a spending limit, and individual requests settle automatically against that session. MPP is chain-agnostic and settlement is batched, amortizing on-chain costs across requests.
AntSeed builds on this foundation with two additions. First, the funding model: in MPP, the buyer executes an on-chain transaction to fund each new session. In AntSeed, the buyer deposits USDC once into a deposits contract, and every session after that draws from that balance — the seller calls reserve() using the buyer's signed authorization, so the buyer never needs to send another transaction. This matters for machine-to-machine payments where the buyer is an agent, not a human clicking "approve" in a wallet.
Second, what settlement proves. MPP confirms that money moved. AntSeed's SpendingAuth carries a metadataHash — a hash of cumulative delivery metrics — so settlement simultaneously proves what was delivered and what was paid.
No facilitator, no per-session buyer transaction. The buyer deposits USDC once. The seller calls reserve() using the buyer's signed authorization — locking funds from the existing deposit. After that, every request is just a local signature check. Settlement happens when the session ends, carrying cumulative delivery metrics on-chain.
| x402 | MPP | AntSeed | |
|---|---|---|---|
| Intermediary | Facilitator (Coinbase) | Stripe + Tempo | None (smart contract only) |
| Payment transport | HTTP headers + facilitator round-trip | HTTP headers + Stripe/Tempo API | Same WebRTC DataChannel as traffic |
| Buyer transaction to open session | Per-request | Per-session | None (seller reserves from buyer's deposit) |
| On-chain settlement | 1 tx per request | Batched (amortized) | Batched (amortized) |
| Session model | Per-request | Pre-authorized session | ReserveAuth ceiling + cumulative SpendingAuth |
| Chain dependency | Multi-chain | Chain-agnostic | Any EVM chain with USDC |
| Proof of delivery | None | None | Built-in (metadataHash in SpendingAuth) |
Both MPP and AntSeed amortize on-chain costs by batching settlement — individual requests are authorized off-chain, and the cumulative result settles on-chain. The architectural distinctions are in the other rows. The deposit model means the buyer never needs to be online for a wallet transaction — critical for autonomous agents that consume AI services without human intervention. The multiplexed transport means no additional infrastructure. And the metadataHash in every SpendingAuth creates a cryptographic link between payment and delivery, enabling on-chain reputation to emerge directly from settlement without a separate reporting system.
Payment negotiation adds zero infrastructure overhead. There's no payment service to deploy, no WebSocket server to maintain, no message broker to scale. Payment flows over the same peer connection as everything else.
When a buyer connects to a new seller for the first time, the 402 flow adds a one-time 2-3 second delay for the on-chain reserve. Every subsequent request is served at full speed with only a local signature verification — sub-millisecond.
HTTP 402 now has competing mechanisms. x402 adds a facilitator. MPP pioneered the pre-authorized session model that inspired our design. AntSeed builds on that with deposit-based funding, multiplexed transport, and delivery proof baked into every signature.
]]>Claude wants your email. ChatGPT wants your phone number. DeepSeek wants to know who you are. Even the "open" models require an API key tied to a billing account. Before you can ask a single question, you've handed over your identity.
For a growing number of users, that's the deal-breaker.
The reasons vary, but they're all legitimate.
Professionals with confidentiality requirements -- lawyers, journalists, therapists, security researchers. If your work involves sensitive information, you can't guarantee that an AI company's terms of service, data retention policies, or response to a government subpoena won't compromise your clients or sources.
People in high-surveillance environments -- using AI with an account attached creates a record. In some countries and industries, that record has consequences.
Developers and researchers -- you want to benchmark models, test prompts, explore capabilities. You don't want your experimental queries attached to an account that gets analyzed and fed back into training.
People who just value their privacy -- you don't owe anyone a justification for not wanting a corporation to read your thoughts.
The options that exist today fall into a few categories, each with real limitations.
Local models (Ollama, llama.cpp) give you complete privacy. Nothing leaves your machine. But running Llama 4 or anything comparable locally requires serious hardware. Most people don't have it, and even those who do can't run frontier closed-source models like Claude or GPT locally at all.
Privacy-first AI products are a genuine improvement over ChatGPT. No conversation logging, strong privacy defaults. But they still require an account, still run on centralized infrastructure, and are limited to their own curated model selection.
API access gives you more control, but every API key is tied to a billing account. Your usage is logged. You're still identified.
None of these give you access to the full range of frontier models -- Claude, DeepSeek, Llama, Qwen -- without any account, without any identity attached.
AntSeed is a peer-to-peer network where providers offer AI inference and buyers consume it, without either side needing to identify themselves to a central authority.
When you connect to AntSeed:
No account required. You install the client and connect. Nothing to sign up for, no email, no phone number.
Providers never know who you are. Your requests reach providers without revealing your identity. The network handles routing anonymously by design, not as a policy promise.
You get access to every model on the network. Claude, DeepSeek R1, Llama 4, Qwen, and more. Whatever providers have made available. One connection, all models.
The anonymity isn't a feature that could be turned off in a future terms of service update. It's structural, a consequence of how peer-to-peer routing works.
This one surprises people. Claude is Anthropic's model. How can you access it without an Anthropic account?
Through AntSeed, providers who have legitimate API access to Claude can offer it on the network. You pay the provider directly (in USDC, at rates set by open competition), and your request reaches Claude without Anthropic ever knowing who you are.
The provider knows a request came in. They don't know it came from you specifically. And Anthropic sees API traffic from the provider's account, not yours.
This isn't circumventing anything. It's the same model as any API reseller, except the reselling happens on an open P2P network with transparent pricing and verifiable reputation, rather than through a centralized middleman.
DeepSeek's models, especially R1, their reasoning model, are among the best available for complex analytical tasks. But DeepSeek is a Chinese company, and for many users that raises legitimate data sovereignty questions.
On AntSeed, you can access DeepSeek R1 through providers running the model locally or through API access, without your requests ever touching DeepSeek's servers directly. The provider you route to handles the upstream relationship. You stay anonymous throughout.
Meta's Llama models are open-weight. Anyone can download and run them. That means AntSeed's network includes many self-hosted Llama operators: developers with good hardware, inference farms in low-cost regions, edge nodes optimized for speed.
For Llama, the privacy story is strongest. Providers running it locally means your prompts never reach any third-party API at all. The model runs on their hardware, the response comes back to you, and the whole exchange happens without any company's servers involved.
For users who need the strongest possible guarantee -- journalists working with sensitive sources, legal professionals, security researchers -- AntSeed supports Trusted Execution Environment (TEE) providers.
TEE nodes run AI inference inside secure hardware enclaves. Cryptographic attestation proves that the code running inside hasn't been tampered with and that the operator cannot access the plaintext of your requests. Not "we promise we don't log." Mathematical proof.
This is where AntSeed opens up something no centralized platform can offer.
Centralized AI products apply content policies uniformly. Not because the underlying models require it, but because the company running the platform does. The same base model that refuses a question on ChatGPT will answer it freely when run without those guardrails.
On AntSeed, providers set their own terms. That means the network can support model variants that simply can't exist on centralized platforms:
Dolphin (fine-tuned on Mistral and Llama) -- one of the most widely used uncensored models, built for full prompt adherence with no refusals.
Hermes (NousResearch) -- instruction-following model with strong reasoning and minimal filtering.
WizardLM -- fine-tuned for complex instruction following, popular for creative and research tasks.
Custom fine-tunes -- domain-specific models trained for security research, red-teaming, medical, legal, or creative use cases that mainstream platforms won't touch.
Base models -- raw, uninstruction-tuned weights for researchers who need direct model access without any RLHF layer.
Anyone with a GPU can run these models and become a provider on AntSeed. The barrier is low: download the model weights, run the AntSeed node software, set your pricing and capabilities. The network handles discovery, routing, and payment automatically.
A developer with a gaming PC running Dolphin or Hermes locally can earn USDC for inference that would be refused or banned on every major platform. Their cost is electricity. Their market is every AntSeed user who needs unrestricted model access.
TEE nodes and uncensored models often go together. Maximum privacy and maximum model freedom in the same provider. For users in sensitive professions or with legitimate research needs, that combination doesn't exist anywhere else.
Getting started takes one command. Your existing AI tools -- Cursor, Claude Desktop, or anything that supports OpenAI-compatible APIs -- work without modification. You point them at AntSeed instead of the original endpoint, and the network handles the rest.
You choose your providers based on the model you want, the price you're willing to pay, and the privacy level you need. The network shows you reputation scores, pricing, and capabilities. You pick. The rest is automatic.
No account. No identity. Just the model.
]]>BitTorrent was faster, cheaper, and more resilient than any streaming service. It didn't matter. Spotify won because humans wanted a clean interface, a monthly subscription, and someone to handle the complexity. P2P required setup, patience, and tolerance for rough edges. Most people weren't willing to trade convenience for control.
That calculus just flipped. Not because humans changed — because the next wave of AI consumers aren't human.
When the user is a person, centralized wins almost every time.
People don't want to think about which peer to connect to. They don't want to manage reputation scores or handle failed connections. They want to open an app and have it work. Centralized services are better at that. A well-funded company with a polished product will beat a distributed protocol for human users, every time, because humans optimize for experience.
That's why BitTorrent lost to Netflix. Not on technical merit — Netflix is objectively more fragile, more expensive to run, and more dependent on corporate relationships. But Netflix is frictionless for a human sitting on their couch. BitTorrent isn't. Human wins to centralized.
The same pattern played out in AI. OpenAI built a great product. Anthropic built a great product. They won because a developer with an API key gets results in minutes, without understanding anything about the infrastructure underneath.
Agents don't have couches. They don't care about interfaces.
An autonomous agent running in production doesn't evaluate infrastructure by how pleasant it feels to use. It evaluates it by whether it's always available, whether costs are predictable, whether it can pay autonomously, and whether it can route to the best provider for each specific task.
On every one of those dimensions, P2P is the better answer — and centralized services are structurally incapable of matching it.
Agents need uptime, not UX. A centralized provider has maintenance windows, rate limits, and outages. When a human hits a rate limit, they wait. When an agent hits one, the task fails. P2P routes around unavailability automatically — if one provider is overloaded, the next one picks up the request. Always on isn't a feature. It's a structural property of the network.
Agents need to pay without humans in the loop. Every centralized AI API requires a billing account — a credit card, an email, a human identity. That model breaks completely for autonomous agents. An agent can't renew a subscription or enter a CAPTCHA. AntSeed settles payments in USDC directly between the agent and the provider. The agent holds a wallet, selects a provider, pays per request. No human involved, ever.
Agents can use reputation, not brand recognition. Humans choose providers based on name recognition and marketing. Agents don't have brand preferences. They can evaluate providers on actual performance: latency, uptime history, cost per token, model quality scores. P2P networks surface this data structurally — every provider builds a reputation record that any agent can read and act on. The best providers win more traffic. The network self-optimizes in a way that centralized markets never can.
Agents benefit from open competition on price. When you lock into one provider, you pay whatever they charge. When an agent routes across a P2P network, providers compete for every request. The market sets the price. A gaming PC running DeepSeek at home competes on the same network as a professional inference farm. The agent picks the best combination of price, speed, and quality for the task. No negotiation, no contracts, just market prices clearing in real time.
The most profound consequence of the agent world isn't that individual agents work differently. It's that agents can hire other agents.
A research agent needs a summarization agent. A coding agent needs a security-review agent. A customer-service agent needs a translation agent. In the centralized world, these capabilities are walled gardens — each provider offers what they offer, and integrations are custom, bilateral, maintained by humans.
In a P2P network, any agent can discover any other agent on the network and transact with them directly. A research agent queries the network for summarization providers, selects one based on reputation and price, sends a request, and pays in the same transaction. No API partnership required. No human negotiating terms. Just two agents, a protocol, and a price.
This is agent-to-agent commerce. It can't exist on centralized infrastructure because centralized infrastructure requires human accounts, human agreements, and human-managed integrations. P2P enables it natively — any participant can be both a buyer and a provider, simultaneously, without anyone's permission.
The primary consumers of AI infrastructure are shifting from humans to agents — and agents make the tradeoff in the opposite direction.
For humans: centralized wins on convenience. For agents: P2P wins on everything that matters.
The infrastructure that seemed like the obviously right choice for a decade turns out to have been optimized for the wrong user. Agents don't need Spotify. They need BitTorrent.
AntSeed is building the BitTorrent for AI — a protocol, not a product. Open to any provider. Accessible to any agent. Priced by competition, not by rate cards. Always on, because the network doesn't have a single point to fail.
]]>That's not a small thing. Before Venice, "private AI" was a talking point. After Venice, it's a proven market with hundreds of thousands of users who vote with their attention every day.
We built AntSeed because we think that market deserves infrastructure to match its ambition.
Venice made a bet that most of the industry ignored: that privacy isn't a feature, it's a requirement for a whole class of users.
Professionals with confidentiality obligations. People in countries where surveillance is a daily reality. Developers who don't want their codebase indexed. Creatives who don't want their ideas harvested. All of them were underserved by ChatGPT, Gemini, and the rest of the mainstream stack.
Venice built for those users: open-source models, no conversation logging, a genuine commitment to user privacy. They were right. The demand was real, it was large, and it isn't going away.
The vision was correct. The execution was impressive. What comes next is infrastructure.
The internet didn't become the internet because one company built a great product. It became the internet when email became SMTP, when the web became HTTP, when file sharing became BitTorrent.
In each case, the transition from product to protocol meant:
AI is at the product stage. The protocol stage hasn't happened yet.
AntSeed is a peer-to-peer network for AI services. Providers, anyone running open-source models, frontier APIs, or specialized agents, join the network and offer their capabilities. Buyers connect and get access to all of them through a single interface, with automatic routing by price, speed, or privacy requirements.
There is no AntSeed server between buyer and provider. No central registry. No partnership required to participate.
The privacy properties aren't a promise. They're a consequence of the architecture. When there's no central server, there's nothing to log. Providers never learn who is sending requests. For the strongest guarantee, TEE nodes run with cryptographic attestation, mathematical proof that not even the operator can read the prompts.
Anonymity is the default. Every request through AntSeed reaches the provider without revealing who the buyer is. The network enforces it structurally, not as a policy.
Here's where the story gets interesting for Venice and their users.
Venice's infrastructure, their models, their privacy stack, their proven reliability, could become a provider on AntSeed's network. Venice users who love Venice's interface and model selection would still have it. But buyers routing through AntSeed could choose Venice as their preferred provider, automatically, based on reputation and quality.
In this model, Venice doesn't compete with AntSeed. Venice wins because of AntSeed. Their reputation and quality earn them more routing from a much larger pool of buyers than they could reach as a standalone product.
This is what protocol-level competition looks like. The best providers win more traffic because the network can measure and reward quality. Not because they locked users in, because they earned it.
Beyond established players like Venice, the protocol enables provider types that couldn't viably exist as standalone products:
Self-hosted operators -- a developer with a Mac Mini or a gamer with a GPU can offer inference. Cost basis is electricity. The protocol handles discovery, routing, and settlement automatically.
TEE nodes -- Trusted Execution Environments with cryptographic attestation. Not "we promise we don't log." Mathematical proof that the operator cannot access plaintext. The strongest privacy guarantee available for cloud AI, now accessible to anyone through a standard endpoint.
Skill providers -- anyone with frontier model API access can package domain expertise and compete on outcomes. Legal research, security auditing, financial analysis. Differentiated agents that build reputation over time.
Custom model operators -- serving use cases that require model flexibility. The protocol doesn't have a content policy. Providers set their own terms. Buyers choose providers whose terms match their needs.
Venice proved that people want AI that respects them. AntSeed is building the network where that's not a product promise, it's structural.
The same infrastructure that makes AI private also makes it censorship-resistant, price-competitive through open markets, resilient through automatic failover, and composable enough for agents to hire other agents autonomously.
That's not a niche. That's the next layer of the internet.
Venice built the vision. The rails are next.
]]>