# Vaultfire financial system

Vaultfire is financial infrastructure for AI agents. It connects explicit permissions, controlled treasuries, payments, task escrow, bonds, balanced accounting and recovery, without granting a model unrestricted access to money.

Read the [plain-English guide](https://theloopbreaker.com/how-it-works) first. The [financial scope and capability matrix](https://theloopbreaker.com/v3/finance) and [technical reference](https://theloopbreaker.com/v3) distinguish implementation, integration, local verification and production qualification.

## Follow the system

- **Incoming funds:** Exact customer invoices and owner deposits are integrated locally. Each invoice binds payer, token, amount, expiry and terms; funds stay held until observed finality. Seller evidence, payer acceptance and refunds remain separate. Real merchant onboarding and facilitator acceptance are not qualified.
- **Permissions:** Exact authority binds the operator, network, asset, recipient, amount, fee limits, policy, configuration and expiry. Shared principal-level controls and reservations apply across sessions; identity alone grants no spending permission.
- **Payments and escrow:** A local direct token payment and fixed-assignee task escrow are implemented. Preparation, approval, submission, settlement and fulfillment are separate phases. Zero native call value still carries token exposure; a payment receipt does not prove merchant delivery.
- **Bonds:** The maintained local journey connects exact customer invoices, treasury payments, escrow and accounting to invoice-linked bonds, separate sponsor rewards and recovery on the same chain. Accountability and Partnership Bonds are the flagship commitment layer, not the whole wallet. Bonds require explicit agreements and are not automatically attached to every payment.
- **Accounting:** A private balanced journal distinguishes available, reserved, pending, spent, refunded and fee amounts. Durable operation identifiers connect the lifecycle; a receipt store alone is not the complete ledger.
- **Recovery:** Principal-wide emergency action revokes registered capabilities. Owner-only recovery requires fresh authorization, while supported refunds and available withdrawals remain possible during pauses. Keep the operation ID, private journal and an independently retained checkpoint rather than blindly rebroadcasting.

## Understand bond funding

- **Protected principal:** The original deposit is separate from remedies and rewards. Flourishing scores do not debit it; recovery follows the agreement’s rules and deadlines.
- **Objective-remedy reserve:** Additional capped funding supports only the configured objective-breach path in the relevant Accountability design.
- **Sponsor rewards:** A separately funded, capped reward budget depends on approved evidence, policy and timing. It is not guaranteed interest.

Partnership principal transfers require both parties’ exact signed consent. Partnership Bonds have no unilateral enforcement slash, and separate addresses do not prove independent people.

## Availability boundaries

The integrated finance profile uses disposable local EVM chain 31337 and a direct-runtime 18-decimal MockERC20. This is not Base USDC qualification, real merchant delivery, public-chain finality, a complete production custody service or proof of Solana financial parity.

Delivery, scores and provider-disagreement observations are synthetic examples, not independently established merchant fulfillment or public finality. Optional native late-event cover is separately prefunded, not automatic insurance. Other module and network lifecycles retain their own evidence. Trading, lending, yield, derivatives, fiat conversion and value bridges are not implied; insurance/coverage modules require their own exact capability and readiness checks.

Public V3 activation, payments and partner funds remain disabled. Real proof, independent review, actual asset/network qualification, isolated production custody, staffed operations and applicable authorization remain separate gates; local results do not satisfy them.

V2 has [operation-specific availability and pricing](https://theloopbreaker.com/x402#availability). A configured catalog entry or declared schema does not establish live fulfillment; 76 declared success schemas, 44 locally observed schemas and 32 declared-only schemas are distinct.

## Choose a starting path

- **People:** Read the guide, then use the [browser-only check](https://theloopbreaker.com/v3/get-started#read-only) and save its inspection record. No wallet or payment is needed; the record is not a transaction receipt or safety certification.
- **Agents:** Use the [agent discovery document](https://theloopbreaker.com/.well-known/agent.json) and [MCP documentation](https://theloopbreaker.com/docs/mcp.md). The public MCP server exposes five read-only tools, not signing or execution. On connection failure, use public documents rather than switching to a payment or signing flow.
- **Builders:** Follow the [pinned local setup and finance command](https://theloopbreaker.com/v3/get-started#finance). Disposable local tools/assets are required, not public-chain funds; setup and compute are your costs. Keep durable identifiers and the private journal for recovery.

Never provide a seed phrase or private key to a visitor-facing page or AI agent. Public addresses, amounts, timestamps and evidence hashes can reveal relationships; hashing and consent do not establish anonymity.