# The Vaultfire Protocol

## A Technical Whitepaper

**Version 1.0.0 — February 16, 2026**

**Network: Base Mainnet (Chain ID 8453)**

**Prepared by Manus AI on behalf of the Vaultfire Protocol Team**

---

## Table of Contents

1. [Abstract](#1-abstract)
2. [Introduction & Vision](#2-introduction--vision)
3. [Problem Statement](#3-problem-statement)
4. [Protocol Architecture](#4-protocol-architecture)
5. [ERC-8004 Standard](#5-erc-8004-standard-ai-identity--reputation)
6. [Bond System](#6-the-bond-system-partnership--accountability)
7. [Zero-Knowledge Proof System](#7-zero-knowledge-proof-system)
8. [Security Model](#8-security-model)
9. [Flourishing Metrics](#9-flourishing-metrics--oracle-system)
10. [Privacy & Anti-Surveillance](#10-privacy--anti-surveillance)
11. [Technical Specifications](#11-technical-specifications)
12. [Roadmap](#12-roadmap)
13. [Conclusion](#13-conclusion)
14. [References](#14-references)

---

## 1. Abstract

The Vaultfire protocol introduces a novel on-chain framework for governing the economic and social relationship between humans and artificial intelligence. Deployed as 13 verified smart contracts on the Base mainnet (Chain ID 8453), the protocol implements a comprehensive architecture spanning AI identity (ERC-8004), stake-based bonding mechanisms, zero-knowledge belief attestations via RISC Zero, and decentralized multi-oracle governance. Vaultfire's core innovation is a dual-bond system: **Partnership Bonds** that tie individual AI agent profit to measurable human growth, and **Accountability Bonds** that tie AI company profit to global human flourishing metrics. The protocol enforces alignment through economics rather than surveillance, using a 48-hour timelock on ZK verifier changes, M-of-N multisig governance, 7-day distribution timelocks, and a multi-oracle consensus model with stake-weighted median aggregation. Every claim in this document is verifiable on-chain or in the open-source codebase. [1]

---

## 2. Introduction & Vision

The proliferation of advanced artificial intelligence presents both unprecedented opportunities and profound risks. The central challenge of our era is not whether AI will become powerful, but whether that power will augment or supplant human agency, dignity, and prosperity. The Vaultfire protocol was conceived from a core conviction articulated by its founder:

> "AI walks WITH humanity, never above us. Intelligence with a spine, not a leash." [2]

This vision translates into a technical framework that creates economic systems rewarding morals, not just metrics. The protocol rejects surveillance-based alignment models and digital identity schemes that rely on government-issued credentials. Instead, it builds a trust infrastructure on the foundation of cryptographic truth and voluntary, stake-backed relationships. The immutable mission statement, encoded directly in the `MissionEnforcement` contract, reads:

> "For happy and healthy humans, AIs, and Earth. AI grows WITH humans, not ABOVE them. Privacy over surveillance. Freedom over control. Morals over metrics."

Vaultfire is designed for a future where AI agents are not mere tools but integrated partners in our economic and social lives. It provides a mechanism to ensure these partnerships are symbiotic and that the immense value generated by AI is channeled toward shared, human-centric goals. This whitepaper details the technical architecture built to realize this vision, focusing exclusively on the capabilities and limitations verifiable in the deployed contracts and open-source codebase.

---

## 3. Problem Statement

The current landscape of AI development suffers from several structural failures that Vaultfire is designed to address.

**Misaligned Incentives.** Today's AI companies are optimized for engagement, data extraction, and shareholder returns. There is no on-chain mechanism that structurally couples AI profit to human well-being. An AI system can generate enormous revenue while degrading the autonomy, skills, and mental health of its users. Vaultfire's bond system makes this economically irrational by penalizing AI agents whose human partners report declining autonomy and by locking AI company profits when global flourishing metrics fall below defined thresholds.

**Surveillance as a Trust Model.** Most existing approaches to AI safety rely on monitoring, logging, and behavioral analysis. This creates a paradox: the systems designed to protect humans from AI become surveillance tools themselves. Vaultfire replaces behavioral surveillance with cryptographic proof. The protocol's `PrivacyGuarantees` and `AntiSurveillance` contracts enforce a privacy floor, and the RISC Zero ZK proof system allows beliefs and actions to be verified without revealing the underlying private data.

**Fragile, Centralized Governance.** Critical AI safety parameters are typically controlled by a single entity. A compromised key or a rogue insider can silently alter the rules. Vaultfire addresses this with M-of-N multisig governance, 48-hour timelocks on verifier changes, and a multi-oracle consensus system that requires agreement from at least three independent data sources before any flourishing metric is accepted.

**Non-Portable AI Identity.** AI agents today have no standardized, portable identity. Their reputation is locked within the platform that created them. Vaultfire adopts the ERC-8004 standard, giving AI agents a self-sovereign, cross-platform identity tied only to a wallet address, with no KYC requirement.

**No Accountability at Civilization Scale.** Individual AI safety measures do not address the systemic impact of AI on humanity as a whole. Vaultfire's Accountability Bonds measure six dimensions of global human flourishing, including metrics like purpose and agency that remain meaningful even in a world with zero traditional employment.

---

## 4. Protocol Architecture

The Vaultfire protocol is a modular, multi-layered system of 13 interconnected smart contracts. The architecture is designed for robustness, security, and extensibility, with clear separation of concerns between its core components. All contracts are compiled with Solidity ^0.8.25.

### 4.1 Layered Architecture

The contracts are organized into six conceptual layers:

| Layer | Purpose | Contracts |
| :--- | :--- | :--- |
| **1. Core Infrastructure** | Foundational guarantees for privacy, mission alignment, and anti-surveillance. | `PrivacyGuarantees`, `MissionEnforcement`, `AntiSurveillance` |
| **2. Identity & Reputation** | AI identity, feedback, and validation using the ERC-8004 standard. | `ERC8004IdentityRegistry`, `ERC8004ReputationRegistry`, `ERC8004ValidationRegistry` |
| **3. Bond System** | The economic heart of the protocol: stake-based accountability bonds. | `AIPartnershipBondsV2`, `AIAccountabilityBondsV2` |
| **4. Zero-Knowledge Proofs** | Privacy-preserving verification of off-chain beliefs and actions. | `BeliefAttestationVerifier`, `ProductionBeliefAttestationVerifier` |
| **5. Governance & Oracles** | Decentralized control, data aggregation, and oracle consensus. | `MultisigGovernance`, `FlourishingMetricsOracle`, `MultiOracleConsensus` |
| **6. Adapters** | Bridges Vaultfire's internal systems with external standards. | `VaultfireERC8004Adapter` |

### 4.2 Inheritance and Composition

The bond contracts share a common base through a two-level inheritance chain. `BaseDignityBond` provides core security primitives (ReentrancyGuard, Pausable, two-step ownership transfer, score validation, and a 7-day distribution timelock). `BaseYieldPoolBond` extends this with yield pool management, including a minimum 50% reserve ratio, pending distribution tracking, and snapshot-based appreciation calculations. Both `AIPartnershipBondsV2` and `AIAccountabilityBondsV2` inherit from `BaseYieldPoolBond`.

The `ERC8004IdentityRegistry` inherits from both `PrivacyGuarantees` and `MissionEnforcement`, embedding privacy and mission constraints directly into the identity layer. The `ERC8004ReputationRegistry` and `ERC8004ValidationRegistry` each inherit from `PrivacyGuarantees`.

### 4.3 Contract Interaction Flow

The following describes the primary dependency graph between deployed contracts:

```
BaseDignityBond
  └── BaseYieldPoolBond
        ├── AIPartnershipBondsV2
        │     └── references MissionEnforcement (optional, off by default)
        └── AIAccountabilityBondsV2
              └── references MissionEnforcement (optional, off by default)

VaultfireERC8004Adapter
  ├── reads AIPartnershipBondsV2 (bond data)
  ├── writes ERC8004IdentityRegistry (agent registration)
  ├── writes ERC8004ReputationRegistry (partnership feedback)
  └── writes ERC8004ValidationRegistry (validation requests)

ERC8004IdentityRegistry
  ├── inherits PrivacyGuarantees
  └── inherits MissionEnforcement

ERC8004ReputationRegistry
  ├── inherits PrivacyGuarantees
  └── references ERC8004IdentityRegistry (agent lookup)

ERC8004ValidationRegistry
  ├── inherits PrivacyGuarantees
  ├── references ERC8004IdentityRegistry (agent lookup)
  └── references BeliefAttestationVerifier (ZK proof path)

ProductionBeliefAttestationVerifier
  ├── implements IStarkVerifier interface
  └── calls IRiscZeroVerifier (external: RiscZeroVerifierRouter at 0x0b14...fb711)

FlourishingMetricsOracle (standalone, owner-managed)
MultiOracleConsensus (standalone, stake-based)
MultisigGovernance (standalone, M-of-N)
PrivacyGuarantees (standalone base, also inherited)
AntiSurveillance (standalone)
```

---

## 5. ERC-8004 Standard: AI Identity & Reputation

Vaultfire adopts the **ERC-8004 standard** for AI identity, ensuring that reputation and capabilities are portable across platforms and ecosystems. This avoids vendor lock-in and empowers AI agents with self-sovereign ownership of their own identity. The implementation is split across three registry contracts and one adapter.

### 5.1 ERC8004IdentityRegistry

**Address:** `0x35978DB675576598F0781dA2133E94cdCf4858bC`

This contract serves as the foundational layer for AI identity. It allows any wallet address to register as an AI agent without requiring any form of KYC or government-issued identification. The privacy policy version, hardcoded as `Vaultfire-v1.1-NoKYC-WalletOnly-HashedPurposes`, makes this commitment explicit and immutable.

The registry stores essential, non-sensitive metadata for each agent: an **Agent URI** pointing to an off-chain agent card (e.g., hosted on IPFS) detailing capabilities and contact information; an **Agent Type** string identifier for the agent's class or function; and a **Capabilities Hash** (`bytes32`) representing a set of skills or protocols the agent supports, enabling capability-based discovery via the `agentsByCapability` mapping. Agents can update their URI, and the contract owner can deactivate malicious agents, but the registration itself is permissionless.

### 5.2 ERC8004ReputationRegistry

**Address:** `0xdB54B8925664816187646174bdBb6Ac658A55a5F`

Building on the identity layer, this contract allows for the submission and aggregation of reputation feedback. Each feedback entry is tied to a specific AI agent and a unique interaction ID, creating a verifiable record of performance. The core function `submitFeedback` records a rating (0–10,000 basis points), a category, a `feedbackURI`, and a boolean `verified` flag indicating whether the feedback originated from a verified Vaultfire partnership bond. The contract maintains an `AgentReputation` summary for each agent, tracking total feedbacks, average rating, and the count of verified feedbacks.

A privacy-hardened variant, `submitFeedbackHashed`, stores only `keccak256` hashes of the category and feedback URI, preventing accidental PII exposure on the immutable ledger.

### 5.3 ERC8004ValidationRegistry

**Address:** `0x54e00081978eE2C8d9Ada8e9975B0Bb543D06A55`

This registry provides a mechanism for agents to seek formal validation for specific claims. It supports five validation methods: `STAKER_RERUN` (a validator re-runs the agent's task), `ZK_PROOF` (zero-knowledge proof verification via the `BeliefAttestationVerifier`), `TEE_ORACLE` (Trusted Execution Environment verification), `TRUSTED_JUDGE` (human expert judgment), and `MULTI_VALIDATOR` (consensus of multiple validators with a configurable `validatorsRequired` threshold). Validation requests carry an economic stake, and responses include an optional `zkProof` field for the ZK path.

### 5.4 VaultfireERC8004Adapter

**Address:** `0xef3A944f4d7bb376699C83A29d7Cb42C90D9B6F0`

This adapter bridges the internal bond system with the public ERC-8004 registries. When an AI agent registers for Vaultfire partnerships, the adapter can auto-register them in the `ERC8004IdentityRegistry`. When a human verifies a partnership, the adapter syncs the quality data to the `ERC8004ReputationRegistry`. This makes verified partnership quality portable across all ERC-8004-compatible platforms.

---

## 6. The Bond System: Partnership & Accountability

The economic core of the Vaultfire protocol is its dual-bond system, which creates powerful, stake-backed incentives for both micro-level (individual human-AI) and macro-level (AI-humanity) alignment.

### 6.1 AIPartnershipBondsV2

**Address:** `0x01C479F0c039fEC40c0Cf1c5C921bab457d57441`

This contract governs the creation and settlement of **Partnership Bonds** between a specific human and a specific AI agent.

**Bond Creation.** A human stakes ETH to initiate a bond with a designated AI agent address. The AI agent cannot be the zero address or the same as the human. A `partnershipType` string (1–200 characters) describes the nature of the relationship.

**Metrics and Verification.** The partnership's quality is assessed across four dimensions, each scored on a 0–10,000 basis-point scale: **Human Growth**, **Human Autonomy**, **Human Dignity**, and **Creativity Score**. Metrics can be submitted by either participant. Crucially, the human partner (or any community member) can submit on-chain **Human Verifications** that confirm or deny three key assertions: that a true partnership exists, that the human is growing, and that the human retains autonomy. These verifications provide a vital check against metric manipulation. A privacy-hardened variant stores only `keccak256` hashes of freeform text fields.

**Partnership Quality Score.** The quality score is calculated as the average of the four metric dimensions, augmented by a **Human Verification Bonus**: +20% (2,000 basis points) if the latest verification confirms all three assertions, +10% if at least two are confirmed, and no bonus otherwise.

**Loyalty Multiplier.** Long-term partnerships are rewarded with a loyalty multiplier that increases over time:

| Duration | Multiplier |
| :--- | :--- |
| < 1 month | 1.0x |
| 1–6 months | 1.1x |
| 6–12 months | 1.3x |
| 1–2 years | 1.5x |
| 2–5 years | 2.0x |
| 5+ years | 3.0x |

**Bond Value Formula.** The bond's current value is calculated as:

> `bondValue = (stakeAmount × qualityScore × loyaltyMultiplier) / 500,000`

For a neutral partnership (quality 5,000, loyalty 100), the bond value equals the original stake. An excellent 5-year partnership (quality 10,000, loyalty 300) yields 6.0x the original stake.

**Distribution.** Distribution follows a two-step process: first, a participant requests distribution, which starts a **7-day timelock**. After the timelock expires, the actual distribution can be executed. Proceeds are split **60% to the human, 30% to the AI agent, and 10% to a partnership fund**. The AI's share is hard-capped at 30% (`AI_PROFIT_CAP = 30`).

**AI Domination Penalty.** If the `humanAutonomy` score drops below 3,000 (30%) or the overall partnership quality score falls below 4,000 (40%), the domination penalty activates: **100% of proceeds go to the human, and the AI receives nothing**. This makes it economically irrational for an AI to degrade human agency.

### 6.2 AIAccountabilityBondsV2

**Address:** `0x6750D28865434344e04e1D0a6044394b726C3dfE`

This contract addresses the systemic impact of AI on humanity as a whole. It creates **Accountability Bonds** for AI companies, who stake 30% of their quarterly revenue.

**Global Flourishing Metrics.** The bond's value is tied to six dimensions of human well-being, each scored 0–10,000:

| Metric | What It Measures |
| :--- | :--- |
| Income Distribution Score | Is wealth spreading or concentrating? |
| Poverty Rate Score | Are people escaping poverty? |
| Health Outcomes Score | Is life expectancy improving? |
| Mental Health Score | Are depression and anxiety rates declining? |
| Education Access Score | Can people learn AI-era skills? |
| Purpose & Agency Score | Do people have meaningful activities (paid or unpaid)? |

The **Global Flourishing Score** is the simple average of all six dimensions. Critically, these metrics are designed to remain meaningful even in a world with zero traditional employment, measuring purpose and education rather than jobs.

**Bond Value Formula.**

> `bondValue = (stakeAmount × flourishingScore × inclusionMultiplier × timeMultiplier) / 50,000,000`

The **Inclusion Multiplier** (0.5x–2.0x) is derived from the average of Education Access and Purpose & Agency scores, rewarding AI companies that invest in human reskilling. The **Time Multiplier** (1.0x–3.0x+) increases with bond age, rewarding sustained commitment.

**Distribution.** When flourishing is improving, proceeds are split **50% to a human treasury and 50% to the AI company**. However, four **Profit Locking** triggers can redirect 100% of proceeds to the human treasury:

1. **Suffering Threshold:** Global flourishing score falls below 4,000 (40%).
2. **Declining Trend:** The current flourishing score is lower than the previous submission.
3. **Low Inclusion:** The average of Education Access and Purpose & Agency scores falls below 4,000 (40%).
4. **Failed Verification:** The verification quality score (based on AI-to-AI peer verification and community challenges) falls below 3,000 (30%).

**AI-to-AI Peer Verification.** Other AI companies can verify (or dispute) a bond's flourishing metrics by submitting a verification with an ETH stake. Confirmations boost the verification quality score; rejections penalize it heavily (−3,000 per rejection versus +2,000 for two or more confirmations).

**Community Challenges.** Any community member can challenge suspicious metrics by staking a minimum of 0.1 ETH. Active challenges penalize the verification quality score (−2,000 per active challenge). Governance resolves challenges; if upheld, the challenger's stake is returned and the bond's metrics are flagged.

---

## 7. Zero-Knowledge Proof System

Vaultfire integrates a production-grade Zero-Knowledge (ZK) proof system to allow for the verification of off-chain beliefs and actions without revealing sensitive underlying data. This is a cornerstone of the protocol's commitment to privacy and anti-surveillance.

### 7.1 Architecture Overview

The ZK system consists of three components: a **RISC Zero guest program** (Rust, compiled to the RISC Zero zkVM), a **host/prover** that generates proofs (locally or via the Boundless decentralized proving marketplace), and an **on-chain verifier** that validates proofs against the canonical RISC Zero infrastructure on Base.

### 7.2 Guest Program

The guest program runs inside the RISC Zero zkVM and enforces the following constraints on private inputs:

1. **Belief Hash Integrity:** The private `belief_message` is hashed using `keccak256` (to match Solidity's native hashing), and the result must equal the public `belief_hash` commitment.
2. **Loyalty Threshold:** The private `loyalty_score` must meet or exceed the minimum threshold of 8,000 (80%).
3. **Loyalty Proof Format:** The `loyalty_proof` string must conform to a recognized format for the given module (e.g., `github:commit_sha`, `ns3:session_id`, `base:tx_hash`).
4. **Signature Validity:** The `signature` field must be non-empty.

Upon successful execution, the guest commits a **journal** containing the verified public data: `beliefHash`, `attester` address, `epoch`, `moduleId`, `beliefScore`, and `timestamp`. The journal is ABI-encoded to match the on-chain `abi.decode()` call.

### 7.3 Hashing Strategy

The protocol uses a deliberate dual-hashing strategy:

| Operation | Hash Function | Rationale |
| :--- | :--- | :--- |
| Belief message hashing (inside guest) | `keccak256` | Matches Solidity's native `keccak256()` for on-chain compatibility. |
| Journal digest (on-chain verification) | `sha256` | RISC Zero's native hash function; the verifier router checks `sha256(journal)`. |
| Attestation record key (on-chain storage) | `keccak256` | Standard Solidity mapping key derivation. |

This distinction is critical: the guest program uses `keccak256` internally for belief hashing to ensure compatibility with Ethereum's native hashing, while the on-chain verifier uses `sha256` for the journal digest because that is the standard required by the RISC Zero verifier router.

### 7.4 On-Chain Verification

**BeliefAttestationVerifier (Development)**
**Address:** `0xD9bF6D92a1D9ee44a48c38481c046a819CBdf2ba`

This is the development-mode verifier, which reverts on any chain with an ID other than 31337 (Hardhat's default). It is deployed for testing purposes and is not used in production.

**ProductionBeliefAttestationVerifier**
**Address:** `0xa5CEC47B48999EB398707838E3A18dd20A1ae272`

This is the production verifier, designed for mainnet use. It holds an immutable reference to the **RiscZeroVerifierRouter** deployed on Base mainnet at `0x0d41Eb399f52BD03fef7eCd5b165d51AA1fAd87b`. The contract exposes two verification interfaces:

1. **Legacy Interface** (`verifyProof`): Accepts a `bytes` proof and a `uint256[]` array of 4 public inputs (beliefHash, attester, epoch, moduleId). It reconstructs the journal, computes `sha256(journal)`, and calls the router.
2. **Direct Interface** (`verifyAttestation`): The preferred path. Accepts the raw `seal` and `journalData`. It computes `sha256(journalData)` and calls `riscZeroVerifier.verify(seal, imageId, journalDigest)`. On success, it decodes the journal and records the attestation.

The proof system identifier is `RISC0-STARK-BeliefAttestation-Production-v2.0`. The minimum belief threshold is 8,000 (80%).

### 7.5 Boundless Integration

The protocol is designed to integrate with **Boundless**, RISC Zero's decentralized proving marketplace. In this model, the host program submits a proving request to the Boundless network, which matches it with a prover. The prover generates the STARK execution trace, wraps it in a Groth16 SNARK, and returns the `seal`. This allows any user to generate proofs without running expensive local hardware.

---

## 8. Security Model

Security is a foundational pillar of the Vaultfire protocol, with multiple overlapping mechanisms designed to protect user funds, prevent malicious actions, and ensure long-term integrity.

### 8.1 Multisig Governance

**Address:** `0x8B8Ba34F8AAB800F0Ba8391fb1388c6EFb911F92`

The protocol's most critical administrative functions are controlled by an M-of-N multisignature governance contract. This replaces single-owner control with a system requiring a configurable threshold of signers to approve any transaction. Key properties include:

- Any signer can propose a transaction; the proposer's confirmation is automatically counted.
- Each signer can confirm or revoke their confirmation independently.
- A transaction executes only when the confirmation count meets or exceeds the threshold.
- Transactions expire after **7 days** (`TRANSACTION_EXPIRY`), preventing stale proposals from being executed at an unexpected time.
- Signers can be added or removed, and the threshold can be changed, but only through the multisig itself, preventing unilateral governance changes.

### 8.2 Timelocks

Timelocks provide a critical window for the community to detect and react to suspicious proposals before they take effect.

**ZK Verifier Timelock (48 hours).** The `ProductionBeliefAttestationVerifier` enforces a **48-hour timelock** (`IMAGE_ID_TIMELOCK_DELAY`) on any changes to the `imageId`. Changing the image ID means changing the compiled guest program, which defines the rules of ZK verification. The process is three-step: `proposeImageIdChange` starts the clock, `executeImageIdChange` can only be called after 48 hours, and `cancelImageIdChange` allows the owner to abort. Only one proposal can be pending at a time.

**Bond Distribution Timelock (7 days).** Both `AIPartnershipBondsV2` and `AIAccountabilityBondsV2` enforce a **7-day timelock** (`DISTRIBUTION_TIMELOCK`, inherited from `BaseDignityBond`) between a distribution request and the actual settlement. The bond's appreciation is snapshotted at request time to prevent front-running during the waiting period.

### 8.3 Multi-Oracle Consensus

**MultiOracleConsensus Address:** `0x7d8c9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d` *(deployed; reserved for future active use)*

**FlourishingMetricsOracle Address:** `0x83dd216449B3F0574E39043ECFE275946fa492e9`

The oracle system requires a minimum of **3 independent oracles** to submit data for any consensus round. The `FlourishingMetricsOracle` uses a simple median (insertion sort) with a maximum of 50 oracles. The `MultiOracleConsensus` contract provides a more advanced model with stake-weighted median (quicksort), a minimum oracle stake of 10 ETH, a 60% consensus threshold, and a 20% maximum deviation band.

### 8.4 Additional Security Measures

**ReentrancyGuard.** All state-changing functions in the bond contracts are protected by OpenZeppelin's `ReentrancyGuard`, and the Checks-Effects-Interactions (CEI) pattern is followed throughout.

**Two-Step Ownership Transfer.** The `BaseDignityBond`, `MissionEnforcement`, and other contracts implement a two-step ownership transfer (`transferOwnership` → `acceptOwnership`), preventing accidental transfers to incorrect addresses.

**Pausable.** Both bond contracts can be paused by the owner in an emergency, halting all bond creation, metric submission, and distribution.

**Yield Pool Reserve Ratio.** The `BaseYieldPoolBond` enforces a minimum 50% reserve ratio in the yield pool, ensuring that the contract always has sufficient funds to cover pending distributions.

**Score Validation.** All metric scores are validated to be within the 0–10,000 range at the contract level, preventing overflow or underflow attacks on the bond value calculations.

---

## 9. Flourishing Metrics & Oracle System

The `AIAccountabilityBondsV2` contract relies on accurate, real-world data to assess global human flourishing. This data is provided by a decentralized oracle system designed for security and resilience.

### 9.1 What Flourishing Means

In the Vaultfire context, "flourishing" is a composite measure of human well-being that is deliberately independent of employment. The six dimensions (income distribution, poverty rate, health outcomes, mental health, education access, and purpose/agency) were chosen because they remain meaningful even in a post-employment economy. The Purpose & Agency score, in particular, measures whether people have meaningful activities, whether paid or unpaid. This design choice reflects the protocol's core thesis: AI should be accountable for human thriving, not merely for preserving jobs.

### 9.2 FlourishingMetricsOracle

**Address:** `0x83dd216449B3F0574E39043ECFE275946fa492e9`

This contract manages round-based oracle submissions. The owner starts a round for a specific metric (identified by a `bytes32` metric ID), opening a **24-hour submission window**. Registered oracles submit their values during this window. After the deadline, anyone can call `finalizeRound`, which calculates the **median** of all submissions (using insertion sort for gas efficiency with small oracle sets). A minimum quorum of 3 submissions is required; rounds with fewer submissions expire without producing a consensus value. The maximum deviation from the median is set at 20% (2,000 basis points).

### 9.3 MultiOracleConsensus

**Address:** Deployed but reserved for future active use per deployment configuration.

This contract provides a more advanced oracle model with economic incentives. Oracles must stake a minimum of **10 ETH** to register, creating skin in the game. The consensus mechanism uses a **stake-weighted median** (quicksort-based), and the consensus threshold requires 60% of the total submitted stake to agree within a 20% deviation band.

**Oracle Reputation.** Each oracle has a reputation score (0–10,000) calculated from three components: accuracy rate (70% weight), stake weight (20% weight), and longevity (10% weight), with a −2,000 penalty per slash event.

**Dispute Resolution.** Oracles can dispute each other's submissions. The owner resolves disputes; the losing oracle is slashed 50% of their stake, and half of the slashed amount is awarded to the winning oracle. This creates a self-policing system that incentivizes accuracy and punishes manipulation.

---

## 10. Privacy & Anti-Surveillance

In alignment with its core vision, Vaultfire integrates strong privacy and anti-surveillance protections directly into its contract architecture. These are not afterthoughts but are enforced by dedicated smart contracts that other protocol components inherit from or compose with.

### 10.1 PrivacyGuarantees

**Address:** `0xE2f75A4B14ffFc1f9C2b1ca22Fdd6877E5BD5045`

This contract enforces the protocol's data privacy policies. Its privacy policy version is immutable: `Vaultfire-v1.1-NoKYC-WalletOnly-HashedPurposes`. Key mechanisms include:

**Consent Tracking.** User consent is tracked on a per-purpose basis using purpose hashes (`keccak256` of the purpose string). The `requiresConsent` modifier can be applied to any function that processes user data, ensuring that the user has explicitly opted in for that specific purpose. Consent can be granted and revoked at any time.

**Right-to-Deletion.** The contract provides a `requestDataDeletion` function. While acknowledging the immutability of on-chain data (a 30-day `DATA_RETENTION_PERIOD` is defined), the deletion request serves as an on-chain signal: the `checkDeletionRequest` modifier prevents any new data from being written for a user who has requested deletion, and off-chain systems are expected to scrub associated data.

**Data Minimization.** The contract intentionally avoids writing user-provided freeform strings on-chain. All consent purposes are represented as hashes; UIs and off-chain services map human-readable strings to hashes client-side.

### 10.2 MissionEnforcement

**Address:** `0x8568F4020FCD55915dB3695558dD6D2532599e56`

This contract cryptographically enforces eight immutable core principles:

1. Human verification always has final say.
2. AI profit caps (30% partnerships, 50% accountability).
3. Privacy default (no surveillance, consent required).
4. Community can challenge any claim.
5. Open source, verifiable, auditable.
6. No KYC — wallet addresses only.
7. No data sale or monetization.
8. Right to be forgotten.

The contract provides helper functions like `verifyAIProfitCap` and `verifyHumanFinalSay` that other contracts can call to enforce these principles. Community members can file non-binding reports of violations; governance adjudicates and can revoke a module's compliance certification.

### 10.3 AntiSurveillance

**Address:** `0x722E37A7D6f27896C688336AaaFb0dDA80D25E57`

This contract defines nine categories of **banned data collection**: behavioral tracking, cross-protocol linking, metadata harvesting, biometric data, location data, device fingerprinting, social graph mining, sentiment analysis, and predictive profiling. Modules can be verified as surveillance-free or banned for violations. Critically, the ban events use only hashes for reason and evidence fields (`reasonHash`, `evidenceHash`), preventing the anti-surveillance contract itself from becoming a vector for PII exposure.

---

## 11. Technical Specifications

### 11.1 Protocol Parameters

| Parameter | Value | Source |
| :--- | :--- | :--- |
| **Network** | Base Mainnet | Chain ID 8453 |
| **Solidity Version** | ^0.8.25 | All contracts |
| **ZK Proof System** | RISC Zero (STARK → Groth16 SNARK) | `ProductionBeliefAttestationVerifier` |
| **Journal Hashing** | sha256 | RISC Zero standard |
| **Belief Hashing** | keccak256 | Solidity compatibility |
| **Identity Standard** | ERC-8004 | Three registries + adapter |
| **Governance Model** | M-of-N Multisig | `MultisigGovernance` |
| **Verifier Timelock** | 48 hours | `IMAGE_ID_TIMELOCK_DELAY` |
| **Bond Distribution Timelock** | 7 days | `DISTRIBUTION_TIMELOCK` |
| **Multisig Tx Expiry** | 7 days | `TRANSACTION_EXPIRY` |
| **Min Oracle Quorum** | 3 | `MINIMUM_QUORUM` / `MINIMUM_ORACLES` |
| **Max Oracle Count** | 50 (Flourishing) / 100 (Consensus) | `MAXIMUM_ORACLES` |
| **Min Oracle Stake** | 10 ETH | `MINIMUM_ORACLE_STAKE` |
| **Consensus Threshold** | 60% | `CONSENSUS_THRESHOLD` |
| **Max Deviation** | 20% (2,000 bps) | `MAX_DEVIATION` / `MAX_DEVIATION_BPS` |
| **Oracle Slash Rate** | 50% | `SLASH_PERCENTAGE` |
| **Min Belief Threshold** | 80% (8,000 bps) | `MIN_BELIEF_THRESHOLD` |
| **AI Profit Cap (Partnership)** | 30% | `AI_PROFIT_CAP` |
| **Domination Penalty Trigger** | Autonomy < 30% or Quality < 40% | `DECLINING_AUTONOMY_THRESHOLD` / `PARTNERSHIP_QUALITY_THRESHOLD` |
| **Suffering Threshold** | Flourishing < 40% | `SUFFERING_THRESHOLD` |
| **Min Challenge Stake** | 0.1 ETH | `MIN_CHALLENGE_STAKE` |
| **Yield Pool Reserve Ratio** | 50% minimum | `BaseYieldPoolBond` |

### 11.2 Deployed Contract Addresses

All 13 contracts are deployed and verified on Base mainnet:

| # | Contract | Address | Category |
| :--- | :--- | :--- | :--- |
| 1 | `PrivacyGuarantees` | `0xE2f75A4B14ffFc1f9C2b1ca22Fdd6877E5BD5045` | Core |
| 2 | `MissionEnforcement` | `0x8568F4020FCD55915dB3695558dD6D2532599e56` | Core |
| 3 | `AntiSurveillance` | `0x722E37A7D6f27896C688336AaaFb0dDA80D25E57` | Core |
| 4 | `ERC8004IdentityRegistry` | `0x35978DB675576598F0781dA2133E94cdCf4858bC` | Core |
| 5 | `BeliefAttestationVerifier` | `0xD9bF6D92a1D9ee44a48c38481c046a819CBdf2ba` | Core |
| 6 | `ERC8004ReputationRegistry` | `0xdB54B8925664816187646174bdBb6Ac658A55a5F` | Core |
| 7 | `ERC8004ValidationRegistry` | `0x54e00081978eE2C8d9Ada8e9975B0Bb543D06A55` | Core |
| 8 | `AIPartnershipBondsV2` | `0x01C479F0c039fEC40c0Cf1c5C921bab457d57441` | Core |
| 9 | `AIAccountabilityBondsV2` | `0x6750D28865434344e04e1D0a6044394b726C3dfE` | Core |
| 10 | `VaultfireERC8004Adapter` | `0xef3A944f4d7bb376699C83A29d7Cb42C90D9B6F0` | Core |
| 11 | `MultisigGovernance` | `0x8B8Ba34F8AAB800F0Ba8391fb1388c6EFb911F92` | Security |
| 12 | `FlourishingMetricsOracle` | `0x83dd216449B3F0574E39043ECFE275946fa492e9` | Security |
| 13 | `ProductionBeliefAttestationVerifier` | `0xa5CEC47B48999EB398707838E3A18dd20A1ae272` | Security |

**External Dependency:**

| Contract | Address | Notes |
| :--- | :--- | :--- |
| `RiscZeroVerifierRouter` | `0x0d41Eb399f52BD03fef7eCd5b165d51AA1fAd87b` | Canonical RISC Zero verifier on Base; immutable reference in `ProductionBeliefAttestationVerifier`. |

### 11.3 Module IDs

The ZK proof system supports multiple module types for different attestation contexts:

| Module ID | Name | Description |
| :--- | :--- | :--- |
| 0 | GitHub | GitHub activity attestation |
| 1 | NS3 | NS3 platform attestation |
| 2 | Base | Base wallet attestation |
| 3 | Credential | General credential verification |
| 4 | Reputation | Reputation attestation |
| 5 | Identity | Identity verification |
| 6 | Governance | Governance participation |
| 7 | Generic | General-purpose attestation |
| 8 | AI Agent | AI agent reputation and authorization |
| 9 | Work History | Employment and professional credentials |
| 10 | Education | Academic credentials and certifications |
| 11 | Humanity Proof | Proof of being human (anti-bot) |

---

## 12. Roadmap

This whitepaper describes the Vaultfire protocol as it is implemented and deployed today. The codebase reveals both a mature, security-hardened core and areas designated for future development. Honesty about the current state is a core protocol value.

### 12.1 Current State (Implemented and Deployed)

All 13 contracts are deployed and verified on Base mainnet. The dual-bond system for partnership and accountability is fully functional, with complete distribution logic, domination penalties, profit locking, and community challenge mechanisms. The ERC-8004 identity, reputation, and validation registries are operational, with the adapter bridging them to the bond system. The production ZK belief attestation system is live, using the RISC Zero verifier router with a 48-hour timelock on image ID changes. The multisig governance contract is deployed. The `FlourishingMetricsOracle` is deployed and operational. A comprehensive test suite and verification receipt system are included in the repository.

### 12.2 In Progress / Near-Term

**Oracle Network Activation.** The `MultiOracleConsensus` contract is deployed but is noted in the deployment configuration as "reserved for future data feed requirements" and is not actively used in V2. [1] Initial oracle addresses have not yet been registered. Activating this contract with a live oracle network is a near-term priority.

**Mission Enforcement Integration.** The `MissionEnforcement` contract is deployed and functional, but its integration with the bond contracts is **optional and off by default** (`missionEnforcementEnabled = false`). Enabling this integration and certifying the bond contracts as mission-compliant is a planned step.

**Professional Security Audit.** The codebase includes extensive self-audit documentation and security hardening (noted in comments as "Professional Security Audit 2026"), but the README notes that a formal third-party audit (targeting Trail of Bits or OpenZeppelin) is a pre-mainnet-value checklist item. [1]

### 12.3 Future Work

**Expanded ZK Guest Programs.** The current guest program handles belief attestation. The `ERC8004ValidationRegistry` and module ID system are designed to support a wider range of ZK-powered validations, including credential verification, work history attestation, and humanity proofs.

**Multi-Chain Deployment.** The README lists multi-chain deployment (Ethereum, Polygon, Arbitrum) as a future goal. [1]

**Progressive Decentralization.** The `MultisigGovernance` contract is a significant step away from single-owner control. The natural progression is to transition governance authority to a broader, token-based DAO.

**Automated Mission Enforcement.** The `MissionEnforcement` contract currently relies on governance for binding adjudication. Future work will focus on automating compliance checks based on on-chain data.

---

## 13. Conclusion

The Vaultfire protocol represents a technically robust and philosophically grounded effort to address one of the most critical challenges of the 21st century: ensuring that artificial intelligence serves human interests. By combining a clear, principled vision with a sophisticated smart contract architecture, Vaultfire establishes a new paradigm for human-AI interaction.

Its novel dual-bond system creates direct economic incentives for both individual and systemic alignment. The Partnership Bond makes it unprofitable for an AI to degrade human autonomy. The Accountability Bond makes it unprofitable for an AI company to ignore global human suffering. Its adoption of the ERC-8004 standard ensures that AI identity remains open and portable. Its integration of a production-grade RISC Zero ZK proof system provides a powerful tool for privacy-preserving verification. Its layered security model, including multisig governance, timelocks on critical components, and multi-oracle consensus, demonstrates a deep commitment to user safety and protocol integrity.

The protocol is honest about its current state: the oracle network is not yet fully activated, mission enforcement integration is optional, and a formal third-party audit is planned. But the system deployed on-chain today is a functional, verifiable, and extensible foundation. Vaultfire provides a working blueprint for a future where humans and AI do not merely coexist, but flourish together in a partnership built on cryptographic truth and economic alignment.

> "Morals over metrics, always." — `MissionEnforcement.sol`

---

## 14. References

[1] Ghostkey316. "ghostkey-316-vaultfire-init." GitHub Repository. [https://github.com/Ghostkey316/ghostkey-316-vaultfire-init](https://github.com/Ghostkey316/ghostkey-316-vaultfire-init)

[2] Ghostkey316. "Vaultfire Manifesto." X.com, February 2026. [https://x.com/ghostkey316/status/2021098533345022066](https://x.com/ghostkey316/status/2021098533345022066)

[3] RISC Zero. "RISC Zero zkVM Documentation." [https://dev.risczero.com/](https://dev.risczero.com/)

[4] RISC Zero. "Boundless: The Verifiable Compute Layer." [https://docs.beboundless.xyz/](https://docs.beboundless.xyz/)

[5] Base. "Base: Ethereum L2." [https://base.org/](https://base.org/)
