Direct merchant payments
The first product surface is ordinary payment from a customer to a merchant. PoB keeps the user experience close to normal checkout while adding private proof and programmable settlement.
Most blockchains are poor payment rails in the ordinary merchant sense. They are slow at the checkout boundary, hard to scale because execution is usually serial, and too public for businesses that do not want competitors reading every transaction. zkLoop Labs is building PoB technology to address those limits directly.
The first product surface is ordinary payment from a customer to a merchant. PoB keeps the user experience close to normal checkout while adding private proof and programmable settlement.
PoB is built around Proof of Balance: a zero-knowledge proof that a payer has enough funds for a transaction without exposing the full balance or making the merchant's transaction stream transparent to competitors. Read the white paper.
Merchant contracts support hold, settle, and release, matching
common preauthorization and capture flows in bookings, marketplaces, deposits, rentals, and metered
business services.
AI agents can act within user-approved limits: who they may pay, how much they may authorize, when they must ask, and how a held payment can be settled.
An EVM-compatible execution surface backed by a custom PoBEVM engine. It keeps familiar JSON-RPC and smart-contract semantics while local execution replicas, batching, and conflict detection make it possible to process non-conflicting payments in parallel. Read the white paper.
PoBERC20 contracts support direct merchant payment with fee and reward handling, giving the platform a normal payment primitive before adding more complex authorization flows.
Tokens can move through merchant escrow contracts. A customer opens a hold, the merchant later settles the actual amount, and any unused balance can be released or refunded.
Wallet access is tokenized. One-time tokens can be exchanged into long-term bearer tokens for connected applications, while sensitive wallet material stays server-side and HSM-oriented.
We treat MPP and x402 as payment-boundary protocols, not as replacements for merchant business APIs. The same PoB hold can be presented through multiple external payment schemes.
ChatGPT and other MCP clients call business-level tools such as search, quote, reserve, extend, cancel, and policy management. Payments stay pluggable behind those tools.
A booking can schedule a one-time follow-up near a deadline. The worker evaluates business state and user policy, then settles, releases, asks the user, or retries once.
An AI assistant books a private meeting room for a team. The merchant places a hold for the reservation, then settles the actual amount after check-out or releases the hold if cancellation rules allow it.
A customer orders a custom digital service. Funds are held when the order starts, settled when the work is accepted, or released if the merchant cannot deliver.
The user can allow an agent to book only approved merchants, within a maximum hold amount, with explicit approval required before any final settlement above the policy limit.
Agents can act only within approved limits such as max spend, max duration, and trusted service scope.
Merchants should not need to become blockchain experts to accept private, agent-driven payment.
The same internal hold/settle primitive can support proprietary APIs, MPP, x402, and future schemes.
Proof of Balance lets a payment network verify enough information without publishing unnecessary state.
zkLoop Labs starts from the simplest serious payment requirement: a customer pays a merchant privately and efficiently. Escrow then extends the same payment foundation to business flows with deposits, uncertain final amounts, cancellation rules, delivery acceptance, and agent-managed policy. Agentic payment is the next step: software agents can search, book, authorize holds, and settle payments within boundaries the user approved in advance.