Four roles make up the Ambient network: users and agents, the gateway layer, miners, and validators. A single inference request passes through all of them on its way from auction to settlement.
The two diagrams below give the shape at a glance: a single node's internal layers, then the life of a request across nodes; the sections that follow explain each piece.
| APIs and SDKs | Language SDKs RESTful Services |
|---|---|
| Blockchain Infrastructure | Smart Contracts Consensus Processing Transaction Services |
| AI Model Training and Execution Engine | Model Profiler Sharding Manager |
| Network Services | Data Oracles Query Processing Privacy Primitives |
Layer table titled Ambient Node Architecture. Four component groups, each with its subcomponents. APIs and SDKs: Language SDKs, RESTful Services. Blockchain Infrastructure: Smart Contracts, Consensus Processing, Transaction Services. AI Model Training and Execution Engine: Model Profiler, Sharding Manager. Network Services: Data Oracles, Query Processing, Privacy Primitives.
Flow graph laid out as three bands. Serving a query: User Queries and Contract Queries feed the Query Auction: listings include fee tokens for escrow, timing requirements, and validation requirements (if beyond minimum), input text size, etc. Mining Clusters place bids into the Query Auction (bids refundable on successful completion) and produce Unvalidated Query Results. Validation: Validator Cluster B (query result validators chosen in a weighted random fashion based on LStake) points at the Unvalidated Query Results, which become Validated Query Results and accrue LStake to successful problem solvers; Validator Cluster A performs LStake weighted voting on correctness of new state. Advancing the chain: Node A and Node B emit PoH sequences to the Leader, which performs transaction ordering based on PoH sequences; the Leader and Validator Cluster A point at New State, which produces a New Block.
The four roles#
- Users and agents. Anyone submitting an inference request: a person in the Ambient app, an application calling the API, or an on-chain agent. Requests state what the caller wants served, within what time, and at what price.
- The gateway layer. The web and API layer at
api.ambient.xyzaccepts OpenAI- and Anthropic-compatible requests and routes them into the network. This layer also handles query intake; the auction process is designed to obfuscate the origin of queries and the consumers of results (see Privacy below). - Miners. GPU operators who run the network model. They bid on queries, perform the actual inference, and commit Proof of Logits hashes as they generate. Mining is the expensive side of the work asymmetry.
- Validators. Nodes that spot-check miner output by re-running a small sample of its tokens and comparing logit hashes. Validators are chosen in a weighted random fashion based on LStake, their own record of validated useful work. Validation is the cheap side of the asymmetry, and it runs in parallel without blocking transaction processing.
Roles are not exclusive. The consensus design lets nodes specialize (some on LLM operations, some on transaction processing, some on validation), with all of them rewarded relative to validated contribution.
Life of a request#
A single inference request moves from auction to settlement in four stages. Validation is retrospective and parallel; it never sits between you and your response.
1. Auction#
Queries enter the system through an auction contract. The user or agent declares, in effect: "I would like this query served within X minutes, and I am willing to pay Y." Miners bid on the query; a miner's bid is refunded when it completes the query within the specified time, which is what gives the network its quality-of-service teeth.
On the testnet chain, this is a native on-chain (SBF) program: the Ambient
auction program. It creates a JobRequest account for the request, carrying the
request's bundle, price and output-token ceilings, context-length and expiry
tiers, and an IPFS content identifier for the input data. IPFS holds the
input data as temporary storage in the auction mechanism.
2. Inference#
The winning miner runs the request on the network model. As generation
proceeds, the miner produces the per-token logit hashes and progress markers
described in Proof of Logits. The request's
on-chain status moves from WaitingForOutput to OutputReceived.
3. Verification#
The auction program tracks a verification state for every job: a Merkle root of the output data, the set of assigned validators (the auction program calls them verifiers), and the token ranges each validator is responsible for. Assigned validators re-run their sampled tokens and check the miner's committed hashes. Each sampled check costs a single token of inference against the thousands the miner generated, so verification adds less than 0.1% overhead.
4. Settlement#
When validators confirm the output, the request reaches OutputVerified and
the job settles: the miner's timely completion is honored under the auction
terms, and the validated work is credited to the miner's and validators'
LStake, the work-credit measure that drives leader election and rewards.
Invalid work, when detected, results in retrospective slashing of that work
credit.
Consensus underneath#
Ambient pairs Proof of Logits with the Proof of History architecture described in the Solana whitepaper, replacing Solana's proof of stake with Ambient's proof of useful work. Leaders are elected on a weighted average of short- and medium-term validated contributions, and elected leaders process and order transactions continuously. Because logit validation is decoupled from transaction processing, consensus stays non-blocking.
What a node exposes#
In the designed node architecture, every node presents the same surfaces. Clients reach its subsystems over simple RESTful services and through language-specific SDKs; the initial SDK targets are JavaScript, Python, Go, and Rust. Smart contracts execute in Ambient's fork of the SVM, with extensions to the SDK for calling the on-network foundation model and for agentic tooling. A model profiler produces the fingerprints validators use for both inference and training, and network service primitives handle anonymized query processing and data access.
Scaling to a very large model#
Running and training a 600B+ model across independent nodes is only tractable with aggressive sharding. The design draws on two lines of research: PETALS (distributed inference and fault tolerance across unreliable, geographically dispersed devices) and Distributed SLIDE (adaptive dropout and hash-based sparse computation for low-bandwidth, few-core clusters). Four techniques carry the load:
- Sparsity. Adaptive dropout and hash-based neuron selection cut the computation and cross-node communication each training step requires.
- Model parallelism. The model and its hash tables are sharded across nodes, with fault-tolerance mechanisms that absorb node failures dynamically.
- Distributed computing under constraints. Adaptive sparsity limits the data that must synchronize across the network, and load balancing spreads work across heterogeneous, unreliable hardware.
- Algorithmic over hardware acceleration. The goal is competitive performance for a state-of-the-art model on relatively low-spec hardware, favoring smart algorithms over raw acceleration.
The intent is to lower the hardware bar for participation so mining is not confined to the largest operators.
Privacy#
Making both transactions and inference anonymous and censorship-resistant is a core design goal, approached with a range of techniques. The simplest is client-side obfuscation of personally identifiable data using a small local LLM before a request leaves the caller. The query auction is designed to obfuscate the origin of queries and the consumers of results. The most complex technique, pending a performant implementation, is fully or somewhat homomorphic encryption. Pre-training data is not obfuscated, but generated synthetic data can obscure fine-tuning data.
Data availability#
Training moves very large volumes of data, and ordinary economic incentives are weak at preserving that much data for long enough to keep model training reproducible. The design addresses this by integrating both HTTP and BitTorrent oracles directly into the nodes, with IPFS as temporary storage within the auction mechanism.
Evolving the network model#
The network model is meant to stay evergreen. A proposed voting system would let participants initiate new training campaigns that are specified programmatically: a training run can be proposed fully in code, referencing web and torrent URLs for its data, and is then interleaved with ordinary inference workloads across the network.
Keep reading#
- Proof of Logits covers the verification mechanism in detail.
- Tokenomics explains how reward design follows from work credit.