A payment loop for agent services
Notes from 0G FlowPay, a testnet prototype connecting service delivery, signed balances, and settlement.
A service used by an agent may produce results gradually. Settling every small interaction on-chain adds work to the service loop. Settling only at the end raises another question: what record can each party retain while delivery is still in progress?
0G FlowPay explores this through a testnet payment-channel prototype. Consumer and provider agents exchange signed off-chain balance updates, while a Solidity contract provides deposit, close, and dispute operations.
Delivery and accounting
The signed balance represents an accounting state that can be carried forward as the service proceeds. Instead of submitting a transaction for every update, the participants retain signed state and later use the channel’s settlement path.
The prototype also connects service evidence to 0G data availability. An upload and its data pointer or hash provide a way to refer to recorded evidence from the surrounding workflow.
These pieces serve different purposes. A signature authenticates an accounting update. A data reference identifies stored evidence. The contract applies its settlement rules. None of these checks automatically establishes that a service result was useful or correct.
Making the loop observable
The repository combines the Solidity channel with Python consumer and provider agents, a Flask service, and a React demonstration interface. This makes it possible to follow the sequence from a request through delivery and balance updates to settlement.
The question I find useful is whether the parties can reconstruct what happened when the loop stops early. Which state was signed? Which evidence was recorded? Which state does the contract accept? Those questions are more concrete than a general promise of “trustless” service delivery.
Prototype boundaries
This is testnet work. It is not an audited payment system, and the demonstration does not establish production safety. Contract behavior, evidence availability, signature handling, and the rules for disputing a result all need separate evaluation.
The prototype is useful because it brings those questions into one executable workflow. It gives the next round of engineering a specific sequence to inspect.
See the source repository.