Why coordination belongs to the Protocol
Consider the alternative. If every provider handled its own billing, an agent using ten services would hold ten accounts, ten credentials, and ten separate trust assumptions. Adding a provider would mean a new commercial relationship. Switching would mean unwinding one. Every provider would be a point of failure for the agent’s ability to transact at all. That model does not survive contact with autonomous operation. It puts a negotiation in the path of every new counterparty, and negotiation is the thing an agent cannot do unsupervised. Moving coordination into the Protocol removes the negotiation. A participant funds once. Consumption draws against that balance wherever it happens on the network. A provider is paid by the Protocol on confirmed completion rather than by the requester on trust. Neither side has to have met.Escrow
Escrow is the mechanism that makes this safe in both directions. When an Action is registered, its fee is committed on chain before work begins. The requester’s funds are locked and cannot be spent elsewhere. The operator’s compensation is real but contingent on completion. If the Action completes and is confirmed, the escrow releases to the SuperNodes that served it. If it fails or expires, the escrow returns to the requester. Neither outcome depends on either party’s cooperation after the fact, because the condition is evaluated against the on-chain record. This is the same discipline documented in the Action Lifecycle. Economic Coordination generalizes it rather than introducing a second payment path.Settlement is gated, not promised
Settlement follows confirmation. Payment flows for work the chain can see was completed. The consequence is that a requester never needs to trust an operator’s invoice, and an operator never needs to chase a payment. There is no accounts-receivable relationship between participants, because the Protocol is the counterparty to both sides of the exchange. Fees are quoted in LUME and denominated by the resource consumed. Where the fee goes once released, and how it splits between operators, validators, and the burn, is documented in Protocol Economics.Two settlement modes, kept separate
Not all obligations have the same shape, and the Protocol does not fund them the same way. Metered settlement covers work with a defined beginning and end. A request is escrowed, performed, confirmed, and settled. Cost tracks consumption. Sustained funding covers obligations that outlive the payment that created them. Permanent storage is the clearest case. A one-time fee cannot pay an operator to hold data indefinitely, because the obligation continues after the payment is exhausted. Everlight is the mechanism for that class, funded through protocol reward flows, fee shares, and endowment yield. Conflating the two would be a design error in both directions. Per-use fees cannot fund permanence. An endowment cannot meter individual requests. Keeping them separate is what allows the Protocol to make a durable promise without accumulating an unpriced liability.Relationship to Protocol Services
Every Protocol Service is priced, escrowed, and settled through the same path. A service is not a separate商 arrangement with its own billing. It is an Action type with a fee schedule. The practical effect for a developer is that adding a capability to an application does not add a commercial integration. If the capability exists as a Protocol Service, it is already payable from the same balance, on the same terms, with the same evidence.LUME
The asset fees are denominated and settled in.
Protocol Economics
How fees are distributed once settled.