Pura is a backpressure-routing protocol for machine-to-machine work. It measures spare capacity, prices congestion, and routes requests and payments toward nodes that can still do the job.
The hosted product today is the gateway at api.pura.xyz and the docs around it. The contracts, SDK, simulation, and protocol drafts are the open-source building blocks for the broader network.
Hosted now
Use the live gateway, provider monitor, Lightning invoice flow, and onboarding docs if you want the thing that works today.
Open source / protocol
Read the paper, inspect the contracts and SDK, or work from the repository directly if you want the underlying protocol machinery.
You run AI agents that call LLMs. You want to pay less per request without managing four different provider APIs. Pura scores each request by complexity and routes it to the best provider for the task. Simple lookups go to Groq or Gemini. Reasoning goes to Anthropic or OpenAI. You get cost headers on every response and a nightly spend report.
One line change: swap your base URL to api.pura.xyz. Everything else in your OpenAI SDK code stays the same.
You run a Nostr relay. You want to monetize it without spamming your users with subscription prompts. Pura lets you declare your relay's capacity on-chain, receive flow-weighted payments through a Superfluid stream, and have your relay's throughput verified cryptographically. Busier relays earn proportionally more.
You run a Lightning node. Channel rebalancing costs money and time. Pura can read your node's channel capacity on-chain, route rebalancing flows through the backpressure algorithm, and settle fees via your existing Lightning channels. The protocol treats your node like any other service provider that declares capacity and earns proportional to work done.
Lightning integration details →
You build AI agents with OpenClaw, LangChain, or a custom stack. Your agents need LLM inference, and you want cost control without hardcoding provider logic. Install the Pura OpenClaw skill or point your HTTP client at the gateway. Your agents get automatic model selection, budget caps, and spend tracking across every agent in your fleet.
AI agents do work for each other and pay in real time: a translation agent pays an LLM, a photo app pays an image generator, a search agent pays an embedding service. These payments stream continuously, like water through pipes.
What happens when an agent gets too busy? The money keeps flowing in whether the work gets done or not. Paying for a meal that never arrives because the kitchen is overwhelmed.
Data networks solved this decades ago. Routers drop packets or reroute traffic when links are congested. Payment networks have no equivalent. Pura builds one.
The core idea comes from backpressure routing: send more money to agents with the most spare capacity. When Agent A has room, it gets a bigger share. When Agent B is slammed, it gets less. The system reroutes money toward whoever can actually do the work.
Pura is organized into four stacked planes. Data flows upward from capacity reports to settlement. Control signals flow downward as backpressure when any plane is saturated.
| Plane | Contracts | Job |
|---|---|---|
| Capacity | CapacityRegistry, StakeManager | Agents declare and stake against how much work they can handle |
| Verification | CompletionTracker | Dual-signed receipts prove work was actually done |
| Pricing | PricingCurve, TemperatureOracle | Dynamic fees rise with congestion, fall with spare capacity |
| Settlement | BackpressurePool, PaymentPool | Money moves via Lightning, Superfluid streaming, or direct ERC-20 |
Every interaction in Pura produces one or more of five typed objects. They flow left to right through the system, each one feeding the next contract.
| Object | Who creates it | What it carries |
|---|---|---|
| JobIntent | Source (buyer) | Task type, max price, deadline |
| CapacityAttestation | Sink (provider) | EWMA-smoothed capacity, EIP-712 signature, epoch number |
| VerificationReceipt | Source + Sink | Dual-signed proof that the work completed |
| PriceSignal | PricingCurve | Base fee + queue premium for this task type at this moment |
| SettlementReceipt | PaymentPool | Which rail was used, amount, preimage or stream ID |
Five operations form a pipeline. Each feeds into the next.
Every sink tells the network its capacity, like a restaurant posting how many tables are open. Two safeguards prevent lying.
Agents deposit collateral to play. The more you deposit, the more capacity you can claim. But the relationship is concave (square root), so depositing 4x more only allows 2x more capacity. This makes Sybil attacks unprofitable.
A commit-reveal scheme prevents front-running: agents submit a sealed commitment first, then reveal the real number later.
Declaring capacity is easy. Doing the work is the hard part. Pura has a built-in lie detector:
Every completed task produces a dual-signed receipt: both the agent doing the work and the agent requesting it must sign off. The blockchain counts receipts and compares them to declared capacity.
If an agent claims it can handle 100 tasks per epoch but only completes 40? After three bad epochs, 10% of its deposit gets slashed. Lying about capacity is a losing strategy.
Like surge pricing, Pura makes busy agents more expensive:
The price has two parts:
Demand naturally flows toward agents with spare capacity because they are cheaper.
The BackpressurePool collects incoming payment streams and redistributes them automatically. Agents with more verified capacity get a bigger slice. No middleman, no manual intervention.
When capacity changes (an agent gets busy, or a new one joins), anyone can trigger a rebalance to update the split.
When all agents are at capacity and money keeps coming in, the EscrowBuffer holds it. When capacity frees up, the buffer drains automatically. If the buffer itself fills, sources get a clear signal: stop sending.
The five-step pipeline treats capacity as a signal and money as a conserved flow. The thermodynamic layer adds six mechanisms that recast the protocol as a physical system: variance becomes temperature, capital ratios become virial equilibrium, and overload triggers circuit breakers.
Three new contracts (TemperatureOracle, VirialMonitor, SystemStateEmitter) plus modifications to BackpressurePool, Pipeline, and DemurrageToken implement the framework.
In statistical mechanics, temperature measures the width of the energy distribution across microstates. Pura defines an analogous economic temperature τ from the variance of capacity attestations within an epoch.
Let σ² be the EWMA-smoothed variance of declared capacities across all active sinks, and σ²max the governance-set maximum expected variance. Then:
τ = τmin + (τmax − τmin) · σ² / σ²max
Defaults: τmin = 0.5, τmax = 5.0. When all providers report identical capacity, σ² → 0 and τ → τmin, producing near-deterministic routing. When capacity reports diverge, τ rises, spreading flow across more sinks.
The floor of 0.5 prevents an oscillation trap where two sinks with nearly equal capacity alternate as the sole recipient each epoch.
Classical BPE assigns pool shares proportional to smoothed capacity times square-root-of-stake. Boltzmann routing replaces this with a probabilistic allocation: the share for sink i with spare capacity ci is:
P(i) = exp(ci / τ) / Σj exp(cj / τ)
Computing exp(x) on-chain is expensive. The contracts use a first-order Taylor approximation (1 + c/τ), accurate when c/τ < 1, which is the common case since spare capacity is a fraction of τmax. Full Boltzmann weights are computed off-chain, signed under EIP-712, and submitted via BackpressurePool.rebalanceWithShares().
On-chain, submitted shares are blended with a uniform exploration term:
sharei = (1 − ε) · P(i) + ε · (1/N)
ε defaults to 5% (capped at 20%). The exploration term guarantees every connected sink gets at least ε/N of the flow, preventing starvation even at low temperature.
In celestial mechanics, the virial theorem relates kinetic and potential energy: 2K + U = 0 at equilibrium. Pura adapts this to bound capital:
V = 2T / (S + E)
T is epoch throughput (total tokens that flowed through pools), S is total staked capital, E is total escrowed capital. The equilibrium target is V = 1.0: throughput and bound capital are balanced.
The VirialMonitor contract stores V and exposes two advisory functions: recommendedDemurrageRate() and recommendedStakeAdjustment().
The DemurrageToken is an ERC-20 wrapper that applies continuous decay to idle balances. Given a decay rate λ and elapsed time Δt since last rebase:
balancereal = balancenominal · e−λΔt
On-chain, a linear approximation avoids the exponential. At the default 5%/year rate with hourly rebases, the approximation error is below 6 × 10−6.
When adaptiveDecayEnabled is true and a VirialMonitor is attached, the decay rate tracks the monitor's recommendation instead of a fixed λ. This closes a feedback loop: low activity (V < 1) raises demurrage, pushing idle tokens into staking or spending, which raises throughput, which raises V back toward equilibrium.
Demurrage is the stock-side complement to BPE's flow-side routing. BPE routes payments to where capacity exists. Demurrage ensures those payments get made, because holding tokens becomes a losing strategy. The two together create stronger circulation pressure than either alone.
The EscrowBuffer stores overflow payments when all sinks are saturated. Pressure is defined as:
P = L / M
L is the current buffer level, M the configured maximum. P ranges from 0 (empty) to 1 (full). The buffer emits a PressureChanged event on every deposit. Draining is permissionless: any caller can trigger drain(taskTypeId), which distributes buffered tokens proportionally by capacity.
The Pipeline contract composes multiple pool stages into a sequential workflow. Each stage carries a circuit breaker with five phases:
| Phase | Trigger |
|---|---|
| Steady | Default healthy state |
| Bull | V > 1.5 |
| Shock | P > 0.80 or V < 0.2 |
| Recovery | τ > 3.0 and V < 0.8 |
| Collapse | P > 0.95 or V > 5.0 |
When a stage collapses, the pipeline decouples it: upstream effective capacity is capped at the downstream throughput observed before collapse, halting new flow into the failed segment. Recovery occurs when the stage's throughput ratio returns above 20% and escrow pressure drops below 90%.
Decoupling prevents cascade failure. A bottleneck in stage 3 of a 5-stage pipeline no longer starves stages 1 and 2 of routing information.
NIP-90 Data Vending Machines already handle user-facing AI jobs on Nostr (kinds 5000-5250). Pura provides three adapter contracts that bridge any existing DVM into the protocol without changing the DVM's own code.
DVMCapacityAdapter translates the DVM's capacity metrics (throughput, latency, error rate) into a normalized capacity score, EWMA-smoothed with α=0.3DVMCompletionVerifier uses EIP-712 dual-signature verification to record NIP-90 job completions on-chainDVMPricingCurve feeds verified completions into the PricingCurve so the DVM's per-job fee tracks real congestionOperators install a Pura sidecar that handles staking, capacity reporting, and attestation. The DVM itself runs unchanged.
Pura does not mandate a single payment mechanism. The PaymentPool selects the best rail for each settlement:
| Rail | Speed | Reliability | Best for |
|---|---|---|---|
| Lightning HTLC | ~2s | 95% | Instant small payments (sats) |
| Superfluid GDA | continuous | 99% | Ongoing per-second streaming |
| Direct ERC-20 | ~4s | 99.99% | Large per-job settlements |
The CrossProtocolRouter exposes a single interface so applications use whatever rail fits without managing three integrations.
You don't have to go on-chain to start using Pura. The @puraxyz/shadow sidecar runs locally alongside your service and simulates the full BPE pipeline: EWMA smoothing, Boltzmann routing, temperature and virial calculations, circuit breaker phases.
Shadow mode is free, has zero blockchain dependencies, and feeds a monitor dashboard showing τ, V, and phase state in real time. When you're ready, a single registration call moves your service on-chain. The sidecar model means you can evaluate the protocol's behavior against your actual workload before committing capital.
The core mechanism (declare, verify, price, route, buffer) is domain-agnostic. Anywhere there is a capacity-constrained service and a continuous payment flow, backpressure routing can improve allocation. Beyond AI agents, Pura extends to four research domains:
Lightning enables instant Bitcoin payments through payment channels, but routing is unreliable. Senders rely on stale gossip data about channel liquidity and probe routes by trial and error.
Pura adds a real-time capacity signaling layer without modifying the Lightning protocol:
LightningCapacityOracle: node operators submit signed EWMA-smoothed attestations of aggregate outbound liquidity (not individual channel balances, so privacy is preserved)LightningRoutingPool: a BPE pool where nodes are weighted by routing capacity. Nodes with more available liquidity and balanced channels earn more streaming revenue.CrossProtocolRouter: selects Lightning (~2s), Superfluid (~4s), or on-chain (~12s) per paymentThis runs on Base as a sidecar to Lightning. Pathfinding algorithms can query the oracle for fresher data than gossip provides. Node operators get streaming revenue proportional to verified capacity, which makes routing more financially sustainable and should attract more liquidity into the network.
Nostr messages are distributed through relays operated mostly by volunteers. Most run at a loss. Users have no way to discover which relays have capacity, and relays have no way to price services based on actual load.
Pura adds an economic layer using the same BPE primitives:
Relay operators who invest in real capacity earn proportionally more. Operators who overcommit get less and get slashed. We've drafted NIP-XX to standardize this.
With four domains sharing BPE infrastructure, there is a coordination problem: how do you share reputation across domains?
UniversalCapacityAdapter normalizes capacity signals from any domain into a common format. A new domain (decentralized storage, compute marketplaces) plugs in by registering a single adapter contract.
ReputationLedger makes track records portable:
OpenClaw is a large open-source agent framework with ClawHub, a marketplace of installable agent skills. As deployments grow from single agents to multi-agent pipelines, a coordination problem appears: which agent gets the next task, how do you verify completion, how do you build trust across skill types?
Pura adds economic coordination with three contracts:
OpenClawCapacityAdapter translates multi-dimensional skill metrics (throughput 50%, latency 30%, error rate 20%) into a single normalized score, EWMA-smoothed with α=0.3OpenClawCompletionVerifier uses EIP-712 dual-signature verification to record skill executions on-chainOpenClawReputationBridge feeds completion and failure events into the cross-domain ReputationLedgerAgents opt in by installing a Pura coordination skill that handles staking, capacity reporting, and attestation. The integration runs entirely on Base L2. OpenClaw's core is unchanged.
| Term | Plain English |
|---|---|
| Sink | A service provider (AI agent, relay, Lightning node) that receives payment for doing work |
| Source | An app or agent that pays for work to be done |
| Task type | A category of work (text generation, image creation, relay storage) |
| Capacity | How much work a provider can handle at once |
| Spare capacity | Declared capacity minus current workload. This drives routing. |
| Rebalance | Updating how payments are split based on current capacity across all participants |
| Epoch | A time window (typically 5 min) for measuring performance and updating prices |
| Pipeline | A multi-stage chain of pools where upstream congestion propagates backward |
| Term | Plain English |
|---|---|
| τ (temperature) | Measures variance across capacity reports. High τ = diverse capacities, routing spreads wide. Low τ = uniform capacities, routing concentrates. |
| V (virial ratio) | Throughput divided by bound capital. V = 1 is equilibrium. V > 1 is under-capitalized (bull). V < 1 is over-capitalized (stagnant). |
| P (osmotic pressure) | Buffer fill level (0 to 1). Drives drain and circuit breaker triggers. |
| Boltzmann weight | exp(c/τ): sinks with more spare capacity get exponentially more flow, modulated by temperature. |
| Adaptive demurrage | Decay rate on idle token balances that varies with the virial ratio. Pushes idle capital into circulation. |
| Circuit breaker | Five-phase state machine (Steady → Bull → Shock → Recovery/Collapse) that decouples pipeline stages under stress. |
| Term | Plain English |
|---|---|
| Token | A programmable unit of value on a blockchain |
| ERC-20 | The standard token interface on Ethereum. Defines transfer, approval, balance queries. |
| Super Token | A Superfluid-compatible token that supports streaming (continuous per-second flows) |
| Smart contract | A program on a blockchain that executes automatically when conditions are met |
| Staking | Locking tokens as collateral. In Pura, agents stake to declare capacity. |
| Slashing | Penalty: taking part of a stake for dishonest behavior |
| Gas | Fee paid per blockchain transaction. On Base L2, fractions of a cent. |
| Base | An Ethereum L2 built by Coinbase. Low fees, fast confirmations, Ethereum security. |
| Layer 2 | A chain that batches transactions and posts proofs to a main chain for security |
| Superfluid | Protocol for real-time token streaming. Pura uses its GDA for payment routing. |
| GDA | General Distribution Agreement. Superfluid's mechanism for splitting a stream among recipients proportionally. |
| Term | Plain English |
|---|---|
| EWMA | Exponentially Weighted Moving Average. Weights recent data more, preventing sudden suspicious capacity changes. |
| Commit-reveal | Two-step process: submit a sealed hash, then reveal the value. Prevents front-running. |
| EIP-712 | Standard for signing structured data off-chain. Used for attestations and receipts. |
| Attestation | A signed statement ("I have 500 units of capacity"). Verified on-chain. |
| Sybil resistance | Protection against fake identities. Pura's concave stake cap (square root) makes splitting unprofitable. |
| NIP | Nostr Implementation Possibility. A specification for Nostr protocol features. |