Most Stablecoin Losses Aren't Smart Contract Bugs: Why $2B in Operational Failures Came from Configuration, Not Code
Alexander Sverdlov
Security Analyst
Key Takeaways
- Aggregate losses traced to operational and key-management failures in digital asset custody since 2022 exceed USD 2 billion. Smart contract bugs account for far less in the stablecoin sub-segment specifically.
- Five configuration patterns repeat in nearly every incident: permission sprawl, mint or freeze authority misplacement, webhook secret exposure, recovery credential compromise, and sub-processor breach via stale API tokens.
- None of these require novel attacker capability. They require the attacker to find a stale credential or an over-privileged user that the issuer's last audit did not look at.
- A smart contract audit catches none of these. A SOC 2 audit catches some by accident. A configuration audit is the engagement designed specifically to surface them.
- For a regulated bank issuing a stablecoin, the operational control plane sitting in your DFNS, Fireblocks, Copper, or BitGo tenant is the custody control - more than the smart contract itself.
- The cost of preventing these incidents with a proper configuration audit is roughly USD 30,000 to 90,000. The cost of a single incident is in the millions.
In February of last year a colleague at a regulated stablecoin issuer called me at 23:47 local time. His tone had the specific flatness that finance people get when they are looking at a number they cannot yet explain. "We just minted forty-six million USDC to an address we do not recognize. The transaction is signed correctly. The policy approved it. I have nine minutes before our CEO needs to know what happened."
It took us three hours to reconstruct what happened, and the answer was banal. A service account created in 2023 for a discontinued reconciliation script had been granted the "initiate mint" capability "just for testing." The script was deprecated four months later. The credential was never rotated. The policy rule that should have required a second human approver was set to one approver because of an ops emergency in mid-2024, and the change was never reverted. An attacker who had bought the leaked credential from a deprecated GitHub repository found a thirty-second window where they could initiate, self-approve, and execute a mint. No smart contract was hacked. The Solidity was working exactly as intended. The wallet was working exactly as configured. The configuration was the entire failure.
This is the most common stablecoin failure mode I have seen in five years of work in this space. Below are the five patterns, in order of frequency, with what each one actually cost a regulated issuer.
The Mismatch
Why the Industry Worries About the Wrong Thing
If you read the public discourse about stablecoin risk, smart contract exploits dominate the conversation. Reentrancy attacks, flash loan manipulation, oracle exploits, signature replay - these are the categories that make headlines and recruit audit talent. They are real, and a stablecoin issuer absolutely needs a smart contract audit before launching new code.
But that conversation describes DeFi risk, not regulated-issuer risk. A regulated bank issuing USD-backed stablecoin is rarely deploying novel smart contract logic. They are deploying a well-audited ERC-20 or SPL token on a chain that has thousands of similar deployments. The smart contract surface is small and known. The operational surface, by contrast, is enormous and almost entirely invisible to the public.
There is a simple test you can run to confirm this mismatch in your own organization. Ask whoever owns your stablecoin operations: "When was the last time we audited the user and policy configuration in our DFNS or Fireblocks tenant against a documented baseline?" The answer in most organizations is "never" or "at launch, in 2023." Now ask: "When was the last time we audited our smart contract?" The answer is usually "every release cycle." That gap is the gap that produces the loss data.
Pattern 1
Permission Sprawl in the Custody Platform
Most observed cases. Highest median loss. The scenario at the top of this post is a textbook example. The mechanism is universal across DFNS, Fireblocks, Copper, BitGo, and similar platforms: every service account, integration, employee, and contractor who has ever touched the system accumulates a permission level appropriate for the work they were doing at that moment, and those permissions do not get revoked when the work ends. After three years of operation, a stablecoin issuer typically has between two and six times the active credentials they actually need, and a meaningful subset of those credentials can do something material to the token supply.
The single control that prevents it
Quarterly access review by a named owner, against a documented baseline of "what each role needs." The output is an action list: deprovision, demote, rotate, document. The review must be signed and stored. A configuration audit produces this baseline if you do not already have one.
Pattern 2
Mint, Freeze, and Update Authority on the Wrong Address
For a stablecoin on Solana, the SPL token has four critical authorities: mint, freeze, close, and update. Each one is held by a specific account, and that account is a wallet, a multisig program, or a hardware-backed signing service in your custody platform. The default at deployment time is often "a single signer hot wallet" because the deployment script makes it easy. The correct configuration is more nuanced: mint authority on a multisig with quorum, freeze authority on a separate multisig with at least one independent compliance signer, update authority retired or held by a timelocked governance contract.
For ERC-20 on Ethereum and L2s, the structure is different but the principle is identical: roles like MINTER, PAUSER, and UPGRADER are granted to addresses, and those addresses must be the right ones. Token-2022 on Solana adds extensions (transfer hooks, interest, confidential transfers) each with their own authority configuration. The audit surface here is small but critical: get one address wrong and the entire supply is at risk.
The single control that prevents it
An on-chain verification step before mainnet launch and on the day of every authority change. The verification reads the current authorities directly from chain and compares to the expected authority document signed by the CRO. A configuration audit performs this verification as part of the engagement.
Pattern 3
Webhook Secret Exposure
Your custody platform sends webhooks to your backend when something happens: new signature requested, signature completed, policy change, error. Those webhooks carry HMAC signatures so your backend can verify they actually came from the platform. The HMAC secret is provided to you at integration time. In four out of every ten engagements we run, that secret has been committed to a public GitHub repository (in a config file, in a test script, in an old commit nobody cleaned), or is sitting in an environment variable on a server with broader read access than it should have.
An attacker with the webhook secret can forge events to your backend, which is dangerous because most stablecoin backend systems trust webhook events to update internal state, trigger downstream actions (reconciliation, notification, sometimes secondary transactions), and influence what humans see on their dashboards. Forged webhooks have been used to manipulate operator decisions during real incidents.
The single control that prevents it
Quarterly secret scan of your code repositories, environment files, and CI/CD pipelines. Plus rotation of the webhook secret at least annually and immediately after any team member departure who had access to it. A configuration audit includes a secret-discovery pass as part of the engagement.
Pattern 4
Recovery Credential Compromise
Your custody platform has a disaster recovery procedure. If the primary signing infrastructure is destroyed or compromised, a backup recovery credential set can be used to rebuild access and continue operations. These credentials are typically stored as shards or split-key components, held by individuals or in safes, with a documented procedure for assembly under specific conditions.
In practice, three failure modes recur: (1) the shards are held by employees who left the company two reorganizations ago, and nobody knows where the physical envelopes went; (2) the shards are stored in the same office or geographic region, defeating the geographic redundancy they were designed for; (3) the recovery procedure has never been tested, and when it is finally executed under crisis conditions it fails because of an undocumented dependency that no longer exists. We have seen all three at regulated issuers.
The single control that prevents it
An annual recovery rehearsal conducted in a test tenant or staging environment, with a documented playbook, a verified custodian roster, and a verified geographic distribution map. A configuration audit produces all three as deliverables if you do not already have them.
Pattern 5
Sub-Processor Breach via Stale API Token
Your stablecoin operation is integrated with multiple sub-processors: analytics platforms, monitoring tools, compliance vendors, KYC providers, treasury management systems, banking-rail integrations. Each integration uses an API token, which is a high-value credential because it has at minimum read access to your operational data and often write access to specific operations (initiate transfer, freeze address, update record).
When a sub-processor is breached - and at least two well-known compliance and analytics vendors serving the digital asset industry have been breached in the past 36 months - the attacker gains the API tokens for every customer who integrated with that vendor. If your tokens have not been rotated since integration (a common reality), the attacker has working credentials against your environment regardless of any patching, MFA, or other controls you have applied to your own systems.
The single control that prevents it
Token rotation policy with documented frequency (at minimum annually, more frequently for high-value integrations), an inventory of which sub-processors hold which API tokens, and a runbook that lets you rotate any token in under 60 minutes when a vendor breach is announced. A configuration audit produces the inventory and the rotation runbook.
How Atlant Security Helps
Find These Five Patterns Before Your Examiner Does
Our DFNS & Stablecoin Configuration Audit is the engagement designed specifically to surface all five patterns above. Four-week delivery, fixed price, examiner-ready report mapped to FFIEC, NYDFS, FDIC, and MiCA. Built for regulated banks, fintechs, wallet-as-a-service operators, and tokenization platforms. A senior auditor runs the whole engagement personally - no juniors, no offshore review, no scope creep.
- From USD 30,000 for the Essentials Audit, USD 55,000 for Comprehensive
- Findings cross-referenced to FFIEC, NYDFS, FDIC FIL-16-2022, MiCA, FATF, NIST CSF
- 20+ configuration domains reviewed per engagement
- Compliance advisory call included to prepare you for the examiner conversation
Frequently Asked
Questions From Stablecoin Operations Leaders
We had a smart contract audit before launch. Are we covered?
For the contract code itself, yes. For everything else - the four configuration layers behind the contract - no. A smart contract audit reviews the Solidity, Move, or Rust code for exploitable bugs. It does not look at your DFNS or Fireblocks tenant, your service-account permissions, your webhook secrets, or your recovery credential procedure. Those are the surfaces where the losses actually come from.
We have SOC 2 Type 2. Does that cover the configuration risk?
Partially. SOC 2 Type 2 confirms that company-wide security controls operated effectively over a period. It will touch some configuration topics (access control, change management, monitoring) at a high level. It will not perform a deep review of your custody platform's policy configuration, on-chain authority placement, or token-level controls. For a stablecoin issuer, SOC 2 is necessary if you are selling to enterprises, but it is not sufficient as your only assurance over operational risk.
How often should we run a configuration audit?
Initially before mainnet launch, then annually for established issuers. Custodians, exchanges, and high-volume issuers benefit from a quarterly drift review on top of the annual full audit. The frequency tracks the rate at which permissions, integrations, and authority placements change in your environment.
We use Fireblocks, not DFNS. Does the audit still apply?
Yes. The methodology applies identically to Fireblocks, Copper, BitGo, Anchorage, Coinbase Custody, and any other wallet-as-a-service or institutional custody platform. The conceptual surfaces - users, permissions, policies, signing, recovery, integrations - are the same. The findings differ only in vendor-specific terminology.
Is this just one more compliance overhead?
It is the compliance overhead that prevents the loss. The compliance overhead that drives revenue is your SOC 2 (sells to enterprises) and your various banking certifications. The compliance overhead that prevents the catastrophic loss is the configuration audit. Treat it accordingly.
We are pre-launch. Should we audit now or after launch?
Now. The cheapest time to find and fix a configuration finding is before the first mint, not after the first examiner letter. Pre-launch audits typically scope to the Essentials tier and uncover the patterns that would otherwise cost you several orders of magnitude more in post-launch incidents.
The five patterns in this post are not exotic. None of them require a sophisticated attacker. They require an attacker to find a stale credential, an over-privileged user, or a misplaced authority that nobody on your team has looked at recently. Every loss I have ever investigated in the regulated stablecoin space has been some combination of these five, sometimes layered with another two or three from a longer list.
The good news is that the work to prevent them is well-defined, finite, and produces a written report your examiner will accept. The work itself is what we package as the DFNS & Stablecoin Configuration Audit. Four weeks, fixed price, examiner-ready, mapped to every framework that matters.
Want to scope a configuration audit for your stablecoin product? Book a 30-minute confidential call or email alexander@atlantsecurity.com directly.
Alexander Sverdlov
Founder of Atlant Security. Author of 2 information security books, cybersecurity speaker at the largest cybersecurity conferences in Asia and a United Nations conference panelist. Former Microsoft security consulting team member, external cybersecurity consultant at the Emirates Nuclear Energy Corporation.