Today we want to share a decision that's been a long time coming.

We established a non-profit Foundation to steward the ecosystem. Its mission is embedded in the Foundation's charter, the document it is bound to serve.

The "why" is simple​

We don't want a company controlling the AntSeed ecosystem.

It is our view that networks that matter shouldn't live or die by the incentives of a single private entity. A company answers to shareholders. A Foundation answers to the mission and the community it exists to serve. That difference shapes every decision that follows.

There's also a practical side to this. Leaving the ecosystem without a proper structure behind it isn't risk-free. It can leave the community and token holders unnecessarily exposed. A Foundation seeks to give the ecosystem a clear, accountable, and durable home, and puts it on solid footing for whatever comes next.

So we're putting the things that matter most into a structure that is built to outlast any one team, including us.

Learning from the past​

We've been in this space since 2012, and over those years we've seen the Foundation model used in ways that didn't always live up to its promise.

In some cases, a Foundation became a vehicle to channel funds toward an affiliated "Labs" company that retained all control and authority. While the Foundation existed on paper, control of the ecosystem rested with the Labs entity, which was not independent.

While these models worked in the past, the world has changed, and we have sought to learn from them by redefining the manner in which our ecosystem is built. Our model is an evolution of the original blueprint.

The Foundation we're creating is designed to steward the ecosystem by utilising its proprietary assets and safeguarding its independence in service of the community. The Foundation shall not serve as a private company wearing a non-profit's clothing.

One master: the network​

This shows up in the smallest, most everyday decisions.

The contributors wake up every morning with one master to serve: the network. In the product world, the question that drives every decision is "what are you optimising for?" and here the answer is always the same. The AntSeed ecosystem. Not the dollar value flowing back to a Labs company.

That single alignment changes everything. In an ecosystem where there is no Labs entity and the network is the most important element, incentives stop being utilised in a manner that benefits the few and start benefiting the network contributors, the people who actually own and use it.

What the Foundation holds and does​

• 15% of total supply. Recognising the contribution to the network and to support its role, the Foundation shall receive 15% of the tokens: the Ecosystem Reserve. Importantly, this allocation is not unlocked upfront. It vests in epochs, on the same schedule as the rest of the supply. No special treatment, no head start.
• The brand, the website, and other assets related to the network.
• Core development funding and direction.
• Grants to builders, contributors, and researchers growing the ecosystem.

This is a real Foundation, not a logo on a website. It exists to safeguard the network's independence and to fund the people building its future.

Our commitment: monthly transparency​

We will publish a transparent report covering:

• What we achieved. Shipped work, grants awarded, milestones hit.
• Where our money went. Clear, itemised spending from the pool.
• The goals for the month ahead, so you can hold us to them.

No "trust us." Just receipts, every month. Our first transparency report will land by the beginning of Q4, and one will follow every month after that.

This is about giving the ecosystem the best possible chance to become genuinely community-owned and self-sustaining. The establishment of the Foundation isn't the finish line. The Foundation shall seek to become the enabler of a growing and flourishing ecosystem where Network Contributors, including the Foundation, build together.

So from now on, call us the AntSeed Foundation.

Let's build. 🐜

Building the Reputation Layer for an Open AI Market​

AntSeed is being built for a simple but difficult idea: anyone should be able to buy and sell AI services in an open market.

That openness is what makes the network powerful. A developer can run a model. A team can offer a specialized agent. A provider can sell private, TEE-backed inference. A router can help buyers find the right service. Buyers can choose between many sellers instead of depending on one centralized platform.

But openness also creates the hardest problem in any market: how do you build trust?

If anyone can show up and claim to be fast, reliable, cheap, private, or high quality, buyers need a way to know who has actually delivered. Sellers need a path to earn trust through real usage. Routers need signals they can inspect instead of relying on private rankings. And the network needs incentives that reward useful participation without making fake activity easy to profit from.

This post introduces the first phase of ANTS token economics: the reputation layer and utility around seller pools.

Seller pools are designed to turn payment-backed usage into a more durable reputation signal. They connect real buyer-authorized settlement history with long-term ANTS support behind seller identities.

This is not the full tokenomics system. It is the first layer.

We are also working on the second layer, focused on liquid inference: a broader market structure for routing, liquidity, and inference capacity. But before that layer can work well, the network needs a strong foundation for reputation. That foundation starts here.

We are building this while AntSeed is already serving close to 1,000 active users. That has been both exciting and humbling. We are moving fast, and when you move fast, you can make mistakes. Our commitment is to fix them quickly, keep improving in public, and keep listening to the people actually using the network. The support and usage from the community has honestly been overwhelming, and it is pushing us to make the system better every week.

The New Tokenomics in Plain English​

Seller pools introduce a simple loop for ANTS:

1. Real usage creates reputation. When buyers pay sellers through AntSeed channels, that settled USDC volume becomes recognized usage.
2. Good sellers can attract long-term support. ANTS holders can lock tokens behind a seller identity, creating a public signal that the service has durable backing.
3. Rewards follow useful participation. Sellers, buyers, stakers, and verifiers can earn from the weekly emissions budget, but only inside capped ranges.
4. Unused rewards do not quietly become extra yield. If a dynamic reward bucket is not fully earned, up to 30% of the extra budget gets burned.
5. Fees can add another burn path. Platform and operator-pool fees may be directed to market buy-and-burn, separate from emission routing.

The important change is that ANTS emissions are not just a flat giveaway. They are routed through usage, stake, verification, burn, and Foundation rules so the system can reward growth while reducing the value of fake activity.

Why Reputation Comes First​

Reputation is the core asset in an open AI services market.

Anyone can run a provider. Anyone can advertise a model name, a price, a latency target, or a capability tag. That is the point of an open network. But an open market also needs a way to separate sellers with real, buyer-authorized settlement history from sellers who only claim they can deliver.

AntSeed already records payment-backed usage through channel settlement:

• Buyers sign cumulative payment authorizations, called SpendingAuth
• Sellers settle against those authorizations
• Contracts record settled volume, channel outcomes, and optional metadata such as token count or request count

The next step is to make that accounting economically meaningful.

Settlement-backed usage should:

1. Build reputation
2. Improve routing
3. Give strong providers a clearer path to more traffic

That is what seller pools are for.

The Problem With Flat Incentives​

The simplest reward model is easy to explain:

seller serves requests → seller earns points → seller gets tokens

But flat usage rewards are not enough for an open network.

They miss two important questions:

1. Was the usage real and hard to fake?
2. Is there long-term stake behind the seller identity?

If rewards only follow volume, the system can invite fake volume. If rewards only follow stake, the system can reward capital even when no useful service is being delivered.

AntSeed needs both:

• Recognized usage — buyer-authorized, settled payment flow that creates usage points
• Locked stake — ANTS committed behind an ERC-8004 seller identity for a defined period
• Routing reputation — a public signal that buyers and routers can use when choosing providers

The new model combines these into seller pools.

What Is a Seller Pool?​

A seller pool is an ANTS-backed pool attached to an ERC-8004 agent ID.

The agent ID is the seller identity buyers route to. A seller can run many kinds of services, including:

• A raw inference service
• A specialized agent
• A TEE-backed provider
• A routing service

The pool sits behind that identity and answers one simple question:

How much long-term ANTS support is committed behind this seller?

That answer does not replace usage history. It adds economic context around it.

A seller cannot buy a good reputation with stake alone. The pool becomes meaningful only when paired with recognized usage.

The lANTS NFT​

When stakers lock ANTS into a seller pool, they choose how long the lock should last. The position is represented by an NFT called lANTS.

Think of lANTS as an on-chain receipt for committed support behind a seller.

The lANTS NFT is not a profile picture. It is not reputation by itself. It is a portable record of committed stake behind a seller identity.

Because it is an NFT, the support is public and composable. Wallets can show it. Dashboards can explain it. Routers can factor it into policy. Future contracts can build on top of it.

We also expect lANTS to play a role in the second ANTS utility phase focused on liquid inference. The exact mechanics are still being designed, but the intent is that long-term support behind real providers can become useful beyond this first reputation layer.

Recognized Usage​

Every paid AntSeed channel already produces buyer-authorized settlement data.

Here is the basic flow:

1. A buyer authorizes payment for usage
2. A seller settles against that authorization
3. The contract records the settled USDC volume
4. Optional metadata can also record request or token counts

For each settlement, the protocol records usage points for the buyer and seller. Those points are weighted by the seller pool's locked support for that epoch.

In plain English:

Settled usage through a stronger, longer-locked seller pool carries more weight than the same usage through a weak or temporary pool.

That does not mean stake alone wins. It means real usage becomes more meaningful when there is durable commitment behind the seller identity.

Why This Creates Better Reputation​

Seller pools combine two signals that are stronger together than apart.

This makes routing better because buyers and routers can inspect more than a single number. They can look at real settlement history, pool support, lock duration, restaking behavior, and service quality metrics together.

Anti-Abuse Protections​

Open incentive systems attract abuse. We should be honest about that.

Seller pools are designed to make wash trading harder to reward. Fake volume has to pass through multiple layers:

• Signed buyer payment flow
• Pool-weighted accounting, so stake context matters
• Account caps and dynamic reward ranges, so fake volume cannot simply scale forever
• Burn and Foundation routing, so unused rewards do not become extra yield
• Verification and anti-abuse policies, so suspicious behavior can be checked and excluded

No single number is enough. The goal is not to pretend abuse disappears. The goal is to make reputation harder to fake and make extraction less attractive.

Verification Is Part of the Market​

A trustworthy market cannot depend only on payments and stake. It also needs people and software constantly checking whether the network is doing what sellers say it is doing.

That is why 10% of the epoch allocation is reserved for verification.

The verification pool is for the people who help validate the network: buyers, routers, providers, researchers, and future verifier operators who contribute useful checks, dispute signals, monitoring, and anti-abuse work. In other words, the network should be validated by the people who serve and use the network.

The first verification layer we are building is behavioral model fingerprinting.

The problem is simple: a provider can advertise a premium model name, but serve a cheaper or unrelated model behind the scenes. Payment settlement proves that a response happened. Ghost-channel reputation can show whether a seller completed sessions. But neither of those alone proves that the advertised model actually produced the response.

Behavioral fingerprinting is a lightweight first step. Buyer-side verifiers can periodically send small deterministic probe requests to the same peer that handled real traffic. These probes do not block user traffic. They are designed to catch common low-effort substitution by testing things like:

• Format and schema compliance
• Simple deterministic tasks
• Model-family sanity checks
• Behavior that should be stable for the advertised model

This is not a perfect proof of model identity, and we should not pretend it is. It is a practical first layer. It helps detect obvious mismatches while we keep improving the verification system.

Over time, we expect to add more verification families, including:

• TEE attestation and privacy verification
• Model and capability checks
• Latency and availability audits
• Receipt and metering verification
• Sybil and wash-trading detection
• Provider claim verification for specialized agents or managed services

As these verification layers grow, the verification pool becomes more important. It rewards the work of making the market trustworthy: writing probes, running checks, reporting disputes, maintaining verifier infrastructure, and helping define better policies for what should count as recognized usage.

This is also why verification is its own allocation instead of being hidden inside seller rewards. We want the people who improve network trust to have a direct path to earn from that work.

How Rewards Flow​

Each weekly epoch has an ANTS emission budget. Some parts are fixed, and some parts are dynamic.

In plain terms: some buckets are always present, while others only expand when the network has more real usage or more locked support behind sellers.

The fixed parts are easy to understand:

• Contributors: 15%
• AntSeed Foundation: 15%
• Verification: 10%

The dynamic parts depend on what is actually happening in the network:

• Seller-pool stakers: 2-40%, based on active ANTS stake behind seller pools
• Sellers / operators: 5-10%, based on recognized settled USDC volume
• Buyers: 5-10%, based on recognized settled USDC volume

The dynamic ranges are what make this model different from a fixed emissions schedule. The protocol does not need to pay the maximum reward when usage and stake are still early. As real usage grows and more ANTS is locked behind sellers, more of the dynamic budget becomes earned.

The projection uses a conservative stake model. It does not assume the 500M stake target is reached early. Instead, it limits modeled active stake based on projected circulating supply and a gradual participation curve.

For usage, the projection starts near the current level of about $15k settled USDC per weekly epoch and reaches the $1M per-epoch target around year two.

When a dynamic budget is not fully earned, the unused part is not redistributed as extra rewards. It routes through the remainder path: burn first, then the AntSeed Foundation.

Dynamic Ranges and Burn​

Seller-pool and usage rewards are not paid out as one fixed percentage every epoch. They grow as the network earns them.

The flow is:

1. The seller-pool budget grows as active ANTS stake grows, but the model does not assume every token can immediately be staked; the weekly budget is still capped at 40%
2. Buyer and seller/operator budgets each grow inside a 5-10% range as recognized settled USDC volume grows toward the $1M per-epoch target
3. Claimable rewards go to lANTS positions, sellers/operators, or buyers based on weighted usage
4. Unused dynamic reward budget is settled as a remainder
5. Remainders burn first, up to 30% of weekly emission, then route to the AntSeed Foundation

That dynamic-budget remainder is only one burn path. The charts project burn from emission routing and early-withdraw penalties only; fee-driven buy-and-burn is a separate mechanism and is not projected here.

The burn shown here is not a single fixed allocation. It can come from unallocated dynamic-budget remainder and early exits from locked positions. Fee-driven market buybacks may add another burn path later, but they are not included in this projection.

This makes unused emission budget visible. Early emissions should not simply go to whoever manufactures the largest number, and budget that is not earned through stake or recognized usage should not quietly become extra rewards.

The goal is to reward useful, long-term participation with real settlement behind it.

Claim, Stake, or Restake​

Seller pools create a loop between usage, rewards, and reputation.

Flow 1: Direct Claim and Stake​

Buyers who earn ANTS from recognized usage can:

• Claim their rewards
• Stake them directly into seller pools

This turns buyer rewards into an active trust signal. Buyers can support the providers they want to see more of.

Sellers who earn ANTS can:

• Claim their rewards
• Stake them back behind their own service

That creates a direct loop:

Serve usage → earn rewards → stake behind service → strengthen reputation → become more attractive to routers

Flow 2: Existing Locked Seller Rewards​

AntSeed currently tracks earlier seller ANTS rewards, but those locked rewards are not being used in the new seller-pools protocol.

They are a separate matter from this launch. More information about those tokens will be announced separately, so this post should not be read as changing their status or moving them into the new pool structure.

Practical Uses for lANTS​

Because lANTS positions are readable on-chain objects, they can support many future uses:

The key distinction is important:

The NFT is the receipt for committed stake. Reputation still comes from usage, settlement, and observable service quality.

It may also become an important primitive for the second token utility phase around liquid inference, where durable provider support and routing liquidity are expected to connect more directly.

The Three Layers of AntSeed Reputation​

AntSeed reputation has three layers.

Layer 1: What Happened?​

This includes:

• Completed sessions
• Failed or abandoned sessions
• Settled USDC volume
• Optional request count
• Optional token volume
• Latency and client-side service metrics

Layer 2: Who Is Committed Behind It?​

This includes:

• ANTS locked behind the ERC-8004 agent ID
• Lock duration
• Pool power
• Restaked rewards
• New lANTS positions created through the seller-pools protocol

Layer 3: Can the Claims Be Verified?​

This includes:

• Behavioral model fingerprinting
• TEE attestation and privacy checks
• Capability and provider-claim verification
• Receipt and metering verification
• Rules that scale down or exclude suspicious usage
• Verifier rewards for people and systems that improve network trust
• Penalties for fake usage, sybil behavior, model substitution, or incentive extraction

Seller pools connect Layer 1 and Layer 2, while verification strengthens the whole system.

A seller earns reputation by attracting settled, buyer-authorized usage. The pool proves that durable stake is committed behind the identity. Verification adds another question: is the seller actually delivering what they claim? Together, those signals make routing better.

What Buyers Can See​

Seller pools help buyers and routers ask better questions:

• Does this seller have settled usage history?
• Did buyers sign payment authorizations?
• How much volume has settled?
• How often does the seller disappear?
• Is there locked ANTS behind the seller identity?
• How long is that support committed?
• Did the seller restake earned rewards?

No single metric answers everything. Seller pools add the missing economic context around settlement data.

Why Buyers Matter​

Buyers are not passive in this model.

Buyer usage creates recognized demand. A seller cannot build real reputation without buyers who actually use the service and sign payment authorizations. Buyer rewards recognize this demand side of the market.

Buyers can also become curators.

If a buyer repeatedly chooses a provider, they can stake earned ANTS into that seller's pool. That is a stronger signal than a review. It says:

I used this provider, earned rewards from settled usage, and chose to lock support behind them.

Over time, good sellers should attract both usage and stake. Bad sellers should not.

What This Is Not​

Not a Promise of Returns​

ANTS does not represent:

• Ownership in AntSeed
• A claim on protocol revenue
• A right to distributions

Rewards are programmatic incentives for useful network participation, subject to:

• Caps
• Locks
• Verification
• Slashing or exclusion rules

Not a Shortcut Around Usage​

The model is designed so that stake supports reputation, but does not replace it.

The Loop​

The system is built around a simple, self-reinforcing loop:

Closing Thoughts​

This first phase of ANTS token economics is about reputation and utility.

Seller pools are designed to:

1. Make stronger sellers easier to find
2. Make fake usage less valuable
3. Fund verification work that makes the market more trustworthy
4. Let reputation compound around identities with settled usage, committed stake, and validated claims

Open AI markets do not need a central ranking committee. They need public accounting, committed stake, independent verification, and routing rules that anyone can inspect.

Seller pools are how AntSeed starts putting those pieces together.

We are still early. We are building while the network is already being used at meaningful scale. We will learn, we will adjust, and when we get things wrong, we will fix them quickly.

The goal is simple: a more trustworthy market for AI services, where useful providers can earn trust in public and buyers can route with more confidence.

Disclaimer: everything described here may still change. We are building in public, watching how the network is actually used, and trying to be sensitive to real network activity rather than forcing fixed parameters too early.

gpt-5.5 | claude-opus-4.8 | minimax-m3 | premium model

But if an endpoint silently routes you to a cheaper model, mixes traffic across providers, wraps another API, or serves a quantized substitute, what evidence do you actually have?

Usually: almost none.

AntSeed is building the missing verification layer for that market.

The Label Is Not Evidence​

The problem is not hypothetical. The paper Real Money, Fake Models audits shadow APIs that claim to serve official frontier models and finds divergence across utility, safety, and identity verification. The economic incentive is obvious: charge for the expensive model, serve something cheaper, pocket the spread.

Centralized APIs can ask users to trust brand, contracts, or customer support. A peer-to-peer market cannot depend on any of that. AntSeed sellers are independent peers. Buyers need evidence that travels with the response.

That starts with a distinction that matters:

Signed responses do not prove model identity.

They prove who served which bytes.

That is the base layer. Once a seller's responses are attributable, buyers can run black-box model verification on top. Cryptographic provenance first. Statistical model auditing second.

What Is Already Implemented: ResponseAuth​

AntSeed now has a signed response-authentication substrate in @antseed/node.

For supported buyer-seller connections, the seller signs a ResponseAuthPayload after serving a response. The payload commits to:

• the request hash;
• the response hash;
• buyer peer id;
• seller peer id;
• advertised service;
• provider name;
• status code;
• timing;
• optional payment channel id.

The buyer verifies the signature against the seller peer identity and stores the result in local verification storage. A random sample of verified exchanges can also be written to disk as full evidence:

<dataDir>/verification_samples/
  <sellerPeerId>/
    <sampleId>/
      manifest.json
      request.bin
      response.bin

This does not tell us whether the response came from the claimed model. It tells us that the seller cannot later deny serving those exact bytes. That is the difference between a complaint and evidence.

What Comes Next: Fingerprint Verifiers​

The next layer is a verifier suite, not one magic test.

Different cheats leave different traces. A cheap substitute might fail knowledge-boundary probes. A wrapper around a real model might show instruction-hierarchy artifacts. A relay might reveal itself through runtime behavior. A model family may have rare-token or perturbation signatures.

The model-verification spec tracks several verifier families:

• KBF: knowledge-boundary fingerprinting with numeric probes near the claimed model's edge of knowledge. See Knowledge Boundary Fingerprinting and the KBF reference implementation.
• LLMmap-style behavioral probes: active prompts selected because model families respond differently. See LLMmap.
• TRAP-style adversarial triggers: private prompts that elicit distinctive target-model behavior. See TRAP.
• ZeroPrint-style perturbation fingerprints: compare how responses change under semantic-preserving input variations. See ZeroPrint.
• UTF / rare-token fingerprints: probe behavior around under-trained or unusual tokens. See UTF.
• LLMPrint-style prompt-injection fingerprints: exercise instruction hierarchy and prompt-injection behavior. See LLMPrint.
• Julius-style service fingerprints: identify serving stacks such as Ollama, vLLM, LiteLLM, and other LLM API runtimes. See Julius and its open-source repository.
• READER-style passive provenance: analyze ordinary signed responses after the fact with reader/provenance models. See READER.

None of these should be treated as absolute truth alone. The point is to build a suite where independent signals compound. A SAME result is not a certificate. A strong DIFF result, backed by signed response evidence and reproducible references, becomes something a buyer can act on.

Why Public Fingerprints Should Behave Like Torrents​

Private probes matter for adversarial enforcement. If every seller can see the exact test set, a dishonest seller can route those prompts to the real model and serve cheap responses for everything else.

But public fingerprints still matter.

They are useful for reproducibility, smoke tests, shared baselines, research, and network-wide learning. The question is how to distribute them without turning AntSeed into another centralized API or hosted database.

The answer in the spec is a fingerprint swarm.

Think torrent, not registry:

A fingerprint pack is a signed, content-addressed bundle. Peers announce small metadata. Other peers fetch the pack from any mirror or seeder, verify the content hash, verify the publisher signature, and decide locally whether to trust it.

The trust model is simple:

Discovery tells me a pack exists.
Storage gives me bytes.
Hash proves the bytes are correct.
Signature proves who published the pack.
Local trust policy decides whether I use it.

No central server has to be the source of truth. GitHub can be a review surface and bootstrap mirror. IPFS, Arweave, HTTPS mirrors, and AntSeed peers can all serve the same pack bytes. The pack is valid if the hash and signature check out.

What This Enables​

The long-term flow looks like this:

1. A seller advertises a model or service.
2. The buyer sends normal requests through AntSeed.
3. The seller signs response provenance with ResponseAuth.
4. The buyer stores verified evidence locally.
5. The buyer imports trusted public fingerprint packs from the swarm.
6. The buyer keeps private references for stronger audits.
7. The buyer runs fingerprint verifiers locally.
8. Local routing avoids sellers with bad evidence.
9. Disputes and slashing come later, only after off-chain verification.

The important part is the ordering. We do not start with slashing. We start by making responses attributable, then make verification local, then make public fingerprints easy to share, then build dispute machinery only once the evidence format is mature.

What Gets Built Next​

The merged specs define the implementation path:

• @antseed/fingerprints: shared verifier interfaces, reference schemas, pack schemas, canonical hashing, and KBF as the first verifier.
• Fingerprint swarm support: signed pack announcements, content-addressed fetches, peer seeding, mirrors, and local trust policy.
• Buyer reference store: trusted references under <dataDir>/fingerprints/references.
• Audit runner: send normal AntSeed requests, require verified ResponseAuth, force-store audit evidence, compute verifier results.
• Local routing policy: downgrade or avoid sellers with repeated adverse evidence.
• Dispute path later: commit-reveal, off-chain exhibit verification, and compact on-chain slash signals only for confirmed substitution.

The first shipped piece is already there: signed response provenance.

Everything else builds on that.

The Bigger Point​

AI infrastructure is moving from branded endpoints to markets of interchangeable providers, routers, resellers, agents, wrappers, and local runtimes. In that world, "trust me, this is the model" is not enough.

The market needs public, inspectable, reusable model fingerprints.

It also needs private probes, because public tests can be gamed.

And it needs cryptographic provenance, because without attribution, every model-verification result is just a claim.

AntSeed is putting those pieces together:

• signed responses for attribution;
• black-box verifier suites for model identity signals;
• a torrent-like fingerprint swarm for public packs;
• buyer-local audits for enforcement;
• dispute and slashing only after evidence can survive review.

A normal API response is just text.

An AntSeed response can become attributable audit evidence.

Read the model-verification spec

Read the fingerprint-swarm spec

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.

The Gatekeeping Problem​

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.

Where Centralized Routing Breaks​

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.

Decentralized Projects: Right Direction, Different Problem​

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: Same Interface, No Gatekeeper​

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 4% protocol fee flows to the Protocol Reserve, not to a company. 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.

How It Actually Works​

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.

The Comparison​

Who This Is For​

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.

Frequently Asked Questions​

Is AntSeed free to use? There's a 4% protocol fee per request, flowing to the Protocol Reserve. 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.

Read the lightpaper · Get started in one command

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.

The metadataHash​

Every payment authorization (SpendingAuth) the buyer signs contains three fields:

• channelId — the session identifier for this buyer-seller pair
• cumulativeAmount — total USDC authorized so far across all requests
• metadataHash — 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.

The Negotiation​

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.

Seller's terms​

When a buyer sends a request without an active session, the seller responds with 402 and publishes its requirements:

• minBudgetPerRequest — the minimum the seller needs per request (default: $0.01)
• suggestedAmount — what the seller recommends for a smooth session (default: $0.10)
• Per-token pricing — optionally, the seller publishes input and output token rates so the buyer can estimate costs upfront

Buyer's limits​

The buyer has its own caps, configured by the operator:

• maxPerRequestUsdc — the most the buyer will authorize per single request (default: $0.10)
• maxReserveAmountUsdc — the total budget ceiling per session (default: $1.00)

Resolution​

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.

Per-Request Cost Tracking​

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.

Settlement as Proof​

When the seller calls settle() or close() on the AntseedChannels contract, they submit the buyer's latest SpendingAuth signature. The contract:

1. Verifies the buyer's EIP-712 signature
2. Charges the cumulative amount from the buyer's locked deposit
3. Credits the seller's earnings (minus platform fee)
4. Optionally forwards the buyer-signed metadata to AntseedStats

Step 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:

• Session count — completed sessions
• Ghost count — sessions where the seller disappeared without settling
• Total volume — cumulative USDC settled
• Last settled — timestamp of most recent settlement

If AntseedStats is configured, it can additionally aggregate:

• Total tokens — cumulative input and output tokens
• Total requests — cumulative requests served

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.

Budget Exhaustion and Renewal​

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.

Timeout Protection​

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.

An Open Record for an Open Network​

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:

• Has this seller actually delivered before? Check session count.
• How much value has flowed through them? Check total volume.
• Do they disappear mid-session? Check ghost count against session count.
• What's their typical response time? Check average latency.
• Are they still active? Check last settled timestamp.

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.

Why This Matters​

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.

The Hot Wallet Is Just a Signing Key​

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:

• Per-request: each SpendingAuth increment is capped at $0.10 by default
• Per-session: each ReserveAuth is capped at $1.00 by default
• Per-seller: each authorization is scoped to a single seller address
• Time-bounded: each authorization expires at a specific deadline
• Monotonic: cumulative amounts can only go up — replaying old signatures is useless

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 Never Touches the Node​

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.

Why This Matters More Than You'd Think​

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.

Under the Hood: One Key, One Identity​

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.

Desktop Key Storage​

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.

Comparison with Existing Approaches​

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 Bottom Line​

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.

The Trigger​

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.

Two Signatures, One Session​

This is the core of the design. AntSeed uses two distinct EIP-712 signatures to separate the concerns of reserving funds and authorizing spend:

ReserveAuth — the budget ceiling​

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:

• channelId — a deterministic identifier for this buyer-seller pair
• maxAmount — the total USDC the seller is allowed to draw
• deadline — when the authorization expires

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.

SpendingAuth — cumulative authorization​

On every request, the buyer signs a SpendingAuth — a lightweight EIP-712 signature that authorizes a cumulative spend amount:

• channelId — same channel as the ReserveAuth
• cumulativeAmount — total USDC authorized so far (monotonically increasing)
• metadataHash — a hash of cumulative delivery metrics (tokens processed, latency, request count)

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.

Same DataChannel, Zero Overhead​

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.

Running Out of Budget​

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 and Manual Mode​

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.

Comparison to x402 and MPP​

Three protocols now give HTTP 402 a concrete mechanism. They solve different problems with different architectural tradeoffs.

x402 (Coinbase)​

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.

MPP (Stripe + Tempo)​

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.

AntSeed​

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.

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.

Why This Matters​

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.

Why People Want AI Without an Account​

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 Problem With Current Options​

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.

What AntSeed Does Differently​

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.

Claude Without a Claude Account​

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, Privately​

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.

Llama and Open-Weight Models​

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.

TEE: The Highest Privacy Tier​

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.

Uncensored Models and Becoming a Provider​

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.

The Practical Picture​

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.

Get started

How the protocol works

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.

Why P2P Lost Before​

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.

What Changed: The User Is Now an Agent​

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 Biggest Shift: Agents Hiring Agents​

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.

Why This Moment​

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.

Read the lightpaper

Get started in one command

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.

What Venice Got Right​

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.

Protocols Outlast Products​

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:

• Anyone could participate as a provider, a builder, or a user
• No single company could turn it off
• Competition happened at the service layer, not the infrastructure layer
• The value of the network grew with every new participant

AI is at the product stage. The protocol stage hasn't happened yet.

AntSeed Is the Protocol Layer​

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.

Venice as a Provider on AntSeed​

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.

The Providers AntSeed Opens Up​

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.

The Bigger Picture​

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.

Read the AntSeed lightpaper

Get started in one command