Slow at the counter
Most chains confirm block by block, so "final" means waiting minutes. Checkout and software agents cannot wait.
Proof of Balance
Payments that are fast, private, and final.
zkLoop Labs builds payment infrastructure for people, businesses, and AI agents. Every payment settles in about a second, carries no gas fee, and keeps balances and customers out of public view.
< 1 secto a final, certified payment
0gas fees for users and agents
100%of balances encrypted
Parallelunrelated payments never queue
The problem
Blockchains were not built to be payment rails.
Card networks are fast but rigid. Public blockchains are open but slow and transparent. Businesses need both speed and privacy.
Hard to scale
When every payment joins one global line, a sale in one shop queues behind a sale in another.
Too public
Shared ledgers expose revenue, prices, and customers to anyone, including competitors.
How it works
Prove, don't publish.
PoB replaces public numbers with mathematical proof. The network can verify every payment while learning almost nothing about it.
Sealed balances
Balances are stored as encrypted commitments. Each payment carries a zero-knowledge proof that value is conserved and nobody spends money they do not have.
Final in a moment
A payment is final once a quorum of independent validators certifies it, typically two network round trips. No confirmations, no reversals.
A graph, not a queue
The ledger is a graph of balances. Payments touching different balances proceed in parallel, so capacity grows with hardware instead of hitting a block-size cap.
No gas, ever
Nobody buys or budgets a gas token. Abuse is stopped by a private minimum-balance check, and fees are simple merchant settings.
Familiar tools
A standard EVM chain for developers, a plain REST API for merchants, and an agent interface for AI assistants. Chains can run private.
Trust nothing extra
The execution engine is treated as untrusted. Validators re-run and certify every transaction, so even a compromised engine cannot forge history or create money.
Programmable payments
Hold, settle, release.
Fuel, parking, rentals, bookings, and metered services do not know the final price up front. PoB builds preauthorization and capture into the payment itself.
Reserve the funds
The customer places funds in escrow with a merchant before the final amount is known.
Charge what was used
The merchant settles the actual amount. The difference returns to the customer in the same step, along with any fees and rewards.
Cancel cleanly
If the order is cancelled, the full hold goes back to the customer by rule, not by dispute or chargeback.
Payments for AI agents
Let agents pay, within limits you set.
Agents transact fast and unattended. They need answers they can act on, and users need guarantees that hold even when an agent reasons badly.
- Policy enforced by the rail. Approved merchants, maximum spend, and expiry are checked by tokens and contracts, not by the model.
- Escrow by default. Agents hold now and settle when the outcome is known.
- No gas ceremony. Agents never hold a special token or guess a fee.
- Any protocol. The same hold works through MCP tools, MPP, and x402.
Example: booking a meeting room
You approve an assistant once: this merchant, up to $200, for the next 30 days.
The assistant searches, gets a quote, and reserves the room. The merchant places a hold.
After check-out the merchant settles the real amount and the rest returns to you. If plans change, the hold is released.
If the assistant is ever tricked into asking for more, its token simply refuses.
Compliance
Verified participation, enforced where payments become valid.
A payment system must do more than prove money was not created from nothing. The operator also needs to know who is participating and to decide which payments are allowed.
Identity-bound participation
The operator verifies each customer or merchant first. Every identifier is tied to that verified identity, so generating a new key grants no new rights.
Restrictions that follow the customer
A restriction applies to everything associated with the customer. Validators stop existing value from being relabelled to evade it, without taking the customer's keys.
Enforced at certification
Validators check the eligibility of both sender and recipient before certifying a payment. Going through a different API or network route cannot bypass the check.
Noncustodial by design
Users keep their wallet keys. Revocation works by refusing future certification, and services can act only through operations the user delegated.
Narrow delegation
A processing service can be allowed to combine or split balances within one identity, while a transfer to another identity needs separate approval.
Privacy with records
Business privacy protects data from the public and other participants. The operator keeps the records its authorized services and compliance duties require.
An architecture, not an approval. This describes how PoB can support regulated operation. Adopting it is not regulatory approval, and accurate onboarding remains essential. Section 8 of the whitepaper covers the design in detail.
Where PoB fits best
Semi-closed-loop payment systems.
An operator issues stored value that customers spend at a defined set of merchants. Malls, fuel networks, transit, campuses, games, and marketplaces all work this way, and card rails serve them poorly.
Operator rules, user-held keys
The operator sets admission and payment rules. Customers keep their own wallet keys, and the validator quorum enforces integrity.
Economics for small payments
No interchange percentage and no gas auction. A 40-cent locker rental costs what the infrastructure costs.
Privacy between competitors
Merchants in the same loop cannot see each other's volumes, prices, or customers. Each reads only its own activity.
Programmable stored value
Expiry, merchant scoping, promotions, and family or fleet spending limits are rules in the contract, not after-the-fact monitoring.
Auditable float
Every unit is backed by an attested cash-in, and the conservation proof lets anyone audit the total without opening a single balance.
One balance, many chains
Each business can run its own private chain while one customer balance pays across all of them, with no bridges.
What PoB is, and is not
Infrastructure you deploy, not a network you join.
An operator runs the stack, sets admission policy, arranges backing and redemption, and chooses its validators. Users keep their keys inside that defined economy.
PoB is not an anonymity coin. It hides balances, amounts, counterparties, and activity patterns from the public and from other participants. It does not hide participants from the operator or from lawful audit.
It is not a global currency. Tokens in a loop represent attested, redeemable stored value. The system is in active development, with demonstration deployments today.
See how PoB could power your payments.
The whitepaper explains the technology end to end in plain language. It is available on request.