Wallet Infrastructure: What Happens When Your Custody Approach Is Wrong

Key Takeaways

• Wallet and signing-infrastructure compromises, not smart contract bugs, are now the leading cause of dollar losses in crypto. Independent trackers show wallet compromises overtook smart contract exploits industry-wide by mid-2026.
• Custody failures rarely start with a stolen key. They start with a single point of trust: one interface, one signer, one pre-signed approval, or one verifier whose compromise is enough to move funds.
• Most failures happen during routine operations and trace back to four repeatable errors: blind signing through a compromised interface, concentrated signing authority, approvals that are never re-validated, and third-party dependencies with no independent verification.
• Certain structural gaps (no tiering, no role-based access, no segregation of duties) reliably predict that a custody setup will fail under pressure, even before an attack happens.
• A resilient custody standard combines tiered wallet architecture, MPC threshold signing, role-based access, and policy rules that check every transaction independently of what a signer sees, rather than adding more approvals to the same fragile process.

Custody failures rarely announce themselves in advance. They surface mid-transfer, mid-approval, on what looked like an ordinary operating day, and by the time anyone notices, the funds are already gone. If your platform hasn’t formally reviewed its custody architecture in the last year, there’s a reasonable chance it has one of the failure patterns below already built in.

How Custody Goes Wrong: The Circumstances and Errors Behind Most Losses

Custody rarely fails because cryptography breaks. It fails during routine operations, when a process that has worked hundreds of times is quietly turned against the operator. 

Four circumstances account for most of the damage, and each traces back to a specific, repeatable error.

1. During a Routine Transfer, When Signers Trust the Screen

When it happens: Scheduled movements between cold and warm wallets, treasury rebalancing, or any transfer the signers have approved many times before.

What goes wrong: In one widely documented pattern from the past two years, an operator’s routine transfer between a cold wallet and a warm wallet was intercepted. The signers approved what their screen showed them. What actually executed was different. The multisig threshold was met and every signature was legitimate, but the interface the signers trusted to represent the transaction had already been altered. Billions of dollars in single incidents have followed this exact shape: not a cryptographic break, but a presentation-layer compromise that turned an approved process into an attacker-controlled one.

The underlying error: Treating signer approval as transaction verification. Signers approved a representation of the transaction rather than the transaction itself, and nothing independent checked the actual payload against policy before it executed.

2. As Operations Scale, When Authority Concentrates by Convenience

When it happens: Early growth stages, support escalations, staff turnover, and emergency fixes that quietly become permanent.

What goes wrong: Signing authority concentrates in one individual, one device, or one automated process, without anyone deciding that on purpose. A founder holds the recovery phrase because it’s convenient, an ops engineer keeps standing access to a hot wallet for support tickets, or a single API key can move funds without a second approval. When that one point fails, whether through loss, compromise, or departure, there’s no structural backstop.

The underlying error: Granting standing, single-holder authority and never revisiting it. No policy limits what one role can do alone, so convenience becomes the security model.

3. Over Weeks or Months, When Signers Are Socially Engineered

When it happens: Long-running campaigns where attackers pose as partners, investors, or counterparties and build trust with the people who hold signing authority.

What goes wrong: Signers are persuaded to approve or pre-sign transactions that look harmless in isolation. Those approvals sit unused until the attacker is ready, then execute in a context the signers never anticipated, such as a transfer of admin control.

The underlying error: Allowing approvals to be collected in advance and executed later without re-validation. An approval that never expires and is never re-checked at execution time is effectively a blank cheque.

4. When a Trusted Dependency Is Compromised, Not the Platform Itself

When it happens: Any setup that relies on an outside wallet interface, custody provider, bridge verifier, or data feed to function correctly.

What goes wrong: Several major losses have come from operators who outsourced custody, signing, or verification infrastructure to a third party and had no independent way to confirm what that third party’s systems were actually doing. The platform’s own security posture was sound. The dependency wasn’t.

The underlying error: Trusting a single external system without a second, independent check. When one dependency is the only source of truth, its compromise becomes the platform’s compromise.

What the Pattern Points To

Blockchain analytics firms tracking these incidents consistently describe the same shift. Signing and infrastructure compromises accounted for the large majority of losses in early 2025, despite representing a small share of total incidents by count, and by mid-2026, wallet compromises had overtaken smart contract exploits as the largest single source of Web3 financial losses.

That’s a meaningful shift for anyone building custody infrastructure today, because it means the risk isn’t primarily in your code. It’s in your architecture.

Read together, these incidents describe one problem in four forms. In every case, a single point of trust stood between the attacker and the funds: one interface signers relied on, one person or key that held authority, one approval obtained in advance, or one verifier no one checked. The attacker never needed to break the keys. They only needed to compromise whatever the keys depended on.

Most attacks now share three traits:

• They target people and process, not cryptography. Signers, admins, and engineers are the entry point, which is why AI-assisted social engineering has become so effective.
• They exploit approval, not access. Funds move through legitimate signatures, so controls that only confirm a transaction was signed have nothing to flag.
• They only need to succeed once. When one compromise is enough to move funds, the size of the loss is set by how much sits behind that single point.

The actual issue is not whether an operator uses multisig, MPC, or an outside custodian. It is whether the architecture allows any single failure to become a complete one. A custody model built on MPC threshold signing removes the complete private key entirely, so there is no single key, device, or person for an attacker to target. Policy rules enforced at the infrastructure layer, such as address whitelists, transaction limits, and multi-party approval quorums, decide what can execute based on the actual transaction, not on what a signer’s screen shows. A transfer to an unrecognized address is held or rejected by policy even when every required signer has approved it.

An institutional wallet system is what brings those layers together. Tiered hot, warm, and cold wallets cap how much any single compromise can reach. Role-based permissions and segregation of duties keep initiation and approval in separate hands. MPC threshold signing distributes authority so no one party can act alone. A policy engine validates every transaction against predefined rules, while real-time monitoring and audit trails surface anomalies while there is still time to stop them. Each layer covers a gap the others leave open. Together, they turn custody from a chain of single points of trust into a system where an attacker has to defeat several independent controls at once.

Why Platform Operators Are Reassessing Custody Now

Four things are pushing custody architecture back onto the roadmap for operators who thought it was already settled.

• The threat surface has moved. Attackers increasingly target signing environments, operational workflows, and third-party dependencies instead of smart contract logic. A custody setup that was reasonable when the main risk was contract exploits may not hold up against operator-level attacks.
• AI has made social engineering faster and more aggressive. Attackers now use AI to profile targets, build believable personas, clone voices and faces for live calls, and write phishing tailored to each signer. Reconnaissance that once took weeks now takes days, and attacks arrive with more volume, more pressure, and more credibility. Any setup where one persuaded signer can approve a transaction is directly exposed.
• The stakes per incident have gone up. A small number of incidents now account for the majority of total losses industry-wide. Concentration risk in custody architecture translates directly into concentration risk in loss size.
• Institutional counterparties and regulators expect proof, not assurances. As platforms scale and take on institutional volume, “we have a multisig” is no longer a sufficient answer to a custody due-diligence question. Auditability, segregation of duties, and documented access controls are increasingly table stakes.

6 Signs Your Custody Approach Is Already Wrong

Most operators don’t find out their custody architecture is fragile until something forces the question. These are the structural gaps that tend to be present beforehand:

• No tiering between hot, warm, and cold wallets. If funds needed for daily operations sit in the same operational tier as long-term reserves, a single compromise has access to everything.
• No role-based access control. If any single signer, engineer, or admin account can independently approve, initiate, or reverse a transaction, there’s no structural separation between a mistake and a catastrophe.
• Signing decisions depend on a single, unverified interface. If the only thing standing between a signer and an altered transaction is trusting that the screen in front of them is accurate, that trust is the entire security model.
• No segregation of duties. If the same person or team can both initiate a transaction and approve it, the control exists on paper only.
• No audit trail for who approved what, when. If a compliance or security review would require reconstructing events from memory rather than logs, the setup isn’t auditable, and it isn’t defensible under scrutiny.
• Custody is outsourced with no independent verification. If a third party handles signing or key custody and there’s no way to confirm what their systems are doing beyond their own assurances, that dependency is an unmonitored single point of failure.

If two or more of these are true for your platform, the honest starting assumption should be that your custody architecture has an unaddressed failure mode, whether or not it has been exploited yet. The incidents below show what that failure mode looks like once it is found.

What Happens When Custody Architecture and Policy Rules Aren’t Sorted Out

Sorting out custody means settling three layers of the custody structure, not just choosing a wallet type:

• The architecture: how funds are tiered across hot, warm, and cold wallets, and how signing authority is distributed so no single key, device, or person can move funds alone.
• The policy rules: who can initiate, approve, and change what, under which limits, quorums, whitelists, and time delays.
• The verification layer: how every transaction, approval, and third-party dependency is independently checked before funds move.

The biggest losses of the past 18 months didn’t come from broken code. Each one came from a single point of trust in one of these layers that an attacker found and used.

The pattern holds across all three. Once signers can be deceived, pre-signed approvals go unchecked, or one verifier is trusted without a backup, the attacker only has to win once. Fixing one layer while leaving the other two unresolved simply moves the single point of trust somewhere else.

How to Build a Resilient Custody Architecture

Resilient custody isn’t a single feature. It’s a standard applied consistently across the entire wallet architecture, where each control closes a specific failure mode from the incidents above. The seven steps below build that standard in order, from how funds are structured to how every action is recorded.

1. Segment Funds Into Hot, Warm, and Cold Tiers

The problem it solves: A single compromise reaching every asset on the platform.

Tiering limits the blast radius of any one failure. Funds are segmented based on how frequently they need to move, with progressively stronger controls at each tier.

• Hot wallets hold only what daily withdrawals and operations require, sized against actual withdrawal volume.
• Warm wallets act as a buffer for rebalancing, with movement into hot wallets automated within preset limits.
• Cold storage holds the majority of reserves, with no direct path to the internet and the highest approval quorum for any outbound movement.
• Movement between tiers happens only through defined, policy-controlled flows, never through ad hoc transfers.

2. Replace Single Keys With MPC Threshold Signing

The problem it solves: Concentrated authority in one key, device, or person.

With Multi-Party Computation (MPC), the private key is never created or stored as a whole. Key shares are distributed across parties, devices, or locations, and a defined threshold of them (for example, 2-of-3 or 3-of-5) jointly computes each signature.

• No single party, including the infrastructure provider, ever reconstructs the full private key.
• Losing one share through a stolen device, a departing employee, or a compromised server is not enough to move funds.
• Share refresh and rotation let operators replace compromised or outdated shares without changing wallet addresses, in implementations that support it.
• Signing happens off-chain, so there is no on-chain wallet contract for attackers to target, and the same model works across chains.

3. Assign Roles and Separate Duties

The problem it solves: One account or person holding end-to-end control.

Every action is tied to a specific role with defined permissions, and no role can complete a sensitive action alone.

• Define distinct roles such as initiator, approver, policy administrator, and auditor.
• Never let the initiator approve their own transaction, and require a different quorum for policy changes than for transfers.
• Replace standing access with time-bound access granted for a specific task and revoked automatically afterwards.
• Revoke permissions and key shares immediately when someone changes roles or leaves the organization.
• Keep client funds structurally separate from operational or custodian assets.

4. Enforce Policy Rules at the Infrastructure Layer

The problem it solves: Controls that depend on a human noticing something unusual in the moment.

A policy engine evaluates the actual transaction payload against predefined rules before it can execute. This is the control that holds even when signers are deceived, because it does not rely on what their screen shows.

• Address whitelisting and blacklisting restrict transfers to approved destinations and block known malicious addresses.
• Transaction and velocity limits cap value per transaction, per day, per asset, and per tier.
• Approval quorums scale with value, so larger or unusual transfers need more independent approvers.
• Time delays on large transfers and on policy changes create a window to catch and cancel unauthorized activity.
• Contract interaction rules block calls that would change wallet ownership or permissions unless explicitly authorized.

5. Verify Transactions Independently of the Signing Interface

The problem it solves: Blind signing and presentation-layer compromise.

Signers should never have to rely on a single screen to know what they are approving.

• Decode and display the raw transaction on a separate device or channel from the one that created it.
• Simulate transactions before signing to confirm the expected outcome, including any ownership or permission changes.
• Confirm high-value transfers out of band, through a separate, pre-agreed channel.
• Set expiry on approvals and re-validate any pre-signed transaction against current policy at the moment it executes.

6. Verify Every Third-Party Dependency

The problem it solves: Outsourced trust with no independent check.

Third parties in the signing or verification path should strengthen the architecture, not become its weakest point.

• Map every dependency that touches signing, custody, or verification, including wallet interfaces, bridges, and data feeds.
• Require more than one independent verifier wherever a single source would otherwise decide whether funds move.
• Prefer architectures where providers cannot sign alone, such as MPC setups where a provider holds at most one share below the signing threshold.
• Request evidence, not assurances: security audits, penetration test results, and the contractual right to review controls.

7. Monitor in Real Time and Log Every Action

The problem it solves: Losses discovered only after funds are gone, and reviews that depend on memory.

• Anomaly alerts flag activity that deviates from normal patterns, such as unusual destinations, amounts, or approval timing.
• Know-Your-Transaction (KYT) screening checks counterparties and fund flows for risk before and after transfers.
• Tamper-resistant audit trails record every approval, transfer, and policy change in a form that can be independently reviewed.
• Regular drills and disaster recovery testing confirm that controls and key recovery procedures work under pressure, not just on paper.

Remember This: Each Failure Mode Has a Matching Control

This is the standard ChainUp builds its wallet infrastructure around, and it’s the baseline any custody architecture should be measured against, regardless of vendor.

How ChainUp’s Wallet Infrastructure Applies This Standard

ChainUp’s White Label Non-Custodial MPC Wallet is built for platforms that hold digital assets, including exchanges, financial institutions, and payment providers. It applies the standard above across four layers:

• Threshold signing: Signing authority is split across multiple parties through MPC, so no single key, device, or person can move funds alone.
• Tiered storage: A minimal amount of assets stays in hot wallets for operational needs, while the majority moves to cold storage.
• Policy engine: Whitelisting, blacklisting, multi-party approvals, and segregation of duties govern how transactions are approved, with client funds kept separate from custodian assets.
• Monitoring and audit trails: Real-time monitoring sends instant alerts on suspicious activity, and the policy engine keeps clear audit trails for accountability.

With these layers in place, compromising one signer, one device, or one interface is not enough on its own to move funds, which addresses the gap behind the largest wallet-related losses industry-wide

ChainUp’s White Label Non-Custodial MPC Wallet applies that standard through threshold signing: key shares distributed across parties so that no single party, including ChainUp, ever reconstructs a complete key. Its policy engine adds whitelisting, multi-party approvals, and audit trails on top of that signing model. Compromising one signer, one device, or one interface stops being enough to move funds, which closes the exact gap that has driven the largest wallet-related losses industry-wide. The difference between the two models is covered in more depth in this guide to non-custodial vs. MPC wallets.

Between those two ends sits every platform still working out where its own architecture actually falls, and how much of that standard it currently has in place. Talk to the ChainUp team today for a demo.

Frequently Asked Questions

What is crypto custody risk, and why does it matter for platform operators?

Crypto custody risk refers to the probability and impact of unauthorized access to, or loss of, digital assets due to failures in key management, signing infrastructure, or operational processes. For platform operators, custody risk is existential. A breach can result in irreversible loss of user funds, regulatory action, and reputational damage.

What is wallet infrastructure failure, and what are the most common causes?

Wallet infrastructure failure occurs when the systems governing key management, transaction signing, or asset storage are compromised or malfunction. Common causes include over-reliance on a single signing interface, concentrated signing authority in one person or system, pre-signed approvals that are never re-validated, no segregation between hot and cold wallet logic, and outsourced custody arrangements with no independent verification.

How do I know if my current custody approach is already a risk?

Common warning signs include the absence of tiering between hot, warm, and cold wallets, no role-based access controls, no segregation between who initiates and who approves a transaction, and no auditable log of custody-related decisions. If more than one of these gaps exists, the architecture likely has an unaddressed failure mode.

What is the main difference between multisig and MPC wallet infrastructure?

Multisig wallets require multiple private keys to authorize a transaction, but each key exists as a complete, reconstructable entity, and signers typically rely on an external interface to know what they’re approving. MPC (Multi-Party Computation) wallets eliminate the complete private key entirely. Key shares are distributed across parties, and transactions are signed through threshold computation, so no single party ever holds or reconstructs the full key.

What wallet infrastructure does ChainUp provide for platform operators?

ChainUp’s White Label Web3 Wallet is a self-custodial dApp gateway where end users hold their own keys, suited to DEX and Web3-native platforms. ChainUp’s White Label Non-Custodial MPC Wallet is built for platforms that are the custodian of record for user funds, applying tiered architecture, role-based access, and MPC threshold signing so no single party, including ChainUp, ever holds a complete key.