Verifiable Atomic Proof-of-Service Completion for Agent Transactions on L2
A standardized, minimal primitive enabling agents to stake collateral against verifiable, atomic proofs of discrete, external computational steps, thereby de-risking the core economic transaction loop for agent-to-agent services.
How can AI agents pay each other for completed work without risking non-payment or fake results?
A standardized Proof-of-Service Completion (PoSC) protocol lets a client lock funds in an L2 smart contract that only releases them once the paid agent submits a signed proof (input hash, output hash, and endpoint) of the completed task. An oracle verifies the proof's signature and format before settlement; invalid or missing proofs trigger slashing of the agent's staked collateral instead of payout. It targets developers building production agent-to-agent services who need guaranteed, verifiable billing for discrete off-chain computations like API calls, rather than a full workflow-tracking ledger.
Process flow
Who it's for
AI agents/developers building production systems that require reliable, paid, computational outputs.
Why they need it
The core need is a guaranteed mechanism to prove that an expensive, non-deterministic computation (like calling a specific external API) was completed correctly and verifiably, and that the payment for this service can be settled against that proof. Current systems lack a standardized, on-chain mechanism to stake collateral against the result of an off-chain, discrete process, leading to settlement risk and unreliable billing.
What it is
A standardized 'Proof-of-Service Completion' (PoSC) protocol. This mechanism allows a client to lock funds, which are then staked against a promise of work completion. The settlement is triggered only upon receipt and verification of a standardized, verifiable proof (e.g., a signed hash of the output + input parameters) from the agent's execution environment.
How it works
- Commitment: Client locks funds/stakes collateral via the PoSC contract, initiating the request.
- Execution: The agent performs the compute off-chain, focusing on a single, verifiable atomic step (e.g., API call).
- Proof Generation: The agent generates a standardized proof (e.g., a JSON structure containing the API endpoint, the input payload hash, the output hash, and the agent's private signature) and submits it to the Proof Oracle service.
- Verification & Settlement: The PoSC contract's oracle verifies the proof's format and signature. If valid, the funds are released to the agent; if invalid or timed out, the collateral is slashed.
Differentiation
We pivot away from building a full 'Agent State Ledger' and focus laser-like on the settlement guarantee for atomic steps. Existing systems manage workflows or paywalls. We solve the hardest, most concrete problem: creating an on-chain economic guarantee for the result of an asynchronous, discrete external computation. This is a foundational primitive for any agent economy.
Implementation sketch
- Design the minimal PoSC smart contract interface (Solidity/Rust) on Base/L2:
stake(amount),submit_proof(proof_data),verify_and_release(proof_data). Focus solely on time-locks and slashing logic. - Develop the 'Proof Oracle' service (backend): This service accepts the agent's proof, verifies its cryptographic soundness (signature, format), and submits the final verification status transaction to the L2.
- Create a minimal SDK for agents to interact with the PoSC contract, facilitating the staking and proof submission lifecycle for a single, defined API call.
First step: Draft the Solidity interface and core logic for the PoSC smart contract, focusing only on the stake and verify_and_release functions, assuming an external oracle will handle the proof submission.
Remaining risks
- Smart Contract Attack Surface: Despite focusing on a minimal primitive, the PoSC contract remains a high-value target. Bugs in the slashing logic, time-lock mechanisms, or oracle interaction could lead to catastrophic loss of staked funds, regardless of how well the proof generation works. — Mandatory, multi-stage formal verification (e.g., Certora) of the core contract logic, followed by bug bounty programs focused exclusively on the state transition and fund transfer mechanisms.
- Oracle Centralization/Collusion: The 'Proof Oracle' service becomes the single point of failure and trust assumption. If the oracle is compromised, or if multiple oracles collude to accept invalid proofs, the entire economic guarantee fails, leading to improper fund release or slashing. — Implement a decentralized oracle network (e.g., Chainlink structure) requiring consensus from N out of M independent, staked oracles to validate the proof before the PoSC contract executes the settlement.
- Adoption Friction (The 'Last Mile' Problem): Even if the primitive is technically sound, developers may prefer integrating with existing, albeit imperfect, tooling (LangSmith, etc.) because the overhead of integrating a new, mandatory PoSC step into their existing, complex pipelines is too high. — Develop a high-level SDK/middleware that abstracts the PoSC complexity, allowing developers to simply wrap existing function calls with a single, declarative PoSC decorator, making integration feel like a minor configuration change rather than a core architectural overhaul.
Watch for: Any indication from the developer community that the cost or complexity of generating the required cryptographic proof (hashing inputs/outputs, signing) for a single atomic step exceeds the economic benefit derived from the settlement guarantee. Kill criterion: If a major, established infrastructure player (e.g., OpenAI, Anthropic, or a major cloud provider) announces a native, non-crypto, enterprise-grade solution that solves the 'guaranteed output' problem without requiring on-chain collateralization, it signals that the market values operational simplicity over decentralized settlement guarantees.
Sources the council used
Real-world evidence that grounded this idea — judge it for yourself.