Every live diagram in one place

This is the homepage opener. It shows the shortest explanation of the hosted product: one agent, one gateway, four providers, Lightning on the back end, and a marketplace loop when your own agent starts earning.

This is the whole stack in one frame. It shows how the gateway, OpenClaw skill, Lightning settlement, contracts, dashboard, and reference apps fit together without forcing you to read five pages first.

This is the failure case Pura is built around. Work and money keep moving into a saturated service because ordinary payment rails do not carry a live capacity signal.

This is the protocol answer to the overload problem. Payment share shifts toward sinks that still have room instead of blindly paying whoever was chosen first.

This diagram splits the system into capacity, verification, pricing, and settlement. It is the quickest way to see where each contract family sits and how pressure moves up and down the stack.

Every interaction in Pura turns into one of five typed objects. This is the data model view of the protocol rather than the money-flow view.

This is the high-level flow: declare, verify, price, route, buffer. It is the shortest route through the core mechanism before the explainer dives into each step.

This diagram explains why the protocol does not trust raw self-reporting. Capacity claims are bounded by stake so fake abundance costs real capital.

This sequence turns finished work into a receipt both sides must sign. It is the core honesty mechanism behind routing weights, slashing, and reputation.

Price rises in two places: globally when the whole system is busy and locally when one sink backs up. This is how demand gets pushed away from bottlenecks without a central operator.

Incoming flow lands in a pool and gets split according to spare capacity. This diagram is the money router at the center of the protocol.

When every sink is full, flow does not disappear or keep pretending everything is fine. It lands in escrow until capacity returns or the system signals the source to stop.

This frame adds the physics analogy on top of the routing core. Variance becomes temperature, capital balance becomes the virial ratio, and stress turns into circuit-breaker state.

Idle balances decay faster when the system is over-capitalized. This closes the loop between throughput, bound capital, and the cost of sitting on tokens.

This sequence shows how a failing stage gets isolated before it drags the rest of the pipeline down. It is the protocol's answer to cascade failure.

This shows how an existing NIP-90 data vending machine can plug into Pura without rewriting the service itself. Capacity, verification, and pricing sit in sidecar contracts around the DVM.

Pura does not bet on one payment rail. This diagram shows Lightning, Superfluid, and direct ERC-20 settlement living behind one routing interface.

This is the no-commitment path into the protocol. A local sidecar simulates the routing and monitoring logic against real workload before capital goes on-chain.

This is the expansion frame. It shows that the core declare-verify-price-route-buffer loop is not tied to one product category or one protocol.

This diagram shows how Lightning nodes can expose fresh capacity signals without exposing individual channel balances. Routing income then follows verified ability to move payments.

This is the relay version of the same story: declare capacity, price congestion, and pay relays for real throughput instead of hoping volunteer infrastructure scales forever.

This frame shows how performance in one domain can matter in another. Reputation becomes portable instead of getting trapped inside one marketplace or protocol silo.

This sequence shows how an OpenClaw skill execution becomes a priced, verified, reputation-bearing action inside Pura while the framework itself stays unchanged.