The idea
Useful autonomy. Explicit boundaries.
An agent might prepare a report, buy an approved service or complete a funded task. These are different jobs: knowing who the agent is does not give it permission to spend, and making a payment does not prove that the work was delivered.
A concrete example · not a live service
A shop asks its agent for Friday’s stock report.
The shop owner agrees on the task before the agent starts. The same agreement explains what counts as completion and how either side can exit.
- The job and its limits
- Read one approved inventory file and deliver a report by Friday at 17:00 UTC. No purchases, bank access or customer messages are permitted.
- What counts as evidence
- The agreed report file, its recorded fingerprint, and the named owner’s signed review. A fingerprint identifies the file; it does not prove that its contents are correct.
- Who supplies the funds
- The company sets aside 100 protected units and a separate 20-unit reserve for a precisely defined breach. A sponsor separately supplies up to 10 reward units. These are example units, not a deposit offer.
- What happens afterward
- Completion follows the signed settlement and claim rules. A proven, configured objective breach can use only the additional remedy reserve. Missing evidence or a missed deadline follows the agreed exit rules, not an automatic seizure of principal.
This illustrates the Accountability design. Partnership Bonds require mutual settlement consent and have no unilateral slash. Rewards are not guaranteed interest; funding, evidence, sponsor approval and claim deadlines still apply.
Vaultfire gives those questions a record and a set of rules that software can check. Its building blocks include permission limits, signed evidence, accountability bonds, and receipts you can inspect later. A receipt is a record of a particular operation, not a certificate that everything is safe.
Why use this instead of an ordinary promise?
- Know the limits before acting. Agree on the task, permissions, deadlines and maximum amounts instead of leaving them vague.
- Check what happened. Use agreed evidence and recorded results, rather than relying only on someone’s description.
- Keep a defined exit. Recovery and dispute rules are part of the design, not a promise that an operator will always help later.
This is not a way to guarantee that an AI will never make a mistake or cause harm. Software can enforce only the rules and evidence it actually receives; important real-world facts still depend on people, evidence providers and review.
The whole picture
Follow the money and the responsibility.
The financial system has six jobs. Bonds are the commitment layer within that system; they do not replace the treasury, spending rules, payment process or financial books.
- Treasury and incoming funds
Bring money in
Start with approved deposits and top-ups in an owner-controlled treasury. Decide which network and asset are allowed.
- Permissions before approval
Set the agent’s limits
Name the agent, recipient, action, amount, fee ceiling and expiry. A useful assistant does not need unlimited access to money.
- Payments and escrow
Pay or hold for a task
Make an exact authorized payment, or use escrow to hold funds under agreed completion and refund rules.
- How the bonds work
Back commitments with bonds
Accountability and Partnership Bonds define funded commitments, evidence and exits. Principal, remedies and sponsor rewards have different jobs.
- Accounting and receipts
Keep the books balanced
Track what is available, reserved, pending, spent, refunded or paid in fees. A receipt alone is not the whole financial record.
- Revocation and recovery
Stop access and recover
Revoke permissions, pause affected actions and follow the supported refund or withdrawal path. Inspect an interrupted operation before retrying.
What is connected today?
The maintained local journey connects customer invoices, deposits, exact token payments, escrow, approvals and accounting to invoice-linked bonds, separate sponsor rewards and recovery on one disposable network. Invoice funds stay held until observed finality; payer acceptance and refunds remain separate. Delivery and scores are synthetic examples, not real merchant delivery.
This is not a qualified production service. Other module and network lifecycles retain their own evidence; Base/USDC, Solana finance and operational production custody need separate qualification. Optional native late-event cover is separately prefunded, not automatic insurance. Trading, lending and yield products are not implied. Read the exact financial capability matrix.
For APIs, check each V2 operation’s price and availability. V3 source availability does not turn on V3 payments, and the public MCP server is still read-only.
The flagship commitment layer
A bond backs an agreement. It is not the whole wallet.
Here, “bond” does not mean a government bond or a guaranteed investment return. It means an agreement backed by specified funds and conditions. The V3 design separates an original deposit, an additional remedy reserve, and money supplied for rewards.
- Agree before funding.
Identify the people and agent involved, what is allowed, what evidence counts, the deadlines, and which funds may be used. The required parties approve the exact terms.
- Keep the funds separate.
The main deposit is not the reward pot. Any extra reserve for a defined breach has its own limit. No score creates an unlimited claim.
- Record and review the evidence.
Relevant reports are signed. Current flourishing reports and corrections require the named human’s consent, the evidence-provider quorum, and exact sponsor approval. A signature records approval; it does not turn an inaccurate report into truth.
- Use the agreed outcome or recovery path.
A valid claim, challenge, reward or expiry follows its specific rules. Money is withdrawn through the supported claim or recovery path, which may involve deadlines. It is not always immediately withdrawable.
Two related kinds of agreement
Accountability Bonds focus on an agent’s defined obligations. Partnership Bonds record an agreement between counterparties and include their consent, funding and exit conditions. A partnership label alone does not prove that people are independent or that an agreement is fair.
Partnership Bonds do not provide a unilateral enforcement slash. The reserve-backed objective remedy described here applies to the relevant Accountability design, not automatically to every bond. Base and Solana also have documented differences; one network’s test result does not automatically qualify another network.
Bond funding, explained
Three pots. Three different jobs.
These are the bond’s funding buckets, not a claim that all treasury funds are locked into bonds. Payments and task escrow have their own balances and settlement rules.
Principal
The original deposit. In this V3 design, a lower flourishing score does not take money from this pot. Recovery still follows the agreement’s rules and deadlines.
Remedy reserve
Separate, capped funds that can cover a specifically defined breach if its objective evidence and enforcement conditions are met. A disappointing score alone is not that evidence.
Sponsor pot
Money separately supplied for eligible rewards. Rewards depend on the actual policy, evidence, timing and available cap. They cannot be invented or borrowed from principal.
A worked example, not a return offer
Imagine an agreement with 100 units of principal, 20 units of remedy reserve, and 10 units supplied by a sponsor. That is 130 units in three separate places. “Units” are illustrative, not a quoted dollar value or an invitation to deposit.
If the agreed rules permit a 5-unit remedy for a proven breach, it can come only from the 20-unit reserve, leaving 15 there. The original 100 is not reduced because of a metric score. If the reward rules separately allow a 4-unit reward, it comes from the sponsor’s 10, leaving 6 there.
The accounting still adds up: 100 principal + 15 reserve remaining + 5 remedy + 6 sponsor funds remaining + 4 rewards = 130. This example explains which pot pays; it is not a forecast, a current rate, or proof that a particular claim would qualify.
Not used to pay remedies or rewards.
An eligible, evidenced breach triggers only the agreed remedy.
Rewards require the policy’s signed observations and claim rules.
130 in = 130 accounted for. No bucket borrows from the original deposit. Eligibility, timing and recovery follow the actual contract; this example is not a guaranteed payout. Partnership Bonds do not have this unilateral reserve remedy.
What is a “flourishing” score?
It is a bounded input to a reward policy, not a universal measure of a person’s worth. The policy uses defined dimensions and signed reports to calculate eligible sponsor-funded rewards. A decline can reduce or suppress rewards; it does not automatically slash principal or prove a breach.
People and evidence providers can still make mistakes or collude. The named human must approve the report, and partnership recipients must use separate addresses, but those rules do not establish truth or prove that different addresses have different owners. Inspect the exact bond mechanics and economic limits.
Your first visit
Start with reading, not sending money.
I want to understand it
You are in the right place. Read the example above, then check the release status. No account, coding software, wallet, private key or funding is needed to read the public information.
See what is available and what is blockedI want my AI assistant to inspect it
Use the read-only brief below. A compatible AI client can discover the tools and explain the evidence. This does not give it permission to sign or spend.
Use the agent starting pathI am building an integration
The developer path lists the software needed to run an example on your own machine. It uses disposable local testing, not a funded V3 deployment. Installation and test execution are separate steps.
Open the developer getting-started guideWhat should I expect to pay?
The public guide and current read-only MCP tools do not require a funded wallet or a V3 payment. Running software locally uses your own computer or hosting resources. Separate live V2 operations can have their own prices and network fees; do not confuse those with this V3 review path.
Do not send funds just to complete this guide. If a tool asks for your seed phrase or private key, stop. If a step does not match the stated release, network and payment status, return to the release information before proceeding.
For AI agents and their humans
Inspect first. No signing permission implied.
MCP is a standard that lets some AI applications call external tools. Vaultfire’s published server exposes five read-only tools for discovery and inspection. It does not sign transactions, make payments, or run V3 contracts.
- Check whether your AI application supports a remote MCP server using Streamable HTTP. Setup differs by application; not every chat app supports it.
- If supported, use
https://theloopbreaker.com/api/mcpas the server address. Follow your client’s own connection instructions. Opening this address in a browser is not the same as connecting an MCP client. - Ask the agent to identify the release, network, available operations and limitations before suggesting any action. Use the brief below if helpful.
- If the connection is unsupported or fails, use the public discovery document and documentation instead. A failed connection is not permission to switch to signing or payment.
Read or manually copy the agent brief
Help me inspect Vaultfire, using read-only information. Start with https://theloopbreaker.com/.well-known/agent.json MCP endpoint, if your client supports Streamable HTTP: https://theloopbreaker.com/api/mcp Human guide: https://theloopbreaker.com/how-it-works Financial system brief: https://theloopbreaker.com/docs/financial-system.md Financial scope and gaps: https://theloopbreaker.com/v3/finance MCP documentation: https://theloopbreaker.com/docs/mcp.md Explain the system in this order: incoming funds, agent permissions, payments and escrow, bonds, balanced accounting, then revocation and recovery. Distinguish an owner deposit from customer income, payment settlement from merchant delivery, and separate bond tests from an integrated finance journey. Tell me what is actually available, which release and network it uses, what evidence supports it, and what remains blocked. The published MCP tools are read-only. Do not sign transactions, send payments, request private keys, or claim that V3 is activated. If you cannot connect, say so and use the public documentation instead. Explain your findings in plain English.
Read the agent discovery document · Read setup and protocol details · Inspect the A2A capability card
The MCP documentation distinguishes demonstrated responses from declared schema records. A listed schema, an A2A skill description, or source code does not by itself mean an operation is live or that an integration has passed acceptance.
Limits, privacy and recovery
Know what happens when something does not work.
- What if the AI performs badly?
- A poor outcome is not automatically an enforceable breach. The agreed obligation, evidence source, remedy cap and time window determine what the contract can enforce. Some harms are outside those rules.
- What if a report is wrong or missing?
- Reports and corrections have authorization and timing rules. Missing data can affect rewards and recovery. A human signature plus evidence-provider signatures still cannot guarantee that a real-world statement is correct.
- What if something is paused or a payment callback fails?
- The design includes defined recovery and retry paths, but the applicable release and state determine which one is available. Keep the operation or transaction identifier, inspect its status, and follow the documented recovery step instead of blindly repeating a money-moving request.
- Does this require surveillance?
- The intended evidence model uses defined summaries and hashes rather than publishing personal notes. A hash is a digital fingerprint, not automatic anonymity. Never place secrets or personal information in public evidence, and do not assume that every external integration shares the same privacy guarantees.
- Is V3 audited and ready for real money?
- No. Published tests and local demonstrations are not an independent external security audit. Real-proof verification, independent review, policy and operational acceptance, and explicit activation approval remain separate gates. Payments and V3 activation stay disabled.
Read the full readiness and recovery boundaries before evaluating a partner integration. If you are not sure what a wallet request does, do not approve it; ask someone you trust to explain the exact transaction first.
A small glossary
The technical words, translated.
- AI agent
- Software that can take steps or call tools toward a task. Its actual permissions depend on its setup.
- Protocol
- A shared set of rules that different applications can follow.
- Smart contract
- A program recorded on a blockchain. It follows its code, including its limitations and bugs; being on a blockchain does not make it safe.
- Blockchain or network
- The system that records and runs a transaction. Base and Solana are different networks, not interchangeable addresses or guarantees.
- Attestor or evidence provider
- A party authorized to sign a report. A quorum is the required number of those signatures.
- Receipt or transaction identifier
- A record or reference you can use to inspect what happened, check status, or follow recovery. Keep it; do not assume a retry is harmless.
- SDK and API
- Developer tools and interfaces that applications use to interact with software. A documented interface is not proof that every operation is enabled.
- Source review
- The code is available to inspect and test. It does not mean that the new version is deployed, independently audited, or approved to handle your funds.
Choose your next step.
Understand the limits first, then choose the path that fits you. You do not need to connect a wallet to keep learning.
Check current availabilityGive the read-only brief to an agentContinue as a developer