The idea
A clear agreement is better than “trust me.”
Imagine you ask an AI assistant to handle a task. Before it acts, you want to know what it may do, what it must not do, how you will check the result, and what happens if the agreement is broken. A friendly answer alone does not settle those questions.
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.
How it works
A bond is an agreement with defined financial backing.
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 as well as the required evidence-provider quorum. 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.
The money, explained
Three pots. Three different jobs.
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 MCP documentation: https://theloopbreaker.com/docs/mcp.md 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