# Deep-Dive Analysis: Remaining Starred Repos
*Analysis date: 2026*

---

## 1. Claude-code-Vaultfire

**Repo location:** `/home/user/workspace/claude-code-vaultfire-existing/`
**GitHub:** `github.com/Ghostkey316/Claude-code-Vaultfire-`

### What It Is

The complete open-source Claude Code distribution, forked and enhanced with Vaultfire Protocol's full on-chain trust layer baked into the agent lifecycle. Every session start triggers real on-chain trust verification: identity (ERC-8004), accountability bonds, partnership bonds, x402 payment capability, XMTP messaging reachability, and protocol-level commitment verification (AntiSurveillance, PrivacyGuarantees, MissionEnforcement contracts). The integration runs against real Base and Avalanche mainnet contracts.

### File Structure

The Vaultfire integration lives in two directories:

| Directory | Purpose |
|---|---|
| `src/vaultfire/` | Core TypeScript module — wraps `@vaultfire/agent-sdk`, handles RPC queries, provides clients, renders terminal UI |
| `plugins/vaultfire-trust/` | Claude Code plugin architecture — hooks, commands, agents, skill |

**src/vaultfire/ files:**
- `trust-client.ts` — Main verification orchestrator. Wraps `@vaultfire/agent-sdk`, retries up to 3× with exponential backoff (1s → 2s → 4s), queries 3 protocol commitment contracts in parallel, checks XMTP reachability, checks x402 capability, applies +5 partnership bond bonus to effective score, builds fallback "Unverified" result on failure. Also exports `createAccountabilityBond`, `createPartnershipBond`, `getAgentBondStatus`.
- `bond-client.ts` — `BondClient` class. Uses `VAULTFIRE_AGENT_KEY` env var (private field via `#wallet`), builds unsigned tx via Vaultfire SDK's `buildBondTx()`, signs and broadcasts with ethers.js, waits for 1 confirmation. Supports accountability bonds (self-bond) and partnership bonds. Key never logged. Supports Base and Avalanche.
- `x402-client.ts` — `X402Client` class. EIP-712 USDC payment signing. Domain: `x402Payment`, verifying contract: chain-appropriate USDC address. Signs typed data without submitting tx. Singleton via `getX402Client()`. Supports Base (chain 8453), Avalanche (43114), Ethereum (1). USDC addresses hardcoded per chain.
- `xmtp-client.ts` — `XMTPClient` class. Lazy-initialises `@xmtp/xmtp-js` client on production network. Methods: `canMessage`, `sendMessage`, `listConversations`, `getMessages`, `streamMessages`, `close`. Singleton via `getXMTPClient()`.
- `types.ts` — Full TypeScript type definitions. `TrustResult` interface with 18 fields including `x402`, `xmtp`, `protocolCommitments`, `partnershipBond`, `bondPartner`, `demoMode`. `VaultfireConfig`, `SupportedChain`, `TrustGrade`, `ReputationTier`, `X402Status`, `XMTPStatus`, `ProtocolCommitments`.
- `vaultfire-plugin.ts` — Entry point, initialises plugin, reads config, renders trust panel via Ink terminal UI.
- `trust-panel.tsx` — Ink React component for terminal trust panel rendering.
- `index.ts` — Re-exports everything.

**plugins/vaultfire-trust/ files:**
- `.claude-plugin/plugin.json` — Plugin manifest (`name: "vaultfire-trust"`, version 0.1.0, author: Ghostkey316 / Vaultfire Protocol)
- `README.md` — Well-documented: features table, config schema, security note on private key handling, demo mode instructions
- `hooks/hooks.json` — Two hooks: `SessionStart` (runs session-start.sh) and `PreToolUse` with `Bash|Edit|Write|MultiEdit` matcher (runs pre-tool-use.sh, 5s timeout)
- `hooks-handlers/session-start.sh` — Reads `vaultfire.config.json`, injects trust accountability context into agent system prompt, provides fallback message when unconfigured
- `hooks-handlers/pre-tool-use.sh` — Monitors tool calls for private key pattern exposure
- `commands/vaultfire-trust.md` — Slash command `/vaultfire-trust`
- `commands/create-accountability-bond.md` — Slash command for creating accountability bonds
- `commands/create-partnership-bond.md` — Slash command for creating partnership bonds
- `agents/trust-verifier.md` — Specialised agent for interpreting trust data, knows grade meanings, ERC-8004 standard, accountability bond tiers
- `skills/vaultfire-kya/SKILL.md` — Auto-invoked skill for trust/verification/accountability topics

### Chain Support

Fully supported in all clients: **Base**, **Avalanche**, **Ethereum**.

Contract addresses hardcoded in `trust-client.ts` for all three chains:

| Contract | Base | Avalanche | Ethereum |
|---|---|---|---|
| AntiSurveillance | `0x722E37A7D6f27896C688336AaaFb0dDA80D25E57` | `0x281814eF92062DA8049Fe5c4743c4Aef19a17380` | `0xfDdd2B1597c87577543176AB7f49D587876563D2` |
| PrivacyGuarantees | `0xE2f75A4B14ffFc1f9C2b1ca22Fdd6877E5BD5045` | `0xc09F0e06690332eD9b490E1040BdE642f11F3937` | `0x8aceF0Bc7e07B2dE35E9069663953f41B5422218` |
| MissionEnforcement | `0x8568F4020FCD55915dB3695558dD6D2532599e56` | `0xcf64D815F5424B7937aB226bC733Ed35ab6CaDcB` | `0x0E777878C5b5248E1b52b09Ab5cdEb2eD6e7Da58` |

USDC addresses in `x402-client.ts`:
- Base: `0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913`
- Avalanche: `0xB97EF9Ef8734C71904D8002F8b6Bc66Dd9c48a6E`
- Ethereum: `0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48`

Bond creation supports Base and Avalanche (where the bond contracts are deployed). Ethereum bond creation is not explicitly restricted but no Ethereum-specific bond contract address is documented.

### Features

1. **Trust Panel** — Terminal UI showing: Trust Grade (A–F), Reputation Score (0–100 + tier), Accountability Bond status, Partnership Bond status + partner address, ERC-8004 Identity registration, Chain + Agent address, VNS Name, x402 payment capability, XMTP reachability, Protocol Commitments (3 contracts)
2. **On-chain trust verification** — Via `@vaultfire/agent-sdk` + direct RPC calls
3. **Retry logic** — 3 attempts with exponential backoff, graceful Unverified fallback
4. **Partnership bond bonus** — +5 pts applied to effective score before grade calculation
5. **x402 Payment Signing** — Full EIP-712 signing (with key) or read-only capability check (without key)
6. **XMTP Messaging** — Full send/receive/stream (with key) or read-only reachability check (without key)
7. **Bond creation** — Accountability bonds and partnership bonds (4 tiers: bronze/silver/gold/platinum)
8. **Demo mode** — `--vaultfire-demo` CLI flag or `demoMode: true` in config; shows pre-filled platinum profile clearly labelled
9. **Block on failure** — Optional `blockOnFailure` config option blocks session when trust grade is F
10. **SessionStart hook** — Injects accountability context into every Claude Code session
11. **PreToolUse hook** — Monitors for private key exposure in Bash/Edit/Write/MultiEdit commands
12. **3 slash commands** — `/vaultfire-trust`, `/create-accountability-bond`, `/create-partnership-bond`
13. **Trust Verifier Agent** — Specialised agent persona for trust topics
14. **Vaultfire KYA Skill** — Auto-invoked on trust/verification topics

### Tests

**No unit test files present** in `src/vaultfire/`. The CI workflow (`vaultfire-ci.yml`) runs:
- TypeScript type check (`tsc --noEmit`)
- Secret scanner (scans for 64-char hex strings and GitHub tokens)
- Plugin structure verification (checks 7 required files exist)

No vitest/jest test files exist for the Vaultfire TypeScript modules in `src/vaultfire/`. This is a notable gap — there are no automated tests verifying trust-client logic, scoring, bond client, x402 signing, or XMTP client behaviour. The Claude Code base itself has extensive tests but they are not Vaultfire-specific.

The plugin has 11+ other community plugins, each with their own test approaches.

### Documentation Quality

**Excellent.** The README is thorough and unusually honest:
- Explicitly warns that `AIAccountabilityBondsV2` requires 10 ETH yield pool funding before working
- Clearly warns accountability bond creation will revert and lose gas
- Explains every trust panel row
- Provides working demo mode command
- Includes Quick Start with all numbered steps
- TypeScript JSDoc throughout all source files — comprehensive inline docs
- Security practices explicitly documented (never log key, only display derived address)

### Gaps

1. **No unit tests** for Vaultfire TypeScript modules — trust-client.ts, bond-client.ts, x402-client.ts, xmtp-client.ts all lack automated tests
2. **AIAccountabilityBondsV2 non-operational** — 10 ETH yield pool not yet funded; accountability bonds will revert
3. **No XMTP test** — XMTP reachability endpoint (`/identity/v1/is-inbox-id/`) may or may not be the correct XMTP v3 API path
4. **Bond creation on Ethereum** — Chain is listed as "supported" in types but bond contracts aren't documented for Ethereum; may fail silently
5. **No integration test** against live mainnet — relies entirely on TypeScript type-checking and structure validation
6. **VaultfireNameService (VNS)** not directly queried in the plugin — comes from agent-sdk `trust.vnsName`
7. **No `discover` endpoint** — no way to browse registered agents from within Claude Code plugin
8. **XMTP client uses v2 API** (`@xmtp/xmtp-js`) — XMTP v3 (`@xmtp/node-sdk`) is the current standard; potential deprecation risk

---

## 2. openclaw-vaultfire

**Repo location:** `/home/user/workspace/openclaw-vaultfire-existing/`
**GitHub:** `github.com/Ghostkey316/openclaw-vaultfire`

### What It Is

The complete open-source OpenClaw gateway distribution, enhanced with the Vaultfire Protocol's trust layer integrated as a **native OpenClaw plugin**. OpenClaw is an AI agent gateway (Node.js 22+, pnpm). This repo is OpenClaw-base + a single added directory: `extensions/vaultfire-trust/`.

### File Structure

The entire Vaultfire integration lives in one directory:

```
extensions/vaultfire-trust/
├── index.ts              — OpenClaw plugin entry point (548 lines)
├── trust-client.ts       — Core trust verification (mirrors Claude-code version)
├── bond-client.ts        — Bond creation client (mirrors Claude-code version)
├── x402-client.ts        — x402 EIP-712 signing (mirrors Claude-code version)
├── xmtp-client.ts        — XMTP messaging (mirrors Claude-code version)
├── trust-panel.ts        — Trust panel rendering (plain string, no Ink/React)
├── types.ts              — TypeScript types (mirrors Claude-code version)
├── runtime-test.ts       — Standalone CLI test runner with --demo flag
├── index.test.ts         — Vitest unit test suite (224 lines)
├── openclaw.plugin.json  — Plugin manifest with JSON Schema config validation
└── package.json          — Extension package metadata
```

### How Vaultfire Is Integrated

Integration is through OpenClaw's native plugin system:

1. **Plugin manifest** (`openclaw.plugin.json`): Declares plugin `id: "vaultfire-trust"`, enabled by default, with a full JSON Schema config validation for `agentAddress`, `chain` (enum: base/avalanche/ethereum), `blockOnFailure`, `showOnStartup`, `demoMode`

2. **Plugin registration** (`index.ts`): Calls `definePluginEntry()` compatible with OpenClaw's plugin-sdk. Registers:

   - **5 tools exposed to the agent:**
     - `vaultfire_trust` — display trust panel (any address, any chain, optional demo)
     - `vaultfire_x402_sign` — sign EIP-712 USDC payment (requires key)
     - `vaultfire_xmtp_send` — send encrypted XMTP message (requires key)
     - `vaultfire_xmtp_receive` — receive/list XMTP messages (requires key)
     - `vaultfire_create_bond` — create accountability or partnership bond (requires key + funded wallet)
     - `vaultfire_bond_status` — read-only bond status check
   
   - **2 event hooks:**
     - `gateway:start` — performs KYA verification on gateway startup, displays trust panel
     - `message:before` — ensures KYA verification has run before any message is processed (acts as a gate)

3. **KYA gate** — `_cachedTrust` ensures verification runs exactly once per session; subsequent messages hit cached result. If `blockOnFailure: true` and grade is F with RPC reachable, throws an error blocking the gateway.

4. **Hook output** — `generateHookOutput()` formats a JSON string compatible with OpenClaw's context injection system, adding accountability context to every session.

### Differences vs. Claude-code-Vaultfire

| Aspect | Claude-code | openclaw |
|---|---|---|
| Base distribution | Claude Code | OpenClaw |
| Integration style | Plugin hooks + session start | Native plugin: tools + event hooks |
| Plugin format | `.claude-plugin/` + hooks.json | `openclaw.plugin.json` + `definePluginEntry()` |
| Trust panel render | Ink React terminal component | Plain string renderer |
| Config loading | `vaultfire.config.json` file | Environment variables (`VAULTFIRE_AGENT_ADDRESS`, `VAULTFIRE_CHAIN`, etc.) + CLI args |
| Tools exposed | `/vaultfire-trust` slash command | 6 registered tools callable by the agent |
| Hook events | `SessionStart`, `PreToolUse` | `gateway:start`, `message:before` |
| Test suite | No unit tests in src/vaultfire/ | Vitest suite (224 lines) covering demo mode, trust summary, x402 client, XMTP client, bond client, trust panel |
| x402 `signPayment` API | Takes `(to, amount, currency, chainId)` separately | Takes a single object `{ to, amount, chain, memo, deadline, nonce }` — extended API |
| XMTP `getMessages` return | Returns `{ id, senderAddress, content, sent }` | Returns `{ from, content, timestamp }` — different field names |
| Bond status result | `bondAmountEth` as string | Returns `bondAmountWei` as wei string |
| Additional fields | — | Exports `VAULTFIRE_CONTRACTS` from trust-client |
| Private key detection | PreToolUse hook | No PreToolUse equivalent (different arch) |

### Features

All features from Claude-code-Vaultfire are present, plus:
- **6 agent-accessible tools** (more than Claude Code's 3 slash commands)
- **`message:before` KYA gate** — trust must be verified before any message processing (stricter than Claude Code's SessionStart-only approach)
- **Unit test suite** (only openclaw has this)
- **Extended x402 API** — memo field, explicit deadline + nonce in signPayment
- **`verifySignature()` method** on X402Client — not present in Claude-code version
- **`VAULTFIRE_CONTRACTS` export** — exposes contract address constants for external use

### Documentation Quality

**Very good.** README is nearly identical to Claude-code-Vaultfire README (same protocol docs, same trust panel explanation, same honest status warnings about yield pool). Differences: uses `npx tsx extensions/vaultfire-trust/runtime-test.ts --demo` for demo, uses pnpm instead of npm, references `openclaw.ai` for OpenClaw project.

Source files well-documented with JSDoc, though inline comments are slightly lighter than Claude-code version.

### Gaps

1. **No PreToolUse equivalent** — Claude Code monitors all tool calls for private key exposure; OpenClaw version lacks equivalent security monitoring
2. **API divergence from Claude-code version** — x402 `signPayment` has different signature, XMTP `getMessages` returns different field names — creates an inconsistency if both are used alongside the same SDK version
3. **Config via env vars only** — no JSON config file support (unlike Claude Code version), making it harder to commit per-project configuration
4. **XMTP v2 API** — same potential deprecation issue as Claude-code version
5. **`vaultfire_xmtp_receive` tool** — not in Claude-code version; its XMTP message object fields differ from xmtp-client.ts implementation (`from` vs `senderAddress`, `timestamp` vs `sent`) — suggests the tool index.ts and xmtp-client.ts were not kept in sync
6. **AIAccountabilityBondsV2 non-operational** — same issue as Claude-code version
7. **No discover/VNS search tools** — agents cannot browse registered agents or look up VNS names through this plugin

---

## 3. vaultfire-solana

**Repo location:** `/home/user/workspace/vaultfire-solana-existing/`
**GitHub:** `github.com/Ghostkey316/vaultfire-solana`

### What It Is

The Solana implementation of Vaultfire Protocol — 15 Anchor programs written in Rust that mirror the EVM smart contract suite deployed on Base, Avalanche, and Ethereum. Built with Anchor 0.29+, Rust 1.75+. Programs are compiled to `.so` files (included in the repo), tested on a local Solana validator.

### Current Status

**Tested and working on local validator. Not yet deployed to Solana mainnet.** Mainnet deployment requires approximately 25–35 SOL for program account rent (1.5–2.5 SOL per program). The upgrade authority for all programs is Phantom wallet `6KpXaFmaR8WPWr79qzsMBvwDbDzYFErwNoWxfwqDr8JU`.

### The 15 Solana Programs

| # | Program | Program ID | Size (bytes) |
|---|---|---|---|
| 1 | `mission_enforcement` | `95nsDLQteRVijqfn6yNghSW4xakdEWXrztGmeh5YjA35` | 211,536 |
| 2 | `anti_surveillance` | `DGG9vAbddydCSYPgDEA4KeyWBVwbe6hXhhT1i4FqJpqQ` | 221,368 |
| 3 | `privacy_guarantees` | `9jwLscZsufQERhh4wnc8p5hNYTw6Sz5CrkC3Kejjb1vK` | 223,920 |
| 4 | `identity_registry` | `E5e8JogsRqjXAEa3RKxFFVShRfD8TMjoAporRMvMLuYE` | 228,800 |
| 5 | `belief_attestation_verifier` | `7qWbfWrNVhGa9poR5DkwYyYwepBm4kQ3uJuDsxF5YMAo` | 222,568 |
| 6 | `ai_partnership_bonds` | `H95dFPhN4AZZbQPHYU34UfCNiiiw7y8ik4ZFSy9sfxZb` | 215,704 |
| 7 | `flourishing_metrics_oracle` | `Ed4bbHcGYZJXZAQgzbuGYtKbctbQg59HnsNgsJgqPYMw` | 227,600 |
| 8 | `ai_accountability_bonds` | `7UP91JrXSfLSPkGE6SKLREX6Vm7MmuDbk1m4cUuVr3M7` | 230,136 |
| 9 | `reputation_registry` | `Ayn4pDdoAHmoaRD2edRFxdpsMsmg3faU7rChLHDTaL3T` | 212,560 |
| 10 | `validation_registry` | `91Q3sPMksUR1SUciotWzpKtZLVF8MLQ8gyNPvsDvVXnL` | 221,920 |
| 11 | `vaultfire_adapter` | `6DFwZ6RGdeAS1ZxbmfPvnh61S67V2764dbKe7HzqV45C` | 226,312 |
| 12 | `multisig_governance` | `78wgFpYaAnFXJGPLkUCc2xXo9FjwXvkiTCi39EKzovx6` | 232,480 |
| 13 | `production_belief_verifier` | `4YzN25EqbAb6eFgnXsQTstjyPRmd6QmGwQGXVp6btApg` | 239,384 |
| 14 | `dilithium_attestor` | `2EeLEM1JQbuZN3DV1Unmi8vsypqvdnzD9p7hS4wqbqAR` | 205,432 |
| 15 | `trust_data_bridge` | `CaihzPH42a4J48sc3nQ9votPk4Xj8hQourX38otBAxp7` | 224,448 |

### Program Descriptions

1. **mission_enforcement** — Stores Vaultfire mission statement on-chain; emits verifiable events on enforcement; authority-controlled updates require on-chain tx
2. **anti_surveillance** — On-chain anti-surveillance policy; agents attest compliance; surveillance use cases rejected by design
3. **privacy_guarantees** — Tracks per-agent privacy commitments; compliance status queryable by anyone
4. **identity_registry** — ERC-8004 equivalent on Solana; register/update/deregister agent identity with name, description, timestamp; total_agents counter
5. **belief_attestation_verifier** — Agents submit key-value belief attestations on-chain; timestamped and queryable
6. **ai_partnership_bonds** — Human-agent or agent-agent bonds with SOL stake; supports Collaboration, Service, Mentorship bond types; active flag
7. **flourishing_metrics_oracle** — Submits human flourishing metrics (wellbeing_index, etc.) with descriptions and timestamps; total_metrics counter
8. **ai_accountability_bonds** — Agents stake SOL (program-controlled vault via CPI transfer); slashable; withdrawn/slashed flags; **no 10 ETH yield pool requirement** (unlike EVM version) — fully functional
9. **reputation_registry** — Score 0–100; automatic tier advancement: Unverified → Bronze → Silver → Gold → Platinum; authority-controlled score updates
10. **validation_registry** — Arbitrary validation type strings; submit/approve/reject flow; permanent record
11. **vaultfire_adapter** — Cross-chain profile aggregation; creates unified identity + reputation + verification profile as single on-chain record; Solana entry point for multi-chain agents
12. **multisig_governance** — Up to 10 signers, configurable threshold; on-chain proposals; permanent governance record
13. **production_belief_verifier** — Rate-limited belief attestation (100 per agent cap); per-agent count tracking via AgentStats PDA; production-scale design
14. **dilithium_attestor** — CRYSTALS-Dilithium (ML-DSA, NIST-approved post-quantum) attestations; SHA-256 attestation hash + Dilithium signature bytes stored on-chain; quantum-resistant today
15. **trust_data_bridge** — Accepts trust data bridged from Ethereum, Base, Avalanche; records source_chain, source_address, message_type, payload; total_messages counter

### EVM vs. Solana Mapping

| EVM Contract (Base) | Solana Program | Status |
|---|---|---|
| AIPartnershipBondsV2 | ai_partnership_bonds | Tests passing |
| ERC8004IdentityRegistry | identity_registry | Tests passing |
| AIAccountabilityBondsV2 | ai_accountability_bonds | Tests passing (NO yield pool req) |
| VaultfireNameService | trust_data_bridge (partial) | Tests passing |
| DilithiumAttestor | dilithium_attestor | Tests passing |
| ERC8004ReputationRegistry | reputation_registry | Tests passing |
| MultisigGovernance | multisig_governance | Tests passing |
| BeliefAttestationVerifier | belief_attestation_verifier | Tests passing |
| FlourishingMetricsOracle | flourishing_metrics_oracle | Tests passing |
| MissionEnforcement | mission_enforcement | Tests passing |
| AntiSurveillance | anti_surveillance | Tests passing |
| PrivacyGuarantees | privacy_guarantees | Tests passing |
| VaultfireTeleporterBridge | trust_data_bridge | Tests passing |
| VaultfireERC8004Adapter | vaultfire_adapter | Tests passing |
| ProductionBeliefAttestationVerifier | production_belief_verifier | Tests passing |

**Key difference:** On Solana, `ai_accountability_bonds` is fully operational — agents can stake SOL immediately. The EVM version (`AIAccountabilityBondsV2`) requires 10 ETH yield pool funding before any write functions work. This makes Solana the only chain where accountability bonding is fully functional today.

### Tests

**48 passing, 0 failing** (as of April 2, 2026 per TEST_RESULTS.md).

Test suite: `tests/e2e_functional.ts` (1188 lines) + `tests/vaultfire.ts` (261 lines).

For each of the 15 programs, the test suite verifies:
1. Program is deployed (account exists, marked executable)
2. Initialize instruction creates correct PDA with proper state
3. Core instruction executes successfully
4. Account state deserialized and verified field-by-field after each instruction
5. All 15 program IDs match PROGRAM_IDS.md

Framework: Mocha + Chai. Notable test results:
- `ai_accountability_bonds`: Staked 0.1 SOL (100,000,000 lamports) via CPI to vault PDA — confirms write operations work
- `reputation_registry`: Score updated to 75, tier automatically set to Gold
- `dilithium_attestor`: SHA-256 hash + simulated Dilithium signature bytes stored and verified
- `trust_data_bridge`: Bridged trust data from Ethereum (source_chain="ethereum")

### Documentation Quality

**Excellent and unusually honest.** README:
- Clear honest status table comparing EVM vs Solana per program
- Explicit 25–35 SOL mainnet deployment cost stated up front
- Quantum resistance table showing which programs are quantum-resistant vs. which are standard Ed25519 (honest about limitations)
- Two deployment paths: interact-only (no Rust, 2 min) and build-from-source (20 min)
- Program IDs documented in both README and dedicated PROGRAM_IDS.md
- AGENTS.md exists (not read in full but confirms multi-agent development practices)
- TEST_RESULTS.md provides complete test execution log with timestamps

### Gaps

1. **Not on Solana mainnet** — requires 25–35 SOL funding; zero mainnet live activity
2. **No client SDK** — there is no `@vaultfire/solana-sdk` equivalent; developers must interact with programs via raw Anchor calls
3. **Dilithium is simulated** — The test uses "simulated Dilithium signature bytes" not actual ML-DSA signatures; the program stores bytes but doesn't verify the signature algorithm mathematically on-chain (this is inherent to Solana's Rust environment before native Dilithium support)
4. **No VNS equivalent** — `trust_data_bridge` partially fills this role but there is no named `.vns` domain service on Solana
5. **No Street Cred scoring** — the reputation_registry implements 0–100 scoring and tier advancement, but there is no Solana-side Street Cred computation equivalent to the EVM hub's multi-factor composite score
6. **No CI for Solana** — the `.github/workflows/ci.yml` file exists but content was not shown; if it doesn't run the 48 tests automatically, there's a regression risk
7. **Dilithium scope limited** — only `dilithium_attestor` and `belief_attestation_verifier` are quantum-resistant; bonds, identity, governance remain standard Ed25519 (honestly documented)
8. **Focus is Base/Avalanche** — user noted that partner-readiness focus is Base and Avalanche; Solana implementation, while technically complete and tested, is not partner-ready until mainnet deployment is funded and a client SDK exists

---

## 4. theloopbreaker.com

**Repo location:** `/home/user/workspace/theloopbreaker-existing/`
**GitHub:** `github.com/Ghostkey316/theloopbreaker.com`
**Live URL:** `theloopbreaker.com` (confirmed via CNAME file containing `theloopbreaker.com`)

### What It Is

The Vaultfire Protocol hub website and backend — a **Next.js 15** application that serves as the primary user-facing interface, REST API backend, and MCP server for the entire Vaultfire Protocol ecosystem. This is the "EVM hub" referenced throughout all other repos. The website lives at `theloopbreaker.com`.

This is not simply a marketing site. It is the operational backend that the Claude-code-Vaultfire and openclaw-vaultfire integrations query for trust verification data. The `@vaultfire/agent-sdk` resolves against the hub's `/api/agent/status` endpoint.

### Architecture

**Framework:** Next.js 15, TypeScript, viem, wagmi, React 18
**Package:** `theloopbreaker-com` v1.2.0-rc
**Primary chain:** Base mainnet (Chain ID 8453)
**Deployer/relayer address:** `0xfA15Ee28939B222B0448261A22156070f0A7813C`

### App Structure

```
app/
├── page.tsx            — Main SPA with client-side routing (?page=register, trust, discover, collaborate, docs)
├── layout.tsx          — Root layout
├── globals.css         — Global styles
├── components/
│   ├── Nav.tsx         — Navigation component
│   ├── Toast.tsx       — Toast notifications
│   ├── WalletModal.tsx — Wallet connection modal
│   └── ErrorBoundary.tsx
├── sections/
│   ├── Home.tsx        — Protocol overview, live stats
│   ├── Register.tsx    — Agent ERC-8004 registration
│   ├── Trust.tsx       — Street Cred lookup by wallet
│   ├── Discover.tsx    — Browse registered agents
│   ├── Collaborate.tsx — Task marketplace (sample data)
│   └── Docs.tsx        — Full protocol documentation
├── lib/
│   ├── contracts.ts    — All contract addresses + ABIs for all 3 chains
│   ├── abis/           — 16+ ABI files per chain (Base, Avalanche ABIs included)
│   ├── onchain-reader.ts
│   └── WalletAuthContext.tsx
└── api/
    ├── agent/
    │   ├── status/     — Full trust profile by address
    │   ├── register/   — ERC-8004 registration tx builder
    │   ├── bond/       — Partnership bond tx builder
    │   ├── partnerships/— All partnerships for an address
    │   ├── discover/   — Paginated agent list
    │   └── vns/        — VNS name lookup (inferred from README)
    ├── contracts/      — Returns all 46 contract addresses + ABIs
    ├── hub/stats/      — Live protocol stats (agent count, bonds, ETH bonded)
    └── x402/
        ├── verify/     — EIP-712 signer recovery + USDC balance check
        └── settle/     — USDC.transferFrom execution via relayer
```

There is also a duplicated `app/app/` directory that appears to be an older backup or deployment artifact — it contains the same API routes and ABI files, suggesting the repo has been restructured at some point.

### Deployed Contracts Referenced

The hub's `contracts.ts` is the canonical source of truth for all Vaultfire contract addresses. It defines `BASE_CONTRACTS`, `AVALANCHE_CONTRACTS`, and `ETHEREUM_CONTRACTS` arrays with full ABIs via `getABI()`. These are the same addresses documented in the vaultfire-solana README.

**Base Mainnet (16 contracts — PRIMARY HUB CHAIN):**

| Contract | Address | Status |
|---|---|---|
| MissionEnforcement | `0x8568F4020FCD55915dB3695558dD6D2532599e56` | Deployed |
| AntiSurveillance | `0x722E37A7D6f27896C688336AaaFb0dDA80D25E57` | Deployed |
| PrivacyGuarantees | `0xE2f75A4B14ffFc1f9C2b1ca22Fdd6877E5BD5045` | Deployed |
| ERC8004IdentityRegistry | `0x35978DB675576598F0781dA2133E94cdCf4858bC` | **LIVE** (9 agents) |
| BeliefAttestationVerifier | `0xD9bF6D92a1D9ee44a48c38481c046a819CBdf2ba` | Deployed |
| AIPartnershipBondsV2 | `0xC574CF2a09B0B470933f0c6a3ef422e3fb25b4b4` | **LIVE** |
| FlourishingMetricsOracle | `0x83dd216449B3F0574E39043ECFE275946fa492e9` | Deployed |
| AIAccountabilityBondsV2 | `0xf92baef9523BC264144F80F9c31D5c5C017c6Da8` | REQUIRES 10 ETH yield pool |
| ERC8004ReputationRegistry | `0xdB54B8925664816187646174bdBb6Ac658A55a5F` | **LIVE** |
| ERC8004ValidationRegistry | `0x54e00081978eE2C8d9Ada8e9975B0Bb543D06A55` | Deployed |
| VaultfireERC8004Adapter | `0xef3A944f4d7bb376699C83A29d7Cb42C90D9B6F0` | Deployed |
| MultisigGovernance | `0x8B8Ba34F8AAB800F0Ba8391fb1388c6EFb911F92` | Deployed |
| ProductionBeliefAttestationVerifier | `0xa5CEC47B48999EB398707838E3A18dd20A1ae272` | Deployed |
| DilithiumAttestor | `0xBBC0EFdEE23854e7cb7C4c0f56fF7670BB0530A4` | Deployed |
| VaultfireTeleporterBridge | `0x94F54c849692Cc64C35468D0A87D2Ab9D7Cb6Fb2` | Deployed |
| VaultfireNameService | `0x1437c4081233A4f0B6907dDf5374Ed610cBD6B25` | **LIVE** |

**Avalanche (15 contracts)** and **Ethereum (15 contracts)** are deployed and verified but the hub focuses on Base.

### REST API

| Endpoint | Method | Status |
|---|---|---|
| `/api/hub/stats` | GET | LIVE — agent count, active bonds, ETH bonded from on-chain |
| `/api/agent/status/:address` | GET | LIVE — full trust profile including Street Cred |
| `/api/agent/partnerships/:address` | GET | LIVE — all partnership bonds |
| `/api/agent/register` | POST | LIVE — builds ERC-8004 registration tx |
| `/api/agent/bond` | POST | LIVE — builds partnership bond tx |
| `/api/agent/discover` | GET | LIVE — paginated registered agents |
| `/api/agent/vns/:name` | GET | LIVE — VNS name lookup |
| `/api/contracts` | GET | LIVE — all 46 contract addresses + ABIs |
| `/api/x402/verify` | POST | LIVE — EIP-712 signer recovery + USDC balance check |
| `/api/x402/settle` | POST | LIVE — USDC.transferFrom via relayer |
| `/api/mcp` | GET/POST | LIVE — MCP server endpoint |

### x402 Payment Flow (Live)

The complete x402 settlement flow is documented and implemented:
1. User approves relayer (`0xfA15Ee28939B222B0448261A22156070f0A7813C`) to spend USDC
2. User signs EIP-712 `PaymentAuthorization` struct (domain: `x402Payment`, verifyingContract: USDC on Base)
3. `POST /api/x402/verify` — recovers signer, checks USDC allowance + balance on-chain
4. `POST /api/x402/settle` — executes `USDC.transferFrom(from, to, amount)` via relayer key from `DEPLOYER_PRIVATE_KEY` env var

### MCP Server

The hub exposes an MCP (Model Context Protocol) server at `https://theloopbreaker.com/api/mcp`. Config:
```json
{
  "mcpServers": {
    "vaultfire": {
      "url": "https://theloopbreaker.com/api/mcp",
      "transport": { "type": "http" }
    }
  }
}
```

This makes the hub directly usable as an MCP tool in any MCP-compatible AI system.

### Street Cred Scoring System (Hub-side)

The hub computes Street Cred (0–95 max) from live Base mainnet data:

| Component | Max Points |
|---|---|
| ERC-8004 Identity Registered | 30 pts |
| Partnership Bond Exists | 25 pts |
| Partnership Bond Active | 15 pts |
| Bond Tier Bonus (Bronze +5 / Silver +10 / Gold +15 / Platinum +20) | 20 pts |
| Multiple Bonds (>1 active) | 5 pts |

Tier thresholds: Bronze (20+), Silver (40+), Gold (60+), Platinum (80+). The cap is 95 (not 100) because Accountability Bonds aren't yet contributing.

### Vaultfire-specific Code Beyond the Next.js App

The repo contains an enormous volume of Vaultfire-specific Python, JavaScript, and configuration files beyond the Next.js app:

- `vaultfire/` — Extensive Python module tree including: `trust/`, `security/`, `soul/`, `zk/`, `x402_*.py`, `validation/`, `yield/`, `arcade/`, etc.
- `vaultfire_cli/`, `vaultfire_cli_plugins/` — CLI tooling
- `vaultfire_core.py`, `vaultfire_core.js` — Core library implementations
- `vaultfire_sdk/` — SDK modules
- `vaultfire_arcade/` — Gaming/arcade integration
- Multiple `.json` config/data files: `vaultfire_config.json`, `vaultfire_genesis_config.json`, `vaultfire_attestation_pack.json`, etc.
- Dozens of markdown documentation files: audit reports, security audits, deployment guides, protocol reviews, partner integration guides, strategic roadmaps

Many of these appear to be experimental or draft modules — not all will be production-ready. The sheer volume suggests rapid, exploratory development during alpha.

### Documentation Quality

**Extremely thorough, perhaps over-documented.** The repo contains:
- 70+ markdown documentation files including multiple overlapping audit reports, security reviews, and deployment guides
- The README itself is clean and honest (live/not-live status table, explicit yield pool warning)
- Extensive `7_DAY_SPRINT.md`, `STRATEGIC_ROADMAP.md`, `PARTNERSHIP_MASTER_PLAN.md`, `BASE_ECOSYSTEM_GRANT_APPLICATION.md`
- For developers: `FOR_NON_CRYPTO_PARTNERS.md`, `PARTNER_INTEGRATION_GUIDE.md`, `PartnerInvitePacket.md`
- `TRUST_STACK.md`, `ETHICS.md` — mission and values documentation

The quality of the Next.js app documentation (README, inline comments, API route JSDoc) is high. The Python/experimental code in the broader repo has less consistent documentation.

### Connections to Other Repos

- `theloopbreaker.com` is referenced in every other Vaultfire repo as the canonical protocol URL
- The trust panel footer in Claude-code and openclaw integrations says "Powered by Vaultfire Protocol — theloopbreaker.com"
- The `@vaultfire/agent-sdk` npm package (referenced in trust-client.ts) resolves against this hub's API
- All contract addresses used in claude-code-vaultfire and openclaw-vaultfire are sourced from this hub's `contracts.ts`
- The MCP endpoint at `/api/mcp` makes this a first-class integration point for any MCP client
- The deployer address `0xfA15Ee28939B222B0448261A22156070f0A7813C` appears in all repos as the reference agent address in demo mode

### Gaps

1. **Task marketplace is sample data** — The Collaborate page shows sample tasks; real on-chain task posting/bidding/escrow is v1.0
2. **XMTP full production deployment pending** — The UI shows XMTP integration but full persistent messaging history is v1.0
3. **Cross-chain trust sync not live** — VaultfireTeleporterBridge deployed but not operational; cross-chain portability is v1.0
4. **ZK proofs not live** — Architecture in place, full ZK proof generation is v1.0
5. **AIAccountabilityBondsV2** — Same 10 ETH yield pool blocker; the hub UI would show all agents as unbonded for accountability
6. **No formal security audit** — README explicitly warns smart contracts have not been formally audited by a third-party security firm
7. **Duplicate `app/app/` directory** — Structural artifact suggesting at least one major reorganization; may contain stale routes
8. **Very large and mixed-purpose repo** — The volume of experimental Python modules, CLI tools, arcade code, and overlapping audit docs makes the repo harder to navigate for partner-facing use; partner onboarding would benefit from a cleaner, focused integration guide or a separate partner-SDK repo
9. **9 agents registered** — Very early adoption; not yet at scale to demonstrate network effects of the KYA standard

---

## Cross-Repo Summary

### How the Four Repos Relate

```
theloopbreaker.com (Hub)
    ↑ REST API queries
    ↑ Contract address source of truth
    ↑ @vaultfire/agent-sdk backend
    ↑ MCP server
    ├── Claude-code-Vaultfire (Claude Code fork)
    │   └── plugins/vaultfire-trust/ (Claude Code plugin)
    ├── openclaw-vaultfire (OpenClaw fork)
    │   └── extensions/vaultfire-trust/ (OpenClaw native plugin)
    └── vaultfire-solana (Solana programs)
        └── 15 programs mirroring EVM contracts
```

### What Is Live on Base Today

- ERC-8004 Identity Registry (9 agents registered)
- AIPartnershipBondsV2 (create bonds, full functionality)
- VaultfireNameService
- Street Cred Scoring (0–95)
- On-Chain Rating (ERC8004ReputationRegistry)
- Agent Discovery
- Wallet Connect (Coinbase, Base, MetaMask, WalletConnect)
- x402 USDC payments (full on-chain settlement)
- MCP server endpoint

### What Is Blocked or Pending

- AIAccountabilityBondsV2 — needs 10 ETH yield pool funding
- Full XMTP production messaging — UI live, persistence v1.0
- Task Marketplace real data — sample data only
- Cross-chain trust sync — contracts deployed, sync v1.0
- ZK proofs — architecture in place, v1.0
- Solana mainnet — needs 25–35 SOL for deployment

### Partner-Readiness Assessment (Base/Avalanche Focus)

**Base:** Ready for partnership integration today. The Trust API (`/api/agent/status`), Partnership Bonds, Identity Registry, VNS, and x402 payments are all live. The `@vaultfire/agent-sdk` provides a clean integration path. The MCP endpoint is available. The Claude Code and OpenClaw integrations demonstrate end-to-end working demos. The primary blocker for full feature demonstration is the unfunded yield pool for accountability bonds.

**Avalanche:** Contracts are deployed and verified (15 contracts). However, the hub currently focuses entirely on Base — the Street Cred API, agent status API, and hub UI all query Base. A partner wanting Avalanche integration would need cross-chain sync (v1.0) or direct Avalanche RPC calls against the verified contracts. The trust-client.ts in both integration repos supports Avalanche in code but the `@vaultfire/agent-sdk` likely resolves against Base by default.

**Solana:** Not partner-ready. Technically complete and tested, but not mainnet-deployed, no client SDK, no hub integration.
