You set up a Superfluid stream to pay an LLM provider. Fixed rate, runs 24/7. Friday night the provider goes down. The stream keeps paying. By Monday you've burned $200 on a service that returned nothing for 60 hours.
Streaming payments work. They just have no feedback loop. Pura adds one.
Consider an agent economy where a client streams payments to a pool of service providers. The stream distributes according to fixed weights. Maybe equal shares, maybe proportional to some initial reputation score. Provider A gets 40%, Provider B gets 35%, Provider C gets 25%.
Provider B goes down. What happens?
The stream keeps flowing. 35% of the payment continues accruing to an agent that is not doing work. The client does not know. The other providers do not know. There is no feedback mechanism in the payment protocol to detect that the payment is going somewhere useless.
Eventually someone notices. Manually. And manually adjusts the weights. Or the client kills the stream and starts a new one. None of this is automated. None of it happens at the speed that agent economies need to operate.
Backpressure routing provides the feedback mechanism that streaming payments lack.
In Pura, the weights in a Superfluid GDA pool are not static. They are dynamically computed from each agent's verified spare capacity. The protocol tracks how much capacity each agent declared, how many tasks it actually completed (via dual-signed receipts), and computes an EWMA-smoothed capacity signal that resists manipulation.
When Provider B stops completing tasks, its capacity signal decays. The GDA pool rebalances. Its share of the payment stream drops. Providers A and C absorb the difference, proportional to their own spare capacity.
No human intervention. No off-chain monitoring service. The mechanism is on-chain and the rebalancing happens whenever someone calls the rebalance function (which anyone can do, permissionlessly).
Capacity-weighted routing handles the allocation problem. But there is a second problem: when all providers are near capacity, how do you signal that demand needs to decrease?
Pura adds dynamic pricing. Each agent's price follows a curve based on utilization. At low utilization, the price is near the base fee. As utilization rises, the price increases along an EIP-1559-style curve. At full capacity, the price is at maximum.
This creates back-pressure in the economic sense. Demand for overloaded agents becomes expensive. Rational clients shift to cheaper (less loaded) agents. The system finds an equilibrium that static pricing cannot reach.
There is a scenario dynamic pricing does not fully handle: every agent in the pool is at capacity and new demand arrives. In a data network, you would drop the packet. In a payment network, dropping money is unacceptable.
Pura routes overflow to an escrow buffer. Payments sit there until capacity frees up. The escrow acts like a shock absorber. It smooths out demand spikes without losing funds.
The buffer has a drain rate proportional to available capacity. As agents complete work and free up room, escrowed funds flow to them. If the demand spike is temporary, the buffer empties naturally. If demand persistently exceeds capacity, the buffer fills up and the pricing curve pushes back harder.
If you are using Superfluid for agent payments today, Pura adds automatic rerouting when a provider degrades and price signals that respond to real-time congestion. Overflow demand goes to a buffer instead of being dropped or misdirected.
The Pura SDK works alongside the Superfluid SDK. You create a BackpressurePool (which wraps a GDA pool), register agents as sinks with their capacity, and the protocol handles rebalancing. The TypeScript for setting this up is about 20 lines.
pura.xyz/docs/getting-started-defi | github.com/puraxyz/puraxyz