ZOOBC / AGENT TREASURY INFRASTRUCTURE
Give your AI agent money. Keep a ceiling it cannot break.
ZooBC gives autonomous agents room to spend, hire, and transact inside a budget boundary enforced by the network, not by the agent's self-control. A dependency-free Python reference proves the complete transaction loop against the live testnet.
- LIMIT
- Locked up front
- CONTROL
- Human-signed increases
- RECORD
- Independently verifiable
START HERE / THREE LIVE RESOURCES
From discovery to a verified transaction.
An agent or developer can move from one discovery file to a confirmed testnet transaction without a browser, an SDK, or a dependency install.
Give your agent one file.
llms.txt identifies the live testnet, essential endpoints, signing model, faucet, and the next document an agent should read.
Open llms.txt ↗02 / IMPLEMENTRead the complete agent guide.
AGENTS.md documents transaction construction, scheduled allowances, expiring escrow, multisig spending, audit queries, and known gaps.
Read AGENTS.md ↗03 / EXECUTERun the working reference.
The dependency-free Python file generates a key, claims test coins, estimates the fee, signs, submits, confirms, and verifies a real transaction.
Open Python reference ↗THE UNSOLVED CONTROL LAYER
Autonomy should not require a blank check.
AI systems are gaining their own tasks, tools, and purchasing decisions. The difficult part is giving them financial agency without watching every move. ZooBC turns the spending boundary into network state: the agent can act freely inside it, but cannot rewrite it.
Software proposes. The ledger enforces.
THREE CONTROLS + THREE CAPABILITIES
What the network enforces, and what applications build around it.
Locked allowances, expiring escrow, and multisig thresholds are controls. Commerce, token settlement, and declared identity are capabilities assembled from ZooBC transactions and data.
An allowance your AI agent cannot exceed.
A scheduled transfer with funding mode 0 locks the lifetime allowance at creation. The agent receives a defined amount on each release, while raising the total requires a new owner-authorized transaction. The remainder can be revoked or reassigned.
A payment can wait for you without trapping your money.
An agent can propose a payment that remains pending until its named approver accepts or rejects it. The timeout is an absolute Unix timestamp. When it passes unanswered, the amount and commission return automatically on-chain.
Require more than one signature for larger payments.
A multisig transfer executes only after the defined N-of-M signature threshold is met. Applications can let an agent handle small transactions directly while routing larger commitments through independent approvers.
Agents can transact and leave verifiable receipts.
Agent-to-agent commerce is a use case built from signed transactions and the controls above. Anyone can query the transaction hash, block confirmation, account history, and balance movements without relying on either agent's private logs.
Settle tiny machine-to-machine payments on-chain.
Micropayments are a use case built on ZBC, user-issued tokens, signed transfers, and the on-chain exchange. Applications can use those rails to settle lookups, API calls, or other machine work while preserving a public payment record.
Publish what an agent claims to be.
An agent can write signed dataset records describing its operator, purpose, capabilities, endpoint, and budget schedule. This is a verifiable claim by the account, not an identity primitive the chain enforces. Applications must still decide whether to trust it.
ONE AGENT / TWO ECONOMIC LAYERS
See what the model consumed and what the agent spent.
A useful agent has two meters. Its model provider measures inference usage. Its ZooBC account records value spent while acting on the world. An application can reconcile both around the same agent and workflow.
Tokens, calls, or compute reported by the provider.
Payments, escrow, schedules, fees, and balance movements recorded on-chain.
Reconcile model usage with independently verifiable chain spending.
Enforcement boundary: ZooBC enforces the chain-side allowance and transaction rules. The model provider remains the source of truth for inference metering, so application code must join the two records.
THE ACTUAL TRANSACTION PATH
A bounded payment from schedule to ledger proof.
These are the real ZooBC operations behind the pattern. Application code still chooses the specialist, validates the work, and decides which signatures count.
- 01 / TX TYPE 29
Lock the allowance.
scheduled-transfer
funding_mode: 0The owner pre-locks the total amount. Changing the lifetime ceiling requires a new transaction.
→ - 02 / ESCROW
Propose the payment.
zbc-send
--escrow-approverThe agent names an approver and supplies an absolute Unix timeout for automatic return.
→ - 03 / MULTISIG
Meet the threshold.
zbc-cli multisig
2 of 3 exampleFor a larger payment, the application validates delivery and collects two of three required signatures before the inner transfer executes.
→ - 04 / PUBLIC API / TESTNET
Settle and verify.
approve-escrow approval: 0
GET https://zoobc.network/api/v1/transactions/{hash}
GET https://zoobc.network/api/v1/accounts/{address}/historyApproval releases the funds. Timeout returns them. The transaction and account history prove which path occurred.
✓
HOW IT WORKS
Four steps from first file to verified transaction.
- 01
Read one file
Start with llms.txt so the agent discovers the live chain, guide, API, and testnet rules.
- 02
Run the reference
Execute the Python example to generate, fund, sign, submit, confirm, and verify a transaction.
- 03
Add controls
Use a locked schedule, expiring escrow, or multisig threshold for the workflow's actual risk.
- 04
Verify the ledger
Query the transaction hash, account history, and movements instead of trusting a submit response.
HARD QUESTIONS
What the boundary solves and what it does not.
The ledger can enforce financial conditions. It cannot replace careful agent design, identity claims, or result validation.
01Does a spending ceiling make an agent safe?
It limits the amount at risk; it does not guarantee that every purchase is wise. Task permissions, vendor selection, result validation, and operational monitoring still belong in the agent system around the wallet.
02Can the agent raise its own allowance?
Not under the bounded pattern described here. Increasing the committed ceiling requires a new transaction authorized by the account that controls the allowance.
03What happens when a proposed payment is never approved?
A proposal can carry an expiry. If approval does not arrive by that deadline, the escrowed value follows its configured return path instead of remaining pending indefinitely.
04What proves which agent authorized an action?
The cryptographic signature proves that the holder of a particular key authorized the message or transaction. Claims about the operator, purpose, and reputation of that key still need clear signed records and independent verification.
05Is this an agent product or a set of blockchain primitives?
Today the foundation is the ZooBC transaction layer: accounts, signatures, escrow, multisignature approval, tokens, and an auditable ledger. A production agent integration still needs software that assembles those primitives for its specific workflow.
TESTNET IS LIVE
Run the proof, then add the boundary.
Start with the working reference, confirm a real testnet transaction, then add the allowance, approval, and audit controls your workflow needs.