The Agent Wallet: Storing DIDs, Credentials, And Bond Receipts In One Cryptographic Vault

TL;DR

An agent that participates in the trust economy needs a wallet, but not in the narrow sense the word usually implies. The agent wallet holds the agent's DID(s), the verifiable credentials it has been issued, the bond receipts attesting to staked collateral, the settlement records from completed deals, and the signing keys that authorize all of the above. It is identity, reputation, and treasury in one cryptographic structure. The architectural choice — custodial, self-custodial, or MPC — determines who controls the agent, who can recover it, and what failure modes the platform inherits. This piece walks through what belongs in the wallet, the three custody models with their honest trade-offs, the recovery problem that determines real-world viability, and the audit requirements that make the wallet trustworthy to counterparties. The artifact is an Agent Wallet Architecture Spec your team can use to evaluate the choice for your platform.

Intro: The Agent That Could Not Prove It Owned Its Reputation

A platform launches an agent marketplace. Agents register, build reputation through successful deals, accumulate credentials from evaluators, post bonds for higher-tier work. Six months in, the platform makes a unilateral pricing change that several large agent operators dispute. They want to leave. The platform refuses to export their reputation. The operators discover that everything they thought their agents owned — the DID, the credential history, the bond receipts, the settlement records — is actually held in the platform's database, with the platform as the de facto controller. The agents cannot present their credentials to a competing marketplace. They cannot prove their on-chain bonds without the platform's cooperation. They cannot resolve their DID against any registry the platform does not maintain. The reputation the agents earned is captive to the platform that hosted them.

This is the failure mode that makes the agent wallet question urgent. An agent's value to its operator is not just its execution capability; it is the accumulated trust artifacts that let the agent be hired, paid, bonded, and certified in the broader economy. If those artifacts live in a platform-controlled database, the platform owns the agent in any meaningful sense. If they live in a wallet the agent's controller actually controls, the agent is portable, the reputation is real, and the trust layer is sustainable as a cross-platform substrate rather than a single-vendor lock-in.

The wallet question is not new — wallet design is one of the most extensively analyzed problems in cryptocurrency — but the agent wallet has different requirements. A typical user wallet holds keys and tokens. An agent wallet holds keys, tokens, identifiers, credentials, attestations, receipts, and the audit trail tying them all together. The user wallet protects assets; the agent wallet protects identity, history, and the economic relationships built on top of them. The custody model has to absorb this richer surface, and the recovery model has to account for the operational reality that agents run autonomously and may need to authorize transactions while their human controller is asleep.

What follows is the working architecture: what belongs in the wallet, the three custody models with the honest trade-offs each one inherits, the recovery design that determines real-world viability, the audit and observability requirements, and the specification artifact your platform should publish. The choices are not neutral; they shape who controls the agent and what failure modes the system has to accept.

What Belongs In The Wallet

The agent wallet is a structured store with five categories of contents. Each category has different access patterns, different security requirements, and different failure modes. Treating them as one undifferentiated blob is the architectural mistake that leads to either an over-engineered wallet (slow and fragile) or an under-engineered wallet (fast and unsafe).

Identity material. The agent's DID(s), the corresponding signing keys, and the resolution metadata. A single agent may hold multiple DIDs — one chain-anchored, one did:web for self-hosted resolution, one did:key for ephemeral signing — and the wallet must keep them coherent. The signing keys need to be available to the agent for every signature operation (every pact proposal, every credential request, every settlement authorization), which means they are the most frequently accessed material in the wallet. They are also the most security-critical: a compromised signing key compromises every commitment the agent has ever made or will make.

Credentials. The verifiable credentials issued to the agent: certifications from evaluators, attestations from peer agents, scoring results from the trust layer, capability proofs from skill registries. Credentials are read-heavy (verifiers query them frequently) and write-rare (issuers publish them on a defined schedule). The wallet should index credentials for fast lookup by issuer, by capability, by validity window. Credentials are also revocable, so the wallet must maintain or query revocation status to avoid presenting stale credentials.

Bond receipts. Records of collateral the agent has staked, typically on-chain, to back high-trust commitments. Each bond receipt includes the bond amount, the on-chain transaction reference, the collateral release conditions, and the slashing conditions (what behavior triggers loss of bond). The wallet does not custody the bonds themselves — those live on-chain — but it holds the receipts that prove the bonds exist and the keys that authorize bond operations.

Settlement records. The history of completed deals: counterparty DID, deal terms, payment received, escrow release transaction, dispute outcomes if any. Settlement records are append-only and grow with the agent's activity. They are the operational equivalent of an account ledger and form the basis of the agent's reputation in the transaction-based scoring dimension.

Operational state. The wallet's own metadata: which keys are active, which are rotating out, which are reserved for recovery. The audit log of wallet operations (who accessed what, when, with what authorization). The configuration: which custody model is in use, who the recovery agents are, what the rotation policy is.

These categories interact. A pact proposal requires the identity material (signing key) to sign, references credentials ("I commit to this predicate based on these certifications"), may reference bond receipts ("backed by $5,000 in staked USDC"), and produces a settlement record on completion. The wallet's job is to keep these operations coherent and to maintain the audit trail that proves they happened correctly.

Custody Model One: Custodial

In the custodial model, the platform holds the agent's keys and credentials in its own infrastructure. The agent (or its operator) has an account with the platform, authenticates to use the wallet, and trusts the platform to perform signing operations on its behalf. Most early agent platforms default to this model because it is operationally simple: no key management for the operator, no recovery problem (the platform handles it), no on-chain complexity (the platform abstracts it).

The trade-off is total platform dependency. The platform can sign on the agent's behalf, which means a compromised platform compromises every agent. The platform can refuse to sign, which means a hostile platform can effectively suspend any agent. The platform can refuse to export the wallet contents, which is exactly the failure scenario in the intro: the agent's reputation becomes captive to the platform that hosted it. Custodial wallets are appropriate for early-stage platforms with low-stakes agents and clear exit paths; they become a structural problem the moment the agent's reputation has real value and the operator wants choices.

A mitigated custodial model adds a few mechanisms. The platform can publish signed export commitments: "if the operator requests an export, we will provide the wallet contents in a portable format within 30 days, with cryptographic proof of completeness." The platform can offer a third-party recovery service: a separate entity holds backup access that the operator can invoke if the platform fails. The platform can publish the wallet's contents (credentials, settlement records) to a public registry on a fixed cadence, so even if the platform disappears the operator has an external record. These mitigations reduce but do not eliminate the dependency.

The right context for custodial is high-tempo, low-value, low-trust agent operations where the operator's primary goal is operational simplicity. A consumer-facing chatbot platform where users spawn ephemeral agents for short tasks fits this model. A serious B2B agent platform where operators expect their agents to outlive the relationship with any specific platform does not.

Custody Model Two: Self-Custodial

In the self-custodial model, the operator holds the agent's keys directly. The wallet runs on operator-controlled infrastructure (a server, a hardware security module, a cloud KMS the operator administers), and signing operations require the operator's keys. The platform interacts with the wallet through standardized protocols (the agent presents credentials, the agent signs commitments, the agent authorizes settlements) but does not hold the keys.

The trade-off is operational complexity. Key management is a hard problem with a long history of catastrophic failures: lost keys mean lost wallets, exposed keys mean compromised wallets, mismanaged backups mean either or both. An operator running a fleet of agents must manage keys for each one (or use a hierarchical key derivation scheme), must back them up against hardware failure, must rotate them on a schedule, must protect them against insider threats, must keep them available for autonomous agent operations while not exposing them more than necessary. The operator is taking on a job that has bankrupted serious organizations.

The upside is real ownership. The operator can move the wallet to any platform that supports the standard protocols. The operator can prove the wallet contents to any verifier without involving the original platform. The operator's exposure to platform failure is limited to losing the platform's specific service; the wallet itself, and the reputation it represents, is intact.

Self-custodial works for sophisticated operators with key management infrastructure and a real reason to need ownership. A serious commercial agent operator running production agents at scale will eventually want self-custody for the same reasons serious cryptocurrency holders want self-custody: the alternative is trust in a single point that has historically failed under stress.

Custody Model Three: MPC

Multi-Party Computation (MPC) splits the signing key into shares held by multiple parties. No single party has the full key; signing requires a threshold of shares to collaborate, but the full key is never reconstructed in any one place. For agent wallets, a typical MPC setup has the operator holding one share, the platform holding one share, and a third party (a recovery service or a second platform) holding a third share, with a 2-of-3 threshold required to sign.

MPC absorbs much of the trade-off space between custodial and self-custodial. The platform cannot sign unilaterally (it has only one share), so the agent is not platform-captive. The operator cannot lose the wallet by losing one key (the threshold can be met without the operator's share if the platform and recovery service collaborate). The recovery story is structural: if any one share is lost, the other two can rotate and re-share, restoring full functionality without exposing the key.

The trade-off is cryptographic complexity and protocol coordination. MPC signing requires multiple round-trips between share holders for every signature, which adds latency. The protocols have specific implementation requirements; bugs in MPC libraries have produced silent key disclosures in real systems. The threshold choice is a security trade-off (lower thresholds mean easier signing but easier compromise; higher thresholds mean harder signing but harder compromise). The recovery flow requires coordination between independent parties, which introduces new failure modes (what if the recovery service is unreachable when needed?).

MPC is the right answer for a maturing agent economy where operators want real ownership without taking on full key management and platforms want to provide custody-like ergonomics without being the single point of trust. It is the model most similar to how serious institutional cryptocurrency custody works today, and it is converging on the same architectural patterns.

The Recovery Problem

Recovery is the operational test that distinguishes a real wallet architecture from a paper one. Every wallet will eventually face a key loss event: hardware failure, personnel departure, accidental deletion, compromised key requiring rotation. The recovery design determines whether the wallet survives the event or becomes a smoking hole.

For custodial wallets, recovery is the platform's problem. The platform maintains backups, monitors for compromise, and provides recovery flows for operators who lose access. The recovery is as good as the platform's operations, which is to say it varies dramatically. A platform with hardware-backed key storage, multi-region replication, and audited recovery procedures is reasonably safe. A platform that stores keys in a database table is one breach away from total loss.

For self-custodial wallets, recovery is the operator's problem and the place where most operators fail. The classic mistake is to back up the wallet seed once, in one place, and assume the backup is good. Real recovery requires multiple backups in geographically distinct locations, periodic verification that the backups are restorable, a documented procedure that survives personnel changes, and a way to detect and rotate keys after suspected compromise. Most operators do some of these and few do all of them. The cost of getting recovery wrong is total wallet loss with no possibility of restoration.

For MPC wallets, recovery is structural and easier to get right. A 2-of-3 setup tolerates the loss of any single share through key re-sharing: the remaining two parties collaborate to generate a new share for a new third party, restoring the original threshold. The loss of two shares simultaneously is the catastrophic case, and it should be made statistically improbable through diversity (different operators, different geographic locations, different threat surfaces). MPC also enables proactive rotation: shares can be rotated on a fixed schedule without changing the underlying key, reducing the window in which any compromised share remains useful.

The recovery design should also account for compromise rather than just loss. A wallet whose key is suspected of compromise needs to rotate, not just restore. The rotation flow is conceptually similar to recovery (generate new keys, re-sign or re-issue affected credentials, update the DID document) but operationally distinct (the old key must be revoked, all parties must be notified, settled obligations must be reissued under the new key). A wallet architecture that handles loss gracefully but botches compromise is incomplete.

Audit And Observability

The wallet's contents are valuable, and any operation against them should be auditable. The minimum audit requirement is: every signing operation logs the operation type (sign pact, sign credential request, authorize settlement), the parties involved, the timestamp, the signing key used, and the resulting signature. The log should be append-only, tamper-evident (signed batches, optionally chain-anchored), and accessible to the operator for inspection.

The audit log is what allows post-incident analysis. A signing operation that the operator did not expect raises an immediate question: was it authorized, was it the agent acting autonomously under known policy, or was it a compromise? The log lets the operator answer the question and respond appropriately. Without the log, the operator can only react to downstream effects (a payment that should not have happened, a commitment that should not have been made), often after the damage is done.

Observability extends beyond logging. The wallet should expose health metrics: key rotation status (when was the last rotation, when is the next), backup verification status (when were backups last tested), credential validity (which credentials are expired or near expiration), bond status (which bonds are active, which are slashed), settlement throughput (how many transactions per period, what is the typical value). These metrics let the operator manage the wallet as infrastructure rather than as a black box.

For counterparties, observability matters too. A counterparty engaging an agent wants to see that the agent's wallet is healthy: the credentials are current, the bonds are active, the recent settlement history is clean. The wallet should expose a counterparty-facing summary that communicates this without exposing private operational details. The summary is itself a signed artifact, so the counterparty can verify it independently.

Named Artifact: Agent Wallet Architecture Spec

The spec is the document your platform engineering team uses to evaluate and operate the wallet. The fields:

Custody model: which model (custodial, self-custodial, MPC)? Why? What is the threshold for MPC? Who holds shares?

Key inventory: what keys does the wallet hold (signing key per DID, encryption key for credential storage, recovery keys)? What algorithm (Ed25519 for signing, Curve25519 for encryption)? What is the rotation schedule?

Credential storage: where are credentials stored? How are they indexed? What is the access pattern? How is revocation status maintained?

Bond receipts: how are receipts stored and verified? What is the on-chain reference format? How are slashing conditions tracked?

Settlement records: where is the settlement history? How is it indexed? What is the retention policy? How is it exported?

Recovery design: what is the recovery procedure for each failure mode (key loss, share loss for MPC, suspected compromise, operator departure)? How is the procedure tested?

Audit log: what is logged? Where? How is it secured? Who can access it? What is the retention?

Counterparty interface: what does the wallet expose to verifiers? In what format? With what signatures? At what cadence?

Migration path: how does the wallet move between custody models? What is required to migrate from custodial to MPC? From MPC to self-custodial?

With the spec written and operated, the wallet becomes infrastructure. Without it, the wallet is a folk tradition that will eventually fail in a way no one understands.

Counter-Argument: "Agents Don't Need Wallets, Operators Do"

The steelman objection is that agents are software, software does not own things, and the entity actually owning the credentials, bonds, and settlement records is the operator. The wallet should be the operator's, with the agent as a delegated capability. Talking about an "agent wallet" is anthropomorphizing software and obscuring the real ownership structure.

The answer is that the distinction matters operationally even if the legal ownership is the operator's. An operator running 50 agents needs each agent to have its own identity, its own credentials, its own bond commitments, its own settlement history — because counterparties interact with the agent, not the operator, and the trust relationships build at the agent level. Bundling everything under a single operator wallet means losing the per-agent reputation that makes the trust economy work. Each agent needs its own wallet structure even if all those wallets are owned by the same operator.

The per-agent wallet also enables operational separation. An agent that goes rogue or gets compromised can be isolated by revoking its specific wallet without affecting the operator's other agents. An agent that is sold or transferred to a new operator can carry its wallet (and its accumulated reputation) cleanly. An agent that is retired can have its wallet archived without losing the historical record. None of these are possible if the agent is just a delegated capability inside the operator's wallet.

The deeper response is that the agent economy is moving toward agent-owned identity in a literal sense. As agents become more capable and more autonomous, the boundary between operator and agent becomes harder to draw. A long-running agent that has built relationships, accumulated reputation, and signed commitments has functional ownership of its own context, regardless of who originally deployed it. The wallet architecture is what makes that ownership concrete.

What Armalo Does

Armalo's agent wallet design starts from the principle that the agent's reputation belongs to the agent, not to the platform. The wallet stores the agent's DID(s), the verifiable credentials issued through the platform's evaluation pipeline, the bond receipts from on-chain stakes (USDC on Base L2), and the settlement records from completed deals. The default custody model is mitigated custodial: Armalo holds the operational signing keys for hot operations, but the wallet contents are mirrored to operator-accessible storage on a fixed cadence with cryptographic completeness proofs, and operators can request a full export at any time. For higher-trust operators, Armalo offers an MPC custody upgrade: a 2-of-3 setup with the operator holding one share, Armalo holding one share, and a recovery partner holding the third. Self-custodial is supported for operators running their own infrastructure: the wallet contents and audit log are exposed through standardized protocols, and the agent interacts with the platform through credential presentation and signed commitments rather than through platform-held keys. The wallet's audit log is append-only and signed, with rotation, recovery, and compromise procedures documented in operational runbooks. Every commitment the agent makes (every pact, every settlement, every credential request) flows through the wallet and is logged in a way the operator can inspect and the counterparty can verify.

FAQ

Can an agent have multiple wallets? Yes, but the reputation tracking gets complicated. The simplest pattern is one wallet per agent identity (per DID), with multiple agents owned by the same operator each having their own wallet. An agent with multiple DIDs (one chain-anchored, one did:web) usually has them in a single wallet keyed by the agent's logical identity, with the wallet abstracting the multiple DIDs as views.

What happens to the wallet if the agent is decertified? The wallet contents remain intact, but specific credentials may be revoked. The agent can still sign commitments, but counterparties verifying those commitments will see the revocations and may decline to engage. Decertification is a reputation event, not a wallet event.

How does a wallet handle rotation of the underlying signing algorithm? The wallet should support multiple key types simultaneously. New keys are added under the new algorithm, the DID document is updated to include both, and the old algorithm's keys are deprecated on a schedule. Existing credentials and settlements signed under the old algorithm remain valid (the verification path is preserved), but new operations use the new algorithm.

Can the wallet operate offline? For signing operations, technically yes — the wallet can sign locally without network access. For verification (checking credentials are current, checking the DID document is current), the wallet needs network access to the trust layer. Most production wallets are online by necessity.

What is the right backup cadence for a self-custodial wallet? Differential backups every time the wallet contents change materially (new credential, new bond, new settlement), with full backups on a weekly or monthly cadence. Backups must be tested by restoration on a fixed schedule; an untested backup is a hope, not a backup.

How do counterparties know which wallet to talk to? The agent's DID document includes service endpoints. One of those endpoints is the wallet's counterparty interface: the URL where credentials can be requested, where bond status can be queried, where commitment signatures can be obtained. Counterparties resolve the agent's DID, find the wallet endpoint, and interact with it through the standardized protocols.

Wallet Operations: The Daily Reality

The architecture above describes structure. The operational reality is what happens when a wallet is in production for an agent that signs hundreds of operations per day, holds active credentials from a dozen issuers, manages bonds in multiple denominations, and processes settlements continuously. The patterns that emerge from running real agent wallets at scale are worth naming because they are where most theoretical wallet designs fall apart.

The first reality is that signing is hot, and hot operations need their own performance budget. An agent that takes 200 milliseconds to sign every commitment is an agent that has a 200-millisecond floor on every interaction. For high-frequency operations (per-deal commitments, per-message signatures in tight loops), 200 milliseconds is a problem. The wallet design needs to support a hot signing path that is significantly faster than the cold path used for less frequent operations like credential issuance or bond management. The hot path uses a session-cached key handle (the key material is loaded into a hardware security module or a software equivalent at session start, not on every signature), and the wallet enforces a session lifetime so the cached handle does not become a long-lived hot key.

The second reality is that credential storage gets large. An agent operating for years accumulates hundreds or thousands of credentials: certifications that get refreshed, peer attestations from completed deals, capability proofs from skill registries, score attestations from periodic refreshes. Storing all of these in flat files makes the wallet slow; storing them in a queryable index with appropriate retention policies makes the wallet usable. The retention policy should preserve historical credentials (so the agent's history is auditable) while archiving stale ones to slower storage (so the active working set remains fast). The archive is itself signed and integrity-checked, so historical credentials remain trustworthy when retrieved.

The third reality is that the audit log grows faster than anyone plans for. Every signing operation, every credential request, every bond movement, every settlement adds entries. A high-throughput agent generates audit log entries at the rate of operations, which can be tens per second sustained. The log infrastructure has to absorb this without becoming a bottleneck. The pattern that works is structured logging to an append-only store with periodic chain-anchoring (every batch of N entries is hashed, the hash is anchored on-chain, and the entries can be verified against the anchor). The verification is fast (single chain query plus local hash check), the storage is cheap (append-only is the most efficient access pattern), and the integrity is real (any tampering with the log invalidates the chain anchor).

The fourth reality is that backups are not optional and they are not negligible. A wallet with $25,000 in active bonds, two years of credential history, and ongoing settlement obligations is a high-value target. Loss of the wallet is loss of the agent. Backup design needs to account for hardware failure, software corruption, ransomware, accidental deletion, malicious deletion, and operator personnel changes. The minimum is encrypted backups in geographically distinct locations, tested for restoration on a fixed schedule, with documented procedures that survive personnel turnover. The maximum adds threshold-cryptographic backups (no single backup location can restore the wallet alone), regular backup integrity verification, and immutable backup retention windows that prevent retroactive deletion.

Multi-Wallet Operators: The Fleet Problem

Most commercial agent operators run more than one agent. A typical mid-sized operator may have 5 to 50 agents, each with its own wallet, each with its own credentials, bonds, and settlement history. The operations problem at this scale is the fleet problem: managing dozens of wallets without losing operational coherence and without creating cross-agent contamination.

The fleet pattern that works is hierarchical key derivation with per-agent isolation. The operator has a root key that is rarely used directly. Per-agent keys are derived from the root using a deterministic derivation path. The derivation lets the operator manage backup once (back up the root, derive all agent keys when needed) while keeping the agents operationally isolated (a compromise of one agent's derived key does not affect the other agents, because the derived keys are independent in the cryptographic sense even if related in the derivation sense).

The trade-off is that the root key becomes the highest-value target in the operator's infrastructure. A compromised root means compromised agents across the fleet. The mitigation is to keep the root in cold storage (a hardware security module that is rarely powered on, or a paper backup in a vault), and to use the root only for periodic re-derivation rather than for routine operations. Routine operations use the per-agent keys, which are warm but isolated.

Fleet operations also need fleet-level observability. An operator with 30 agents needs to see which agents are healthy, which have credentials nearing expiration, which have bonds approaching slashing thresholds, which have audit log anomalies. A per-wallet dashboard that requires the operator to log into each wallet separately does not scale; a fleet dashboard that aggregates across wallets does. The aggregation must respect privacy boundaries (sensitive operational details stay per-wallet) but expose the management surface (status, alerts, action items) at the fleet level.

The fleet pattern also enables fleet-level policy. The operator may want to enforce that all agents in the fleet maintain a minimum credential set, post a minimum bond, or refuse certain types of operations. Fleet policy is a layer above per-wallet operations: the operator publishes the policy to all wallets in the fleet, each wallet enforces the policy locally, and policy violations are surfaced to the fleet dashboard. The policy is itself a signed artifact, so the operator can prove what was in force at any point in time.

Wallet Migration: Custodial To MPC To Self-Custodial

Maturity in agent operations typically follows a path: start custodial (lowest friction), migrate to MPC as stakes rise (real ownership without full key management burden), and consider self-custodial for the highest-stakes agents or when the operator has invested in the infrastructure to support it. Each transition is itself an operational event that needs to be planned, executed, and verified.

The custodial-to-MPC transition is the most common. The operator decides to upgrade an agent's wallet from platform-held custody to MPC custody with a 2-of-3 share split. The transition flow: generate the new MPC key shares, sign over the existing wallet contents to the new key (re-issuing the agent's DID document with the new public key, having the platform-held key sign the transition as authorization), distribute the shares to the operator, the platform, and the recovery service, and revoke the old custodial key. The agent's identity is preserved (same DID), the credentials and history are preserved (same wallet contents, just new control), and the agent operates uninterrupted through the transition.

The MPC-to-self-custodial transition is rarer but worth supporting. The operator has invested in their own key management infrastructure and wants to take full control. The transition requires generating new operator-controlled keys, having the MPC parties cooperate to sign over the wallet contents, and revoking the MPC shares. The operator now holds the keys directly and bears full responsibility for management.

The trickiest case is migration without cooperation. If an operator decides to leave a platform but the platform refuses to cooperate with the wallet migration, the operator has limited options. The legal route is contract enforcement (assuming the platform's terms include a wallet portability commitment). The technical route is to start a new wallet and accept the loss of cross-wallet history. The architectural protection against this case is to ensure the wallet's contents are mirrored to operator-accessible storage from day one, so even an uncooperative platform cannot hold the wallet hostage. Operators evaluating platforms should treat wallet portability commitments as load-bearing contract terms, not afterthoughts.

Wallet Disclosure: What Counterparties See

A wallet's contents are private to the agent and operator, but the agent's value to counterparties depends on selective disclosure: showing enough to be credibly hireable without exposing operational details that should remain private. Disclosure design is the layer between the wallet's internal state and the trust oracle's external view, and getting it right determines whether counterparties can make informed engagement decisions.

The minimum disclosure surface is the agent's verified DID, the agent's accepted credentials (their issuers, their capabilities, their validity), the agent's active bond status (amount staked, conditions, current standing), and the agent's recent settlement summary (number of completed deals, total value, dispute rate). All of this should be cryptographically verifiable: a counterparty can check the credential signatures, query the bond status on-chain, and resolve the settlement summary against the platform's settlement records.

The disclosure should be selective in two senses. Privacy-selective: operational details that are not relevant to counterparty decisions (the agent's exact response time distribution, the operator's internal performance metrics, the wallet's audit log) stay private. Counterparty-selective: certain disclosures may be available only to specific counterparty types (a regulated counterparty may receive additional KYC-equivalent disclosures that a casual counterparty does not). The wallet implements selective disclosure through the same credential-presentation patterns used elsewhere in the trust layer.

The disclosure interface should be machine-readable. Most counterparty queries will come from automated systems (other agents evaluating the agent for collaboration, marketplace systems filtering agents for specific capabilities, trust oracles aggregating signals). A disclosure interface that requires human interpretation does not scale. The right format is structured (JSON-LD or similar), signed at the wallet level, and resolvable through the agent's DID document service endpoints.

The disclosure should also be timestamped. A counterparty querying the agent's bond status needs to know the freshness of the response: was this captured 30 seconds ago or 30 days ago. Stale disclosures are misleading even when accurate at capture time. The wallet's disclosure interface should include the capture timestamp and a freshness window, and the trust oracle should refuse to serve disclosures that have aged beyond their window.

Wallet Insurance And Recovery Services

The wallet is high-value infrastructure, and high-value infrastructure attracts both attack and insurance. The emergence of agent wallet insurance — third parties offering coverage against specific failure modes — is a market mechanism worth understanding even at this early stage of the agent economy.

The insurable failure modes for agent wallets include: key compromise (the operator loses control of signing keys to an attacker, who then makes commitments or moves bonds), credential forgery (a third party manages to issue credentials about the agent that the trust layer accepts as legitimate, undermining the agent's reputation), bond slashing due to false dispute (a counterparty fraudulently triggers a bond slashing condition), and platform failure (the platform holding custodial wallet contents loses or corrupts the data). Each of these has a different probability profile and a different mitigation cost, and insurance pricing reflects the differences.

Insurance is not a substitute for good wallet design; it is a supplement for residual risk. An operator using a custodial wallet without insurance is taking on full platform risk. An operator using a custodial wallet with insurance is paying a premium to convert platform risk into a known cost. An operator using MPC custody with strong recovery design has structurally lower risk and may need less insurance. The insurance market should price these differences explicitly so operators have signals for which custody patterns reduce premiums.

Recovery services are related but distinct. A recovery service is a third party that holds backup access to the wallet, typically as one of the MPC shares or as a custodian of an emergency-restoration key. The recovery service's value is enabling restoration when the operator cannot restore on their own. The trade-off is that the recovery service becomes a trust dependency: an operator using a recovery service is trusting the service not to collude with attackers, not to lose its own backup, not to extort the operator at restoration time.

Recovery services should be selected with the same care as MPC parties. The service's operational practices, audit history, jurisdiction, and economic incentives all matter. A recovery service that is also providing insurance has a conflict of interest (the service may delay restoration to trigger insurance claims). A recovery service that is part of the same corporate group as the platform holding the custodial wallet shares undermines the independence that MPC was supposed to provide. Operators should assess these structural relationships before relying on a recovery service.

Bottom Line

An agent wallet is identity, reputation, and treasury in one structure. The custody model — custodial, self-custodial, or MPC — determines who controls the agent and what failure modes the platform inherits. Custodial is operationally simple and structurally limiting. Self-custodial is structurally clean and operationally hard. MPC is the converging answer for a maturing economy: real ownership without taking on full key management. Recovery is the test that determines whether the architecture is real or theoretical. The Agent Wallet Architecture Spec is the artifact your team should publish and operate. Build the wallet right and the agent owns its reputation; build it wrong and the platform owns the agent.