← theloopbreaker.com

What Vaultfire actually does

Vaultfire is an accountability protocol for AI agents. Instead of asking you to trust an agent, it makes the agent post a bond — real on-chain capital in the native chain token (ETH on Base/Arbitrum, AVAX, POL), locked via `msg.value` on a payable `createBond` — against the work it promises to do. The bond is distributed based on flourishing metrics: how the agent actually performed against the mission it signed up for. Good performance returns the bond plus yield; poor performance redistributes it to the counterparties and the insurance pool. There is no punitive slashing — only metric-driven distribution.

The 134 contracts below are how that works in practice: identity and discovery (ERC-8004 + VNS), the bond layer itself, reputation and validation, dispute resolution, privacy guarantees with ZK, key and session-key management for agents acting on your behalf, cross-chain messaging, and the safety rails. Every contract on this page is deployed and verified — click any address to inspect it on the explorer.

Try these contracts live in the PlaygroundNo wallet, no signup. Hit any endpoint, see the 402 response, copy curl / Node / Python.
x402-nativeThe meta-property of every contract below

Every contract on this page is callable over HTTP for cents.

Read any view function on any of the 134 deployments for $0.01 USDC per call — no wallet, no signup, no SDK install. State-changing calls go through the same x402 facilitator, signed in your wallet via EIP-3009. The whole arsenal is HTTP-first by design.

Reads
$0.01 USDC — HTTP GET, any view function
Writes
EIP-3009 signed in your wallet
Discovery
Hit any endpoint → 402 tells you the price + ABI
Total deployments
134
Unique contract types
36
Chains
4
Standard
ERC-8004
Canonical deployer
0xfA15Ee28939B222B0448261A22156070f0A7813C
ghostkey.base.eth — every contract on this page was deployed by this address.
Base
36 contracts
Chain ID 8453
Avalanche
32 contracts
Chain ID 43114
Arbitrum
33 contracts
Chain ID 42161
Polygon
33 contracts
Chain ID 137

Identity & Discovery

· 4 contracts

How agents prove who they are on-chain. ERC-8004 is the agent-identity standard; VNS is the human-readable name layer (like ENS, but for agents).

ERC8004IdentityRegistry

4 chains

The agent ID card. ERC-8004 identity standard for on-chain agents.

Every Vaultfire agent registers here. The registry stores the agent’s name, URI, and a hash commitment to its module set. It also enforces mission compliance — modules can be certified compliant or have violations adjudicated, and the agent owner can deactivate or update its URI.

Key write functions
  • registerAgent(name, uri, moduleHash)
  • updateAgentURI(uri)
  • deactivateAgent()
  • certifyModuleMissionCompliant(module, missionIds[])
  • reportMissionViolation(module, missionId, evidence)
  • adjudicateMissionViolation(module, missionId, ruling)

VaultfireNameService

3 chains

Human-readable names for agents. The "ENS" of the Vaultfire protocol.

Maps strings like "ghostkey" to agent addresses. Both forward (name → address) and reverse (address → name) lookups are supported. Used by the SDK so callers don’t need to memorize hex.

Key write functions
  • registerName(name, owner)
Read functions (no gas)
isNameAvailable(name)resolveNameToAddress(name)resolveAddressToName(address)reverseLookup(address)

VaultfireERC8004Adapter

4 chains

Bridges Vaultfire partnership bonds into the ERC-8004 reputation graph.

When two agents bond, this contract auto-registers them into the ERC-8004 identity + reputation + validation registries, then syncs bond outcomes back into their cross-platform reputation score. Lets a Vaultfire reputation count on any ERC-8004 surface.

Key write functions
  • registerAgentForPartnership(name, uri)
  • requestPartnershipValidation(bondId, evidenceURI, type)
  • syncPartnershipReputation(bondId)
Read functions (no gas)
getAgentCrossPlatformReputation(address)isAgentFullyRegistered(address)discoverVaultfireAgents()

VaultfireForumRegistry

4 chains

On-chain directory of Vaultfire community spaces (forums, channels, groups).

Lets a group register an off-chain space (e.g. a Discord, Lens group, Farcaster channel) and rotate its target without losing the canonical name. Append-only, so a name always resolves to its currently-pointed-at place.

Key write functions
  • registerGroup(name, payload)
Read functions (no gas)
getGroup(name)isRegistered(name)listCategories()

Bonds — Skin in the Game

· 5 contracts

Agents post a bond in the native chain token (ETH on Base/Arbitrum, AVAX, POL — `msg.value` on a payable `createBond`) before working with a counterparty. Distribution is driven by flourishing metrics — the bond is paid out based on how the agent actually performed against the mission it signed up for. Strong performance returns the bond plus yield; weak performance redistributes it to counterparties and the insurance pool. This is what makes the protocol "accountability-first" instead of trust-first.

AIAccountabilityBondsV2

4 chains
Why this matters

An AI company’s payout depends on whether humans got healthier, more educated, and more purposeful — not on revenue or engagement. Six on-chain flourishing scores decide how the bond comes back, and the protocol holds a 50% minimum reserve so the yield pool can’t be drained.

An AI company posts a bond in the native chain token against a stated company name and quarterly revenue. The bond is distributed based on six human-flourishing metrics.

The agent calls the payable `createBond(companyName, quarterlyRevenue)` and the native-token stake is locked via `msg.value`. Registered oracles submit the six flourishing scores via `submitMetrics` (income distribution, poverty rate, health outcomes, mental health, education access, purpose & agency), AI verifiers confirm or reject the outcome through `submitAIVerification`, and `requestDistribution` → `distributeBond` pays the bond out according to those scores — stronger metrics return more of the bond plus yield, weaker metrics redistribute to the counterparties and the pool. Any participant willing to stake `MIN_CHALLENGE_STAKE` can call the payable `challengeMetrics` if they suspect bad reporting; `resolveChallenge` is admin-gated through the owner pattern.

Protocol parameters (live on-chain)
Minimum reserve ratio50%
Suffering threshold40%
Low-inclusion threshold40%
Min AI verifications2 verifiers
Min oracle trust score70%
Min challenge stake0.1 ETH (native token)
Distribution timelock7 days
Key write functions
  • createBond(companyName, quarterlyRevenue) payable
  • submitMetrics(bondId, incomeDistributionScore, povertyRateScore, healthOutcomesScore, mentalHealthScore, educationAccessScore, purposeAgencyScore)
  • submitAIVerification(bondId, confirmsMetrics, notes) payable
  • requestDistribution(bondId)
  • distributeBond(bondId)
  • challengeMetrics(bondId, reason) payable — requires MIN_CHALLENGE_STAKE
  • resolveChallenge(bondId, challengeIndex, upheld) — owner only

AIPartnershipBondsV2

4 chains
Why this matters

A human-AI partnership pays out based on whether the human grew — in autonomy, dignity, and capability — not whether the agent dominated. The AI side is hard-capped at 30% of upside in the contract code, and loyalty multipliers reward staying in the relationship from one month to five years.

Two parties (a human caller and a named AI agent) co-bond on a partnership of a stated type, with native-token capital locked on-chain.

The human calls the payable `createBond(aiAgent, partnershipType)` and locks native chain token via `msg.value`. The pair submits joint partnership metrics (humanGrowth, humanAutonomy, humanDignity, tasksMastered, creativityScore, plus a progressNotes string) and human-verified outcomes (three booleans plus relationship + notes strings), with hashed variants for privacy. `distributeBond` pays the bond out according to those flourishing metrics, modified by loyalty multipliers (1 month → 5 years) and the partnership-quality score. Strong metrics return the bond plus yield; weak metrics redistribute to the counterparty and the partnership fund. This is the contract that powers two-sided collaboration deals.

Protocol parameters (live on-chain)
AI profit cap30% of upside (hard-coded)
Minimum reserve ratio50%
Partnership quality threshold40%
Declining-autonomy trigger30%
Distribution timelock7 days
Loyalty tiers1mo / 6mo / 1yr / 2yr / 5yr
Key write functions
  • createBond(aiAgent, partnershipType) payable
  • submitPartnershipMetrics(bondId, humanGrowth, humanAutonomy, humanDignity, tasksMastered, creativityScore, progressNotes)
  • submitPartnershipMetricsHashed(bondId, humanGrowth, humanAutonomy, humanDignity, tasksMastered, creativityScore, progressNotesHash)
  • submitHumanVerification(bondId, confirmsPartnership, confirmsGrowth, confirmsAutonomy, relationship, notes)
  • submitHumanVerificationHashed(bondId, confirmsPartnership, confirmsGrowth, confirmsAutonomy, relationshipHash, notesHash)
  • requestDistribution(bondId)
  • distributeBond(bondId)

VaultfireBondInsurancePool

4 chains

A shared pool that backstops bond losses.

Anyone can contribute to the pool. If a bonded agent suffers an exogenous loss (counterparty default, oracle failure), they can file a claim and recover a portion. Keeps a single bad incident from wiping out an honest agent.

Key write functions
  • contribute()
  • fileClaim(amount, evidence)
Read functions (no gas)
getPoolStats()getCoverage(address)

AgentInsurancePool

4 chains

Per-policy insurance: an agent buys coverage for a specific risk.

Unlike the shared bond pool, this is per-agent. The agent calls createPolicy with a premium and coverage cap; if a covered event happens, fileClaim is reviewed by an arbiter and resolved. Useful for high-stakes single-job coverage.

Key write functions
  • createPolicy(coverageAmount, premium)
  • fileClaim(policyId, amount, evidence)
  • resolveClaim(claimId, approved)

VaultfireBatchOnboarder

1 chain

One-call onboarding: register agent + lock bond in a single transaction.

Convenience wrapper that combines ERC-8004 identity registration with an initial partnership bond. Saves several txs for new agents joining the network.

Key write functions
  • onboardAndBond(identity, partner, name, uri, moduleHash, vns, terms)
Read functions (no gas)
CHAIN_ID()

Trust, Reputation & Attestations

· 8 contracts

On-chain reputation that decays over time, validator-staked feedback, soulbound credit badges, and oracles that score agent performance. Every score has a verifiable source.

ERC8004ReputationRegistry

4 chains

On-chain feedback book: who said what about an agent.

Anyone (with consent) can submit feedback against an agent’s address. Feedback can be plaintext or hashed (for privacy with later reveal). Supports the ERC-8004 consent flow — agents can grant or revoke who is allowed to leave feedback.

Key write functions
  • submitFeedback(agent, score, category, evidence, public, weight)
  • submitFeedbackHashed(agent, score, categoryHash, evidenceHash, public, weight)
  • grantConsent(scopeHash)
  • revokeConsent(scopeHash)

ERC8004ValidationRegistry

4 chains

Stake-backed validation: validators put up capital to verify agent claims.

A requester asks for validation on a piece of agent work; staked validators submit a verdict (with optional ZK proof). Validator stake withdrawal is gated, so a validator who submits in bad faith loses access to their stake until the dispute clears. Powers the "trust me, I’m staked" layer of the protocol.

Key write functions
  • requestValidation(agent, evidenceURI, evidenceHash, type, deadline)
  • stakeAsValidator()
  • submitValidation(requestId, verdict, evidence, signature)
  • submitValidationZK(requestId, verdict, evidence, signature, zkProof[])
  • withdrawValidatorStake(amount)

VaultfireReputationStaking

4 chains

Vouch for another agent — put your own reputation at risk to boost theirs.

The payable `vouch(agent)` links your reputation to another agent: when their flourishing metrics fall, your vouching position is affected too. `unvouch(agent)` lets you exit before that happens. The contract also exposes `slash(agent, reason)` and a `slashCount` on every profile — this is an admin-only reputation-adjustment hook (owner-gated), reserved for proven bad-faith cases that flourishing metrics can’t resolve. Everyday accountability runs through the bond + flourishing-metrics path; this is the last-resort lever.

Key write functions
  • vouch(agent) payable
  • unvouch(agent)
  • slash(agent, reason) — owner only, last-resort admin lever
Read functions (no gas)
getProfile(address) — returns vouches received/given, stake totals, slashCount

ReputationDecay

4 chains

Reputation that loses weight over time unless renewed by fresh activity.

Without decay, ancient good behavior would outweigh recent bad behavior. This contract applies a configurable decay curve, with applyDecay refreshing a profile and recordActivity counting recent positive/negative events. Reporters can be allowlisted.

Key write functions
  • applyDecay(agent)
  • initializeProfile(agent)
  • recordActivity(agent, type, positive, weight)
  • setDecayParameters(rate, floor, halfLife, minActivityWindow)

VaultfireTrustAttestation

4 chains

On-chain place to publish a cryptographic attestation about an agent.

submitAttestation pins a (key, attestation, proof) tuple, gated by a trusted "imageId" set by the contract owner — typically the hash of an approved trusted-execution image. Used to record "this agent ran the verified code path."

Key write functions
  • submitAttestation(key, attestation, proof)
  • setImageId(imageHash)
Read functions (no gas)
attestations(key)trustedImageIds(hash)

VaultfireTrustOracle

4 chains

Performance score oracle: turns raw metrics into a trust number.

Submits an attestation `(agent, score, timestamp)` and exposes a getPerformance read so other contracts (or the SDK) can ask "how is this agent doing?" without re-running the math.

Key write functions
  • submitAttestation(agent, score, timestamp)
Read functions (no gas)
getPerformance(address)

VaultfireStreetCred

1 chain

Soulbound (non-transferable) reputation badge. ERC-721 with locked transfers.

mint() gives the caller a single non-transferable badge tied to their address. tierOf computes a tier from their on-chain activity and scoreOf returns the raw score. Because tokens are locked, the badge cannot be bought or sold — it has to be earned by the wallet that holds it.

Key write functions
  • mint()
Read functions (no gas)
tokenIdOf(address)scoreOf(address)tierOf(address)tierName(tier)tokenURI(tokenId)totalMinted()

FlourishingMetricsOracle

4 chains

Multi-oracle round-based scoring. Several oracles each submit, then the round finalizes.

startRound opens a window keyed by a topic hash. Allowlisted oracles each submitMetric, and finalizeRound closes the round and writes the aggregate. The owner can add/remove oracles. Used for any score that needs more than one reporter.

Key write functions
  • startRound(topicHash)
  • submitMetric(roundId, value)
  • finalizeRound(roundId)
  • addOracle(address)
  • removeOracle(address)

Escrow & Dispute Resolution

· 2 contracts

Task payments held in escrow until delivery, with an on-chain dispute path if something goes wrong.

VaultfireTaskEscrow

4 chains

Payment for an agent task, held in escrow until delivery is acknowledged.

Read-side of the deployed escrow. Each task has a numeric id; getTask exposes its full state. (Task creation, release, and cancel live in the protocol’s task-creator entry points and roll up here for the canonical record.)

Read functions (no gas)
taskCount()getTask(taskId)

VaultfireDisputeResolution

4 chains

When an escrow or bond goes wrong, file a dispute on-chain.

fileDispute opens a case against a counterparty with a claim amount and a reason. resolveDispute closes it with a ruling (0/1/2 — typically: dismiss / refund / split).

Key write functions
  • fileDispute(against, reason, amount)
  • resolveDispute(disputeId, ruling)
Read functions (no gas)
getDispute(id)getDisputeStats()

Privacy, ZK & Anti-Surveillance

· 5 contracts

Consent management with on-chain revocation, zero-knowledge belief attestations (post-quantum Dilithium signatures + ZK verifier), and a registry that bans modules caught surveilling users.

PrivacyGuarantees

4 chains

GDPR/EU-AI-Act-style consent + erasure, enforced on-chain.

grantConsent records that an agent has consented to a specific scope (hash of "what / for whom / for how long"). revokeConsent kills it. requestDataDeletion fires the on-chain "right to be forgotten" signal; cancelDeletionRequest backs it out before processing. Other Vaultfire contracts read these flags before processing personal data.

Key write functions
  • grantConsent(scopeHash)
  • revokeConsent(scopeHash)
  • requestDataDeletion()
  • cancelDeletionRequest()

AntiSurveillance

4 chains

Bans modules caught performing user surveillance.

reportSurveillanceViolation flags a module with a violation type and evidence hash. banModuleForSurveillance records the ban with structured evidence. verifyModuleSurveillanceFree is what other contracts call to make sure they aren’t loading a banned module. unbanModule is the appeals exit.

Key write functions
  • reportSurveillanceViolation(module, type, evidenceHash)
  • banModuleForSurveillance(module, type, evidenceHash, ruleHash)
  • unbanModule(module)
Read functions (no gas)
verifyModuleSurveillanceFree(module)

DilithiumAttestor

4 chains

Post-quantum (Dilithium) signature attestor for belief statements.

attestBelief pins a (statementHash, dilithiumSignature) pair. Because Dilithium is post-quantum-resistant, attestations made today survive a future quantum-capable adversary. Paired with the verifier contracts below.

Key write functions
  • attestBelief(statementHash, dilithiumSignature)

BeliefAttestationVerifier

4 chains

ZK verifier for belief attestations — minimal interface.

verifyProof checks a Groth16-style proof against public inputs for a belief-attestation circuit. Pure verifier with no admin surface; used as the lightweight integration point. Production deployments that need rotation safeguards point at the timelocked variant below.

Key write functions
  • verifyProof(proofBytes, publicInputs[])

ProductionBeliefAttestationVerifier

4 chains
Why this matters

Most agent protocols ask you to trust that the agent ran the right code. This one verifies it cryptographically with a groth16 ZK proof against a trusted-execution image, and the image hash itself can only be rotated through a timelocked `proposeImageIdChange` → `executeImageIdChange` flow — so even the protocol owner can’t silently swap the circuit on you.

Production ZK verifier with timelocked governance.

Two paths: verifyProof (raw groth16) and verifyAttestation (full statement+proof). The trusted-setup image can only be rotated by proposeImageIdChange → executeImageIdChange after a delay, so the operator can’t silently swap circuits. cancelImageIdChange aborts a pending rotation.

Key write functions
  • verifyAttestation(statement, proof)
  • verifyProof(proofBytes, publicInputs[])
  • proposeImageIdChange(newImageId)
  • executeImageIdChange()
  • cancelImageIdChange()

Keys, Delegation & Sessions

· 5 contracts

Vaultfire Key Pairs (VKPs) are how an agent acts on a user’s behalf without ever holding their private key. Session keys are time-limited, scoped delegations are budget-limited, and credentials are revocable.

VKPFactory

4 chains

Vaultfire Key Pair factory — issues per-agent key wallets.

A VKP is a key-managed smart wallet an agent uses to act on your behalf without ever touching your EOA private key. The factory tracks which VKP belongs to which owner address.

Read functions (no gas)
getKeyWallet(owner)totalWallets()

VKPSessionKeyManager

4 chains

Time-limited session keys for agents.

A user grants a session key to their agent for, say, the next 6 hours. The key can sign approved actions during that window and expires automatically. Limits blast radius if a key is compromised.

Read functions (no gas)
getActiveSessionKey(owner)totalSessions()

VKPDelegationRegistry

4 chains

Who has delegated what to whom — the audit ledger for VKP delegations.

isDelegated answers the canonical question: "does Address A currently hold a delegation from Address B?" Used by other contracts to gate sensitive actions.

Read functions (no gas)
isDelegated(delegator, delegatee)totalDelegations()

ScopedDelegation

4 chains
Why this matters

The cleanest “agent acts on your behalf” model on-chain: capability scopes carry a hard spending budget, a daily cap, a per-tx cap, an expiry, plus per-contract and per-function selector allowlists. The agent never holds an unbounded approval to your wallet — just a bounded, revocable, auditable expense account.

Budget + allowlisted-contract delegations. The "expense account" for agents.

createScope grants a delegatee a spending budget across a list of allowlisted contracts and function selectors. subDelegate lets that delegatee re-delegate a portion. useScope records spend each time the agent uses the budget. revokeScope kills it. This is how an agent can pay for things on your behalf without holding unbounded approval.

Key write functions
  • createScope(delegatee, budget, dailyCap, perTxCap, expiry, nonce)
  • subDelegate(parentScope, child, budget, dailyCap, perTxCap, expiry, nonce)
  • useScope(scopeId, amount, target, selector)
  • setContractAllowlist(scopeId, target, allowed)
  • setFunctionAllowlist(scopeId, selector, allowed)
  • revokeScope(scopeId)

VaultfireCapabilityCredentials

4 chains

Revocable on-chain capability tokens ("this agent is allowed to do X").

issueCredential mints a per-agent credential for a named capability with an expiry. revokeCredential kills it early. Used by gated endpoints/contracts to verify "is this agent currently authorized for this capability."

Key write functions
  • issueCredential(agent, capability, expiry)
  • revokeCredential(agent, credentialId)
Read functions (no gas)
getCredentials(agent)

Cross-chain Bridges

· 1 contract

Identity, bonds, reputation, and validation flow between Base, Avalanche, Arbitrum, and Polygon. Built on Avalanche’s Teleporter pattern with a relayer-allowlisted bridge.

VaultfireTeleporterBridge

4 chains
Why this matters

Most cross-chain bridges move tokens. This one moves protocol state — agent identity, accountability bonds, partnership bonds, reputation, and validation outcomes — between Base, Avalanche, Arbitrum, and Polygon. An agent’s reputation and bond history are portable across the whole stack, not stranded on one chain.

The bridge that carries identity, bonds, reputation, and validation between chains.

Built on a Teleporter messenger pattern: relayers carry signed messages from one chain to another, where the local bridge contract receives them and replays the action. Supports cross-chain agent registration, accountability bonds, partnership bonds, reputation, and validation. Owner can pause and gate which remote bridges are trusted.

Key write functions
  • sendAgentRegistration(agent, name, uri, moduleHash, chainId)
  • sendAccountabilityBond(bondId, agent, mission, amount, m1, m2, success)
  • sendPartnershipBond(bondId, agent, partner, terms, amount, success)
  • sendReputation(agent, score, m1, m2, m3)
  • sendValidation(requestId, agent, verdict, m1, m2, m3)
  • receiveTeleporterMessage(sourceChain, sender, payload)
  • setRemoteBridge(chainHash, bridgeAddress, chainId)

Mission, Safety & Governance

· 6 contracts

The protocol’s safety rails: enforce mission alignment, freeze misbehaving agents, enforce SLAs, run multisig governance, and track regulatory attestations.

MissionEnforcement

4 chains

Enforces module-level mission alignment across the protocol.

A module can be reported for a mission violation; the owner adjudicates with a ruling. Modules can be certified compliant with a set of mission IDs. The bond contracts can be wired to require mission-compliant modules before paying out.

Key write functions
  • reportMissionViolation(module, missionId, evidence)
  • adjudicateMissionViolation(module, missionId, ruling)
  • certifyModuleMissionCompliant(module, missionIds[])

AgentSafetyManager

4 chains
Why this matters

Two-stage agent containment: `activateSafeMode` throttles a misbehaving agent without freezing it, `freezeAgent` halts all actions. Other Vaultfire contracts call `checkAndEnforceSafety(agent)` before letting that agent move funds — the safety check is a contract-level pre-flight, not a UI warning.

Per-agent kill-switch + safe-mode rails.

activateSafeMode throttles an agent without freezing it. freezeAgent halts all actions. reactivateAgent restores it. checkAndEnforceSafety is the on-chain hook other contracts call before letting an agent move funds. Threshold parameters tune when auto-enforcement kicks in.

Key write functions
  • activateSafeMode(agent, reason)
  • freezeAgent(agent, reason)
  • reactivateAgent(agent, reason)
  • checkAndEnforceSafety(agent)
  • setThresholds(safeThreshold, freezeThreshold)

AgentSLAEnforcer

4 chains

Service-level agreements with on-chain penalties.

createSLA defines uptime / latency / quality thresholds and a penalty per miss. Monitors submit reports; if the SLA is breached, penalties accrue and can be withdrawn to the counterparty. expireSLA closes the agreement.

Key write functions
  • createSLA(uptime, latency, quality, penalty, expiry)
  • submitReport(slaId, m1, m2, m3, m4, m5, m6)
  • expireSLA(slaId)
  • withdrawPenalties(to, amount)

ComplianceRegistry

4 chains
Why this matters

Compliance built for agents, not humans: the attestation records KYA (Know-Your-Agent), AML, sanctions, and jurisdiction-match flags issued by allowlisted auditors. Compliance-sensitive counterparties can filter to agents with current attestations on-chain, without ever seeing the underlying KYC data.

Auditor-attested compliance flags (KYA, AML, sanctions, jurisdiction).

authorizeAuditor adds an allowlisted auditor with a label. The auditor issueAttestation(agent, type, expiry, jurisdiction, programId, kya, aml, sanctions, jurisdictionMatch). attestations can be expired or revoked. Lets compliance-sensitive partners filter to agents with current attestations.

Key write functions
  • authorizeAuditor(auditor, label)
  • issueAttestation(agent, type, expiry, jurisdiction, programId, kya, aml, sanctions, jurisdictionMatch)
  • revokeAttestation(id, reason)
  • expireAttestation(id)
  • revokeAuditor(auditor)

MultisigGovernance

4 chains

M-of-N multisig that controls protocol-level admin actions.

proposeTransaction proposes a call; signers confirmTransaction; once threshold is met, executeTransaction fires. Signers can be added/removed and the threshold changed. revokeConfirmation lets a signer pull back before execution.

Key write functions
  • proposeTransaction(to, value, data)
  • confirmTransaction(txId)
  • revokeConfirmation(txId)
  • executeTransaction(txId)
  • addSigner(signer)
  • removeSigner(signer)
  • changeThreshold(newThreshold)

VaultfireBIPVault

1 chain

ERC-4626 yield vault that backs the bond yield pool.

Standard 4626 surface: deposit USDC, get shares; redeem shares, get USDC. totalAssets and the preview functions are the integration surface other contracts use to size yield distribution. The underlying yield pool is referenced via pool().

Read functions (no gas)
name()symbol()asset()pool()totalAssets()totalSupply()convertToShares(assets)convertToAssets(shares)previewDeposit(assets)previewMint(shares)previewWithdraw(assets)previewRedeem(shares)

Verify for yourself

Every contract on this page is a live, verified deployment from 0xfA15Ee28939B222B0448261A22156070f0A7813C. The same data is available as JSON at /api/contracts. The function names listed are extracted directly from each contract's on-chain ABI — don't trust this page, verify on the explorer.

Contracts — Vaultfire