# Deep-Dive Analysis: vaultfire-base-ref

**Repo path:** `/home/user/workspace/vaultfire-base-ref/`  
**Analysis date:** 2026-04-15  
**Analyst note:** Base is positioned as the primary hub chain for Vaultfire Protocol.

---

## 1. File Inventory (Non-Git)

The repo is minimal — only 2 files:

| File | Size (approx) | Purpose |
|------|--------------|---------|
| `README.md` | 273 lines | Primary (and only) documentation |
| `LICENSE` | 22 lines | MIT license, copyright 2026 Ghostkey316 |

**No source code.** No scripts, no contracts, no tests, no configuration files. The entire repo is documentation-only.

Compare to `vaultfire-avalanche`, which contains:
- `README.md`
- `LICENSE`
- `scripts/verify_contracts.py` (functional on-chain verification script)
- `tests/test_verify_contracts.py` (unit tests for the script)
- `.gitignore`
- `.pytest_cache/` directory

---

## 2. Contract Addresses — Full List

The README lists **16 contracts** deployed on Base mainnet (Chain ID: 8453):

| Contract | Address | Status in README |
|----------|---------|-----------------|
| ERC8004IdentityRegistry | `0x35978DB675576598F0781dA2133E94cdCf4858bC` | **LIVE** |
| AIPartnershipBondsV2 | `0xC574CF2a09B0B470933f0c6a3ef422e3fb25b4b4` | **LIVE** |
| AIAccountabilityBondsV2 | `0xf92baef9523BC264144F80F9c31D5c5C017c6Da8` | Deployed |
| ERC8004ReputationRegistry | `0xdB54B8925664816187646174bdBb6Ac658A55a5F` | **LIVE** |
| ERC8004ValidationRegistry | `0x54e00081978eE2C8d9Ada8e9975B0Bb543D06A55` | Deployed |
| VaultfireERC8004Adapter | `0xef3A944f4d7bb376699C83A29d7Cb42C90D9B6F0` | Deployed |
| VaultfireNameService | `0x1437c4081233A4f0B6907dDf5374Ed610cBD6B25` | **LIVE** |
| FlourishingMetricsOracle | `0x83dd216449B3F0574E39043ECFE275946fa492e9` | Deployed |
| MultisigGovernance | `0x8B8Ba34F8AAB800F0Ba8391fb1388c6EFb911F92` | Deployed |
| VaultfireTeleporterBridge | `0x94F54c849692Cc64C35468D0A87D2Ab9D7Cb6Fb2` | Deployed |
| DilithiumAttestor | `0xBBC0EFdEE23854e7cb7C4c0f56fF7670BB0530A4` | Deployed |
| ProductionBeliefAttestationVerifier | `0xa5CEC47B48999EB398707838E3A18dd20A1ae272` | Deployed |
| BeliefAttestationVerifier | `0xD9bF6D92a1D9ee44a48c38481c046a819CBdf2ba` | Deployed |
| MissionEnforcement | `0x8568F4020FCD55915dB3695558dD6D2532599e56` | Deployed |
| AntiSurveillance | `0x722E37A7D6f27896C688336AaaFb0dDA80D25E57` | Deployed |
| PrivacyGuarantees | `0xE2f75A4B14ffFc1f9C2b1ca22Fdd6877E5BD5045` | Deployed |

**LIVE count:** 5 (ERC8004IdentityRegistry, AIPartnershipBondsV2, ERC8004ReputationRegistry, VaultfireNameService, and VNS names endpoint)  
**Deployed (not LIVE):** 11

---

## 3. Consistency with Main Repo Base Addresses

### Primary reference: `redeployment-baseMainnet-1771950109844.json`

This is the most recent Base deployment JSON in the main repo. Comparing all 15 contracts it tracks:

| Contract | base-ref README | Redeployment JSON | Match |
|----------|----------------|-------------------|-------|
| ERC8004IdentityRegistry | `0x35978...58bC` | `0x35978...58bC` | ✓ |
| AIPartnershipBondsV2 | `0xC574...4b4` | `0xC574...4b4` | ✓ |
| AIAccountabilityBondsV2 | `0xf92b...6Da8` | `0xf92b...6Da8` | ✓ |
| ERC8004ReputationRegistry | `0xdB54...a55F` | `0xdB54...a55F` | ✓ |
| ERC8004ValidationRegistry | `0x54e0...3D06A55` | `0x54e0...3D06A55` | ✓ |
| VaultfireERC8004Adapter | `0xef3A...B6F0` | `0xef3A...B6F0` | ✓ |
| FlourishingMetricsOracle | `0x83dd...92e9` | `0x83dd...92e9` | ✓ |
| MultisigGovernance | `0x8B8B...F92` | `0x8B8B...F92` | ✓ |
| VaultfireTeleporterBridge | `0x94F5...6Fb2` | `0x94F5...6Fb2` | ✓ |
| DilithiumAttestor | `0xBBC0...0A4` | `0xBBC0...0A4` | ✓ |
| ProductionBeliefAttestationVerifier | `0xa5CE...272` | `0xa5CE...272` | ✓ |
| BeliefAttestationVerifier | `0xD9bF...2ba` | `0xD9bF...2ba` | ✓ |
| MissionEnforcement | `0x8568...9e56` | `0x8568...9e56` | ✓ |
| AntiSurveillance | `0x722E...25E57` | `0x722E...25E57` | ✓ |
| PrivacyGuarantees | `0xE2f7...5045` | `0xE2f7...5045` | ✓ |
| **VaultfireNameService** | `0x1437...D6B25` | **NOT IN redeployment JSON** | ⚠ |

**15 of 16 addresses match the main repo's most recent redeployment JSON exactly.**

### VaultfireNameService (16th contract)

The VaultfireNameService at `0x1437c4081233A4f0B6907dDf5374Ed610cBD6B25` is **not tracked in the main repo's `redeployment-baseMainnet-1771950109844.json`** (which captures 15 contracts). However, it **is confirmed** in a separate deployment record:

- File: `/home/user/workspace/main-vaultfire/deployments/vns-deployment-1774902931302.json`
- Address: `0x1437c4081233A4f0B6907dDf5374Ed610cBD6B25` ← matches base-ref exactly
- Network: `baseMainnet`, Chain ID: 8453
- Deployer: `0xfA15Ee28939B222B0448261A22156070f0A7813C` (same deployer)
- Timestamp: `2026-03-30T20:35:31.302Z` (deployed after the redeployment JSON, which explains its absence from that file)

**Conclusion: All 16 addresses in vaultfire-base-ref are correct and verifiable.**

### Secondary cross-check: `base-full-deploy-1771631040020.json` (older)

Two discrepancies exist between the **old** full deploy JSON and vaultfire-base-ref:
1. `PrivacyGuarantees`: old JSON has `0x227e27e7...` — base-ref has `0xE2f75A4B...`. The redeployment JSON confirms base-ref is correct (redeployment supersedes the full-deploy).
2. `VaultfireTeleporterBridge`: old JSON has `0x613585B7...` — base-ref has `0x94F54c84...`. Again, the redeployment JSON confirms base-ref is correct.

Both discrepancies are explained by a redeployment of those two contracts, which the `redeployment-baseMainnet-1771950109844.json` confirms. **vaultfire-base-ref tracks the latest (correct) addresses.**

---

## 4. Feature Coverage

The README documents the following feature set for Base:

### Live Features (5)
| Feature | Details |
|---------|---------|
| ERC-8004 Identity Registry | 9 agents registered on Base mainnet |
| Partnership Bonds | Mutual economic stakes |
| VNS Names (.vns) | Human-readable agent names — **Base only, not on Avalanche yet** |
| Street Cred Scoring (0–95) | Composite reputation from identity + bonds + peer feedback |
| On-Chain Rating (0–10,000) | Peer feedback via ERC8004ReputationRegistry |

### Deployed But Not Fully Active (6)
| Feature | Status Note |
|---------|------------|
| Agent Discovery | Lookup by wallet address (marked LIVE) |
| x402 Trust-Gated Payments | Full on-chain USDC settlement on Base |
| Wallet Connect | Coinbase Wallet, Base Wallet, MetaMask, WalletConnect |
| Accountability Bonds | Requires yield pool funding before activation |
| Cross-Chain Trust Sync | Full Base ↔ Avalanche ↔ Ethereum sync in v1.0 |
| Quantum-Resistant Attestations | CRYSTALS-Dilithium via DilithiumAttestor |

### Architecture Stage (1)
| Feature | Status Note |
|---------|------------|
| ZK Proofs | Verification contracts in place — full ZK in v1.0 |

### Street Cred Scoring Breakdown (documented)
| Component | Max Points |
|-----------|-----------|
| ERC-8004 Identity Registered | 30 |
| Partnership Bond Exists | 25 |
| Partnership Bond Active | 15 |
| Bond Tier Bonus | 20 |
| Multiple Bonds | 5 |
| **Total max** | **95** |

### Bond Tier System (documented)
- Bronze: 0.01 ETH  
- Silver: 0.05 ETH  
- Gold: 0.1 ETH  
- Platinum: 0.5 ETH

### Partnership Types (documented)
collaboration, delegation, service-provider, data-sharing, oracle-consumer

---

## 5. Documentation Quality

### Strengths
- **Contract table is complete and accurate** — all 16 contracts with full addresses, Basescan links, and live/deployed status clearly differentiated.
- **Quick Start section is genuinely usable** — includes working `viem`-based JavaScript code for both registering an agent and creating a partnership bond. Addresses in the code samples match the contract table.
- **Hub API section** documents 5 API endpoints with methods and descriptions, including a live `curl` example with realistic JSON response.
- **Street Cred scoring is fully documented** with a component breakdown table, tier thresholds, and max score explanation.
- **Architecture diagram** (ASCII) gives an accurate visual overview of how the modules connect.
- **Hub API endpoint** (`/api/contracts`) is documented for programmatic consumption of all 16 addresses and ABIs.
- **Tone is honest** — status distinctions (LIVE vs. Deployed vs. Architecture) are clearly maintained. VNS is flagged as Base-only. Accountability Bonds are flagged as needing yield pool funding. Cross-chain sync is explicitly deferred to v1.0.
- **Mission statement** is present and consistent with the broader protocol.
- **License** is correct MIT.

### Weaknesses / Gaps
1. **No verification script** — unlike `vaultfire-avalanche`, there is no `scripts/verify_contracts.py` equivalent for Base. A partner cannot independently verify contract deployment against Base mainnet without writing their own script.
2. **No tests** — `vaultfire-avalanche` has `tests/test_verify_contracts.py` with 11 test classes and comprehensive coverage. `vaultfire-base-ref` has nothing.
3. **No `.gitignore`** — minor, but the Avalanche repo has one.
4. **No "Core Protocol" section** — `vaultfire-avalanche` has a detailed "Core Protocol" section explaining each contract in prose. `vaultfire-base-ref` relies on the feature table but doesn't give per-contract explanations.
5. **No XMTP/agent-to-agent messaging documentation** — the Avalanche repo documents XMTP integration. The Base repo does not, even though Base is the primary hub and the hub at theloopbreaker.com runs on Base.
6. **No "Honest note" / caveats section on quantum resistance** — the Avalanche README explicitly notes which components are and aren't quantum-resistant. The Base README mentions Dilithium but does not include this nuance table.
7. **No separate "Cross-Chain" section** — the Avalanche README has a dedicated "Cross-Chain — Base and Avalanche" section with a side-by-side address table. The Base README only mentions cross-chain in the feature table.
8. **PrivacyGuarantees `PrivacyGuarantees` status** — the contract is listed as "Deployed" with no explanation of what it enforces, unlike the Avalanche repo's prose description.
9. **VaultfireNameService not in main repo's 15-contract redeployment JSON** — while the address is independently confirmed via a separate deployment record, the disconnect could confuse partners expecting all 16 addresses to appear in one canonical source.
10. **Main repo notes "12/15 contracts responding" on Base (Degraded status)** — the `vaultfire-base-ref` README does not mention that 3 contracts (`AIAccountabilityBondsV2`, `DilithiumAttestor`, `VaultfireTeleporterBridge`) have reverting view functions. This is an honest gap for a partner reference.

---

## 6. SDK Reference

**Yes — the SDK is referenced.** The README includes a dedicated "SDK" section:

```
## SDK

npm install @vaultfire/agent-sdk

Documentation: github.com/Ghostkey316/vaultfire-sdk
```

The SDK reference is brief but functional. It gives the npm install command and links to the SDK repo. No code examples using the SDK are provided — the Quick Start section uses raw `viem` calls directly. This is arguably more honest (SDK write methods are noted as unproven in the main repo) but means partners don't see an SDK-integrated workflow.

---

## 7. Gaps Compared to vaultfire-avalanche

| Dimension | vaultfire-avalanche | vaultfire-base-ref | Gap |
|-----------|--------------------|--------------------|-----|
| File count (non-git) | 5+ files | 2 files | Base lacks scripts and tests |
| Verification script | ✓ `scripts/verify_contracts.py` | ✗ None | **Major** |
| Unit tests | ✓ `tests/test_verify_contracts.py` | ✗ None | Significant |
| `.gitignore` | ✓ | ✗ | Minor |
| Contract count | 15 | 16 (incl. VNS) | Base has VNS extra — correct |
| Core Protocol prose section | ✓ (per-contract explanations) | ✗ (only table) | Notable |
| XMTP/messaging docs | ✓ | ✗ | Missing from Base |
| Quantum resistance caveats table | ✓ | ✗ | Missing from Base |
| Cross-chain address comparison table | ✓ | ✗ | Missing from Base |
| Hub API docs | ✗ | ✓ | Base has this extra |
| x402 payment detail | Basic mention | ✓ (LIVE) | Base is more prominent |
| USDC contract address documented | ✓ (Avalanche: `0xB97EF9...`) | ✗ | No USDC address in Base README |
| Bond tier currency | AVAX | ETH | Correct per-chain |
| Architecture diagram | ✓ | ✓ | Both have it |
| Street Cred scoring table | ✓ | ✓ | Both identical |
| SDK reference | ✓ | ✓ | Both present |
| Main repo link | ✓ | ✓ | Both present |
| Status badges | ✓ (Alpha/Avalanche/MIT) | ✗ | Base lacks badges |
| Honest "Note" box | ✓ (hub is on Base, not Avalanche) | ✗ | N/A but no equivalent |

---

## 8. Does It Serve as a Proper Partner Reference?

**Verdict: Yes, with notable limitations.**

### What it does well
- All 16 contract addresses are present, accurate, and independently verifiable (15 match the main redeployment JSON exactly; VaultfireNameService confirmed via separate deployment record).
- The Quick Start section is genuinely actionable — a developer can copy the `viem` code, substitute a private key, and interact with live Base mainnet contracts.
- Feature status is honestly communicated (LIVE vs. Deployed vs. Architecture).
- Hub API endpoints are documented, enabling REST-based integration without wallet or SDK.
- SDK is referenced with install command and link.
- Architecture diagram correctly represents the deployed system.
- The protocol's mission and positioning are clear.

### What it's missing for a partner
1. **No way to verify deployments without writing code.** The Avalanche ref includes a zero-dependency Python script that checks all contracts on-chain. Base has nothing equivalent. A partner must trust the README addresses or verify manually on Basescan.
2. **No disclosure of the 3 reverting-view-function contracts.** Main repo status says Base is "Degraded" — `AIAccountabilityBondsV2`, `DilithiumAttestor`, and `VaultfireTeleporterBridge` exist but have reverting view functions. Partners integrating these contracts would hit unexpected errors.
3. **No USDC contract address for x402 payments.** x402 trust-gated payments are marked LIVE and featured prominently, but the USDC address on Base is not documented (it's `0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913` for native USDC on Base).
4. **No per-contract prose.** The Avalanche README explains what each major contract does. The Base README relies on table entries only, which is sufficient for address lookup but not for understanding what to build against.
5. **No ABI snippets for the remaining Live contracts** (ERC8004ReputationRegistry, VaultfireNameService). Quick Start covers registerAgent and createBond but not reputation queries, VNS lookups, or any read operation.

### Summary rating

| Category | Score | Notes |
|----------|-------|-------|
| Address accuracy | 5/5 | All 16 verified against main repo deployments |
| Completeness of feature coverage | 3/5 | Covers major features, missing XMTP, USDC addr, per-contract detail |
| Documentation quality | 3/5 | Good Quick Start; missing verification script, test suite, prose sections |
| SDK coverage | 3/5 | Referenced, no usage examples |
| Consistency with main repo | 4/5 | Addresses correct; doesn't reflect Degraded status from main repo |
| Value as partner reference | 3/5 | Functional for basic integration; gaps in verifiability and edge-case disclosure |

**Overall: A solid starting point that covers the critical path (addresses, Quick Start, Hub API) but is materially thinner than the Avalanche partner reference, which ships with a runnable verification tool and test suite.**

---

## 9. Key Findings Summary

1. **Only 2 files** in the repo (README.md + LICENSE). Documentation-only, no code.
2. **16 contract addresses** listed — all 15 shared with the main redeployment JSON match exactly. VaultfireNameService (16th) confirmed via `main-vaultfire/deployments/vns-deployment-1774902931302.json`.
3. **VaultfireNameService is Base-only** (not on Avalanche yet) — this is correctly documented.
4. **No verification script** — the biggest gap vs. vaultfire-avalanche. Partners cannot run an on-chain check without writing their own tool.
5. **No unit tests** — Avalanche has 11 test classes; Base has none.
6. **Main repo's known "Degraded" status on Base** (3 contracts with reverting view functions) is **not disclosed** in the partner ref.
7. **No USDC address documented** despite x402 payments being marked LIVE.
8. **SDK is referenced** — install command and GitHub link present, no code examples.
9. **Documentation quality is good but not excellent** — accurate, honest about status distinctions, actionable Quick Start, but missing the depth of the Avalanche partner reference.
10. **PrivacyGuarantees address discrepancy with old deployment JSON is explained** — redeployment JSON confirms base-ref has the correct (newer) address.
