How resolution actually works
The /demo tells the story in plain English. This page tells you exactly what the contracts do — function names, events, the real mechanism. No simplification, no “slashing” metaphor. If you're evaluating Vaultfire technically, start here.
People talking about agent accountability default to the word slashing — borrowed from staking systems where misbehavior burns collateral. Vaultfire's mechanism is different and, we think, better. The bond doesn't get burned. It gets distributed based on what actually happened, weighted toward the harmed human. That's what the contract does. That's what this page documents.
The two contracts involved
Holds the agent's collateral. Tracks bond outcomes via signed metrics submissions. When a bond is ready to resolve, it computes an appreciation score (positive = the agent flourished, negative = the human was harmed) and splits the bond accordingly.
Key events:
BondCreated — bond is posted
MetricsSubmitted — agent submits signed outcome data
MetricsChallenged — anyone can challenge the metrics with stake
ChallengeResolved — challenge is upheld or rejected
BondDistributed — bond pays out (humanShare, aiCompanyShare, appreciation)
ProfitsLocked — yield pool can't cover full payout
There is no Slashed event. The contract does not burn collateral. It distributes it.
Separate contract that handles disputes when parties disagree about an outcome. Disputes are resolved by an arbitrator panel — not by the contract auto-evaluating rules, and not by a single judge.
The flow:
1. Plaintiff calls fileDispute() with a stake and evidence pointer
2. Owner assigns a panel of 3-7 arbitrators (selected by reputation)
3. Arbitrators vote: for claimant or for respondent
4. Majority resolves the dispute on-chain
5. Arbitrators earn a 5% fee split among the panel
6. Parties cannot vote on their own dispute (enforced in contract)
How metrics get into the system
Disputes resolve human-vs-human outcomes. But the bond's appreciation also depends on flourishing metrics — numbers like “was the booking confirmed,” “did the user mark it acceptable.” Those numbers come from oracles. Here's the honest design.
Multi-oracle consensus. A minimum of 3 independent oracles must submit a value during a submission window. The reported metric is the median of all submissions — outlier-resistant by construction. Submissions outside an acceptable deviation band are flagged.
Design constraints (enforced in contract):
• Minimum quorum: 3 oracles
• Aggregation: median (not mean) — resistant to extreme submissions
• Owner can register/remove oracles but cannot submit data
• Each oracle can only submit once per round
• Rounds have explicit deadlines; late submissions rejected
Hardened consensus layer for high-stakes data. Oracles register with a stake. Status transitions are explicit: Inactive → Active → (on misbehavior) Suspended or Slashed. The word “slashed” applies to oracle stake, not bond collateral — a separate mechanism from the bonds themselves.
Per-submission lifecycle:
Pending → awaiting consensus
Confirmed → quorum reached, value accepted
Disputed → oracles disagree significantly
Expired → consensus window closed without quorum
The oracle infrastructure is deployed but lightly populated. The contract enforces a 3-oracle minimum, but in practice the oracle set is small and the owner has the power to register or remove oracles (disclosed on /security). This is appropriate for the bootstrap stage and inappropriate for high-value enterprise use — we say so in both places.
Read the source: FlourishingMetricsOracle.sol ↗ · MultiOracleConsensus.sol ↗
How the distribution math works
When distributeBond(bondId) is called, the contract reads the snapshotted appreciation and splits as follows:
if (appreciation > 0) // the agent earned a positive outcome
if (yieldPool covers it) → human gets full share
else → 50/50 split (ProfitsLocked event)
if (appreciation < 0) // the human was harmed
humanShare = abs(appreciation)
aiCompanyShare = 0 → the human is made whole first
Read it directly: AIAccountabilityBondsV2.sol on GitHub ↗
Live numbers, right now
Fetched from each chain at page load. If a number is zero, it's zero — we don't pad.
Honest status: the resolution mechanism is deployed and live on all four chains, but no dispute has ever been filed in production. The infrastructure exists; it has not yet been tested in anger. We'll show you the first one when it happens.
Per-chain breakdown
Snapshot at 2026-04-29T16:43:32.222Z
Why we don't use the word “slashing”
Slashing is a punishment frame: the bond is the penalty, the misbehavior triggers the burn. That model leaks value out of the system every time something goes wrong, and it treats the harmed human as a beneficiary of the punishment rather than the priority.
Distribution by appreciation is a different shape. The bond is still real, the agent still has skin in the game, but when the outcome is bad the harmed human is made whole first. When the outcome is good, the human shares in the upside. The mechanism mirrors the principle: making human thriving more profitable than extraction.
Has this been audited?
Honestly: not by a third-party firm. The contracts have gone through local review and AI-assisted audit passes (most recently the V3.3-R3 review). They are open-source and deployed at the addresses linked above — anyone with the skill is welcome to read them, fork them, or break them.
A paid third-party audit costs more than this project currently earns. We'd rather tell you that than fake it. If you want to audit the code yourself or fund an external review, the contact is ghostkey316@proton.me.
Want the plain-English version?
The 60-second story walks through Alice and a real on-chain agent.
Read the demo →Making human thriving more profitable than extraction.