The Custodial Stablecoin Rekt Test

Last year, custodial stablecoins reached $27.6 trillion in transaction volume, surpassing both Visa and Mastercard combined. As this new asset’s systemic importance grows, so does the need for a clear understanding of its security risks, for both issuers and users of stablecoins. For groups managing significant stablecoin holdings, a single operational security failure in their stablecoin’s issuer now represents a material financial risk.

Custodial stablecoins are digital tokens that are designed to maintain a stable value, typically by being pegged to a fiat currency like the US dollar. They are issued and managed by centralized entities that maintain the reserves backing them.

Unlike decentralized stablecoins and many other blockchain systems, the integrity of a custodial stablecoin hinges on the operational security of its issuer, including the people, processes, and infrastructure behind the stablecoin. Custodial stablecoins share much more in common with banks than DeFi or blockchain protocols.

However, unlike banks, stablecoin users have few protections in the event of a computer security breach or compromise that impacts the issuer’s liabilities or ability to pay them. For this reason, institutions and users planning on holding or transacting in these assets should perform rigorous due diligence on the issuer’s security practices or else face the existential risk that their holdings become worthless.

In the past, Trail of Bits introduced “the Rekt Test” as a simple framework for assessing the basic security posture of blockchain projects. Building on that philosophy, this post will introduce a Rekt Test for custodial stablecoin issuers, focusing on the specific risks issuers face and offering a set of due diligence questions to help evaluate an issuer’s operational resilience.

The Custodial Stablecoin Rekt Test

1. Do you use multiple independent controls to verify transaction contents before signing?
2. Do you continuously update your security practices based on emerging threats?
3. Do you work with the community to freeze and recover hacked funds?
4. Do you segregate your signing infrastructure?
5. Is your signing infrastructure immutable?
6. Do you limit each role’s permissions to the minimum required?
7. Do you verify the integrity of your critical software dependencies?
8. Do you have a written and tested incident response plan?
9. Do you use monitoring tools that can trigger an incident response if discrepancies are detected?

Although each question in the test can theoretically be answered with a simple “yes” or “no,” mature issuers should be able to provide specific, detailed explanations as to how they address the risks posed by each question.

While stablecoin users can use these questions to inform due diligence practices, stablecoin issuers can also use them as a self-assessment framework to identify critical gaps in their security program.

Alongside each question, we explain how it reflects our consensus of best practices for stablecoin issuers, but these recommendations are by no means exhaustive or absolute. The controls we recommend for addressing each question are meant to stimulate conversations to help stablecoin users and issuers better understand their security risk; they should not serve as a comprehensive checklist that every stablecoin issuer should follow.

Special thanks to Josselin Feist, @tayvano_, Matt Aereal (SEAL Security Alliance/The Red Guild), and Isaac Patka (Shield3) for reviewing and providing feedback on this test.

1. Do you use multiple independent controls to verify transaction contents before signing?

Single points of verification create catastrophic failure modes. Modern attackers can easily circumvent single-layer transaction verification mechanisms, as demonstrated in the Bybit and Radiant Capital hacks where compromised interfaces showed legitimate transactions while executing malicious ones. Even multiple signers become useless when they all rely on the same verification method.

The fundamental challenge is that true “What You See Is What You Sign” (WYSIWYS) remains impossible with current hardware wallet technology. These devices can display basic transaction parameters but cannot decode complex smart contract interactions, leaving signers partially blind to what they’re actually authorizing. Until someone rebuilds the entire wallet stack, we’re stuck in a world where sophisticated transactions appear as generic “Blind Signing” interactions on hardware wallet screens. This technological limitation makes multiple independent verification controls essential.

Mature stablecoin issuers must implement redundant security controls with genuine independence. This means separate verification systems using different technical stacks, running on different hardware, with no shared dependencies. Each system must decode and display transaction contents through its own lens such that if one is compromised, the others must still reveal the truth.

For manual signing processes, implement at least three dedicated-use workstations per signer: a primary workstation that initiates transactions and sends them to the hardware wallet, a network-isolated simulation environment that reveals actual execution outcomes, and an air-gapped verification system using independent, offline decoding tools like safe-tx-hashes-util. The critical discipline is comparing transaction hashes character-by-character across all systems before signing. Any discrepancy indicates compromise.

This approach deliberately trades operational speed for security. Yes, comparing hashes across three systems is tedious. Yes, maintaining truly independent verification infrastructure is complex. But when the alternative is explaining how attackers turned your multisig into a single point of failure, the choice becomes clear. In the Radiant Capital incident, all signers saw falsified transaction data because they used the same compromised interfaces. With independent verification, at least one system would have exposed the deception.

Until hardware wallets evolve beyond their current limitations, multiple independent verification layers remain our best defense against the interface manipulation attacks that have defined recent crypto security failures.

2. Do you continuously update your security practices based on emerging threats?

Cryptocurrency attackers evolve faster than your annual security review. While you’re implementing defenses against last year’s attacks, threat actors have already moved on to new techniques. The organizations that suffered the worst breaches in 2024 weren’t compromised through novel zero-days, but through evolved versions of known attack patterns they hadn’t updated their defenses against. Static security is decaying security.

Continuous security updates mean more than reading threat intelligence feeds. It requires a systematic process for translating emerging threats into concrete defensive improvements. This means maintaining active channels for threat information, rapidly assessing relevance to your infrastructure, and incorporating lessons learned into your security architecture before you become the lesson for others.

Establish a formal threat review cycle, monthly at minimum, where your security team analyzes recent incidents in the cryptocurrency space and asks, “Could this happen to us?” For each relevant threat, document specific controls you’ll implement or modify. This shouldn’t be framed as a simple one-and-done discussion; it’s a tabletop exercise whose outputs must inform your future security plans.

When North Korean operatives began infiltrating crypto companies through fake IT worker schemes in 2024, organizations that detected this pattern early implemented enhanced identity verification for remote hires. But the real lesson wasn’t about background checks. It was about recognizing that your hiring process could be an attack vector. Teams that internalized this broader lesson also hardened their insider threat controls, access provisioning, and behavioral monitoring.

Your security team should maintain relationships with threat intelligence providers who specialize in cryptocurrency and blockchain attacks. More importantly, participate in information sharing communities where practitioners discuss what actually worked against real attacks. The Kraken write-up on detecting fake DPRK workers provided more actionable intelligence than a dozen generic threat reports because it documented specific detection techniques and indicators that others could immediately implement.

Every significant cryptocurrency breach should trigger a mini threat modeling exercise. How would this attack path work against our infrastructure? What controls would detect it? What would we need to change? Document these analyses and track the implementation of identified improvements. The strongest security control isn’t any single technical measure, but the organizational muscle memory that translates “that happened to them” into “here’s what we changed to prevent it from happening to us.”

The DPRK IT worker threat will evolve or be replaced by something new by the time you read this. What matters is whether your organization has the processes to detect, analyze, and adapt to whatever comes next. In cryptocurrency security, the only constant is that last year’s playbook is this year’s vulnerability. Without a disciplined approach to threat adaptation, you’re not maintaining security; you’re maintaining the illusion of security while attackers iterate past your defenses.

3. Do you work with the community to freeze and recover hacked funds?

When hackers steal cryptocurrency, they race to exfiltrate and convert it into stablecoins before the theft is discovered. Due to their price stability and healthy liquidity, stablecoins often become a critical chokepoint in the laundering pipeline. However, within hours, those funds will flow through automated market makers, cross-chain bridges, and privacy coins into jurisdictions where recovery becomes impossible. This is the only moment victims have any hope of recovery. However, when stablecoin issuers demand court orders that take months to obtain, they guarantee that stolen funds disappear forever.

The recent Bybit hack demonstrates why speed and capability matter. Hackers deliberately moved funds through HyperLiquid precisely because some stablecoins there have no freezing mechanism, highlighting how criminals actively route funds through systems where recovery is impossible. In contrast, when issuers can act quickly, recovery rates improve dramatically. In the Multichain hack, stablecoin issuers successfully froze $66 million of the $126 million stolen, securing a potential recovery for nearly half the funds because they acted within hours, not weeks.

This isn’t about privacy versus compliance. It’s about whether your stablecoin enables theft at scale. Every major exchange, custody provider, and institutional user evaluates stablecoin issuers based on their track record of protecting victims. Will you, as an issuer, help when their funds are stolen, or will you hide behind bureaucracy while criminals cash out?

Mature issuers establish clear, public processes for freezing stolen funds based on credible evidence from security firms, exchanges, and custody providers. This means publishing response time commitments (measured in hours, not days), designating 24/7 contacts for critical incidents, and working with established blockchain security firms who can verify theft claims. Leading issuers have frozen thousands of wallets and recovered over $100 million in assets by maintaining these relationships.

The process must balance speed with accuracy. Issuers should require proof of theft, verification from recognized security firms, and clear documentation of the incident. But once theft is verified, action must be immediate. Issuers must also build an appeals process so users with erroneously frozen funds have a route to recovery.

4. Do you segregate your signing infrastructure?

Shared points of failure represent critical control points where a single compromise can bypass your entire security architecture. In the Bybit hack, attackers didn’t need to compromise all five multisig signers independently; they found shared dependencies that let them pivot from one compromise to control multiple signing workstations. When your security domains overlap, multisig becomes single-sig with extra steps.

Without proper segregation, a single breach in your corporate IT can sink the entire system. We’ve seen this pattern repeatedly: attackers compromise a single endpoint management system, IT administrator account, or software deployment pipeline, then leverage that access to control what should be independent signing systems.

True segregation requires isolating three critical areas where failures can cascade:

Access segregation: Who can touch what

This prevents a single compromised identity from accessing everything. In practice:

• Different systems for different levels of operations (mint, burn, upgrade)
• Each multisig signer operating from completely independent infrastructure—different ISPs, different hardware vendors, different operating systems
• Time-based controls that prevent any administrator from having 24/7 access to critical systems

Security segregation: What systems can talk to each other

This prevents a breach in one system from spreading to others. In practice:

• Dedicated networks for signing operations with no connectivity to corporate systems
• Dedicated hardware that only runs signing software—think of it like a calculator that can only do one thing
• Separate monitoring systems for each tier, so compromising your main SIEM doesn’t hide attacks on signing infrastructure

Supply chain segregation: What code runs where

This prevents compromised software from infecting your signing systems. In practice:

• Completely different build pipelines for your signing software and your website
• Vendor diversity where it matters (e.g., don’t buy all your hardware wallets from one vendor)
• Independent software stacks for verification—if all the multisig signers use the same verification tool, they will all fall to the same attack

If an attacker can compromise any single element (an admin account, a management server, a software package, a network segment, etc.) and use that compromise to authorize significant funds movements, then your system is not adequately segregated.

Proper segregation, while expensive and operationally complex, is valuable because it severely constrains the attacker’s ability to move laterally. This containment strategy is crucial for limiting the potential impact of sophisticated attacks that might bypass individual security controls.

5. Is your signing infrastructure immutable?

The servers and applications that implement the signing infrastructure represent critical control points. This infrastructure requires defensive controls that protect the security and integrity of its operation, even when other parts of the infrastructure are compromised. The best way to accomplish this is by making the infrastructure immutable.

Immutable infrastructure means that servers, applications, and configurations cannot be easily modified or tampered with after deployment; they can only be replaced entirely through a controlled deployment process with multiple approval points. This approach dramatically reduces the attack surface by eliminating the possibility of unauthorized modifications to critical systems.

Mature stablecoin issuers should implement immutability at multiple levels of their infrastructure:

Operating system immutability. Use read-only operating systems or container images that cannot be modified during operation. Controls like Binary Authorization can also be used to ensure that only authorized images are executable by your container orchestrator, if you use one.

Application immutability. Deploy applications as immutable artifacts that cannot be changed without going through a secure build pipeline. Binary Authorization, SGX, and Trusted Platform Modules (TPMs) can be used to ensure the artifacts running in production are authorized and have not been tampered with. Controls like WDAC and Airlock Digital can also help control application runtime behavior and allowlists.

Deployment controls. The signing infrastructure’s deployment pipeline has the greatest potential to mutate the production environment and should be adequately locked down to mitigate this risk. Deterministic builds can be used to ensure that a CI/CD server has not been tampered with, and approval workflows should be used to ensure that a single developer cannot mutate the production environment without multiple levels of human approvals.

The choice of which controls should apply to each part of the issuer’s stack can vary drastically depending on the issuer’s architecture. For example, if the signing infrastructure runs in an SGX enclave and is updatable only using a multisig scheme, then the value gained by applying controls to developer workstations is greatly reduced.

6. Do you limit each role’s permissions to the minimum required?

Excessive privileges create unnecessary risk. Consider this scenario: if your treasury management multisig can both mint new tokens AND upgrade smart contracts, a single compromised signer could inflate your supply by billions while simultaneously removing all security controls. But if that same multisig can only burn tokens (with a daily limit of, say, $10 million), the maximum damage is contained and recoverable.

Stablecoin issuers must segregate high-risk operations and limit who can perform them, following the principle of least privilege. This means creating distinct permission tiers that match real operational needs. Your daily operations team handling routine redemptions should only be able to burn tokens within strict limits, not mint new supply. Your treasury team managing institutional flows might have minting permissions, but only with 48-hour timelocks and rate limits. Critical operations like contract upgrades should require extraordinary measures: multi-day timelocks, supermajority multisigs, and even physical key ceremonies.

The business impact becomes clear when examining real incidents. In the October 2024 Radiant Capital hack, attackers exploited a 3-of-11 multisig configuration. This setup required only three signatures from eleven possible signers, which gave attackers multiple targets while keeping the approval threshold dangerously low. This weak permission structure enabled a $53 million theft. In contrast, protocols with well-designed thresholds and timelocks force attackers to compromise significantly more signers or give defenders time to respond before damage occurs.

For automated systems, implement granular controls:

• Minting services can only mint to whitelisted addresses with rate limits enforced by smart contracts.
• Redemption systems can only burn tokens, not mint them.
• Temporal access controls are imposed on system administration/devops.

Temporal/expiring access controls are often one of the most overlooked controls. An issuer’s CFO might need minting access for a specific corporate action, but why leave that access enabled permanently? Implement 24-hour access windows that require reauthorization, reducing the window for insider threats or compromised credentials. Regular permission audits ensure that access rights remain appropriate as your operation evolves.

These controls transform your attack surface from a single point of failure into a resilient system where compromises are contained, detected, and recoverable.

7. Do you verify the integrity of your critical software dependencies?

Any custodial stablecoin’s infrastructure relies on numerous third-party software components, libraries, and tools. Compromised dependencies can introduce vulnerabilities that bypass all other security controls, potentially allowing attackers to manipulate signing processes or steal funds before detection.

Software supply chain attacks have become increasingly sophisticated. Attackers specifically target cryptocurrency infrastructure by compromising trusted libraries, development tools, or package repositories. A single compromised dependency can provide attackers with persistent access to signing systems.

Unlike broader supply chain risks, dependency integrity verification provides concrete, measurable protection through technical controls that can detect tampering before compromised code executes in production systems.

Mature stablecoin issuers implement dependency integrity verification through:

Software bill of materials (SBOM). Issuers should maintain complete inventories of all software components to quickly identify if they are impacted when vulnerabilities are discovered.

Cryptographic verification. Issuers should validate signatures and checksums for all dependencies before installation or execution. Some package managers support digital attestations, such as PyPI’s PEP 740. Using package managers with similar functionality can help further reduce the risk of dependency compromise.

Dependency pinning. Issuers should use specific, verified versions of dependencies rather than automatically updating to potentially compromised newer versions. New dependency updates should be reviewed and vetted to reduce the risk of malicious code being introduced.

Regular dependency auditing. Issuers should use automated scanning for known vulnerabilities and use runtime monitoring to identify suspicious changes in dependency behavior. These controls provide measurable assurance that the software running in your signing infrastructure matches what you intended to deploy, rather than code that has been modified by attackers.

These controls provide measurable assurance that the software running in your signing infrastructure matches what you intended to deploy, rather than code that has been modified by attackers.

8. Do you have a written and tested incident response plan?

Even with robust preventative controls, security incidents will occur. A well-planned and tested incident response process can mean the difference between a minor security event and a catastrophic breach. Without an incident response plan, organizations typically make critical decisions under extreme stress, often leading to mistakes that compound the initial breach. For stablecoin issuers, delays in response could allow attackers to steal significant funds or damage the stablecoin’s market credibility beyond recovery.

An incident response plan details the procedures, roles, and communication strategies for responding to security incidents. For stablecoin issuers, such a plan should specifically address scenarios like compromised signing keys, fraudulent mint/burn transactions, and supply chain compromises.

More specifically, a high-quality incident response plan for a stablecoin issuer should accomplish the following:

• Assign clear roles and responsibilities for the incident response team members
• Document incident response procedures specific to expected incident scenarios
• Define clear thresholds and criteria for different response actions, such as notifying the public or contacting law enforcement
• Include procedures for preserving evidence and conducting forensic investigations

At the absolute minimum, stablecoin issuers must regularly perform tabletop exercises to test the various incident scenarios the plan is designed to address. They should also regularly review and update the plan as the underlying system and its processes change.

The lack of an incident response plan should be treated as a red flag. Without one, it is extraordinarily unlikely that the issuer will be able to detect, much less effectively respond to, an active incident.

9. Do you use monitoring tools that can trigger an incident response if discrepancies are detected?

Monitoring serves as your early warning system across multiple layers of defense. Without comprehensive monitoring, compromises can persist undetected for months, giving attackers time to study your systems and wait for the perfect moment to strike. The Ronin Bridge hack perfectly demonstrated this when $600 million was drained from their bridge, and the hack went undetected for a week.

Effective monitoring for stablecoin issuers requires three layers:

Endpoint detection and response (EDR). Every workstation that can influence the issuer’s signing infrastructure needs EDR coverage. Attackers often spend weeks or months moving laterally through corporate networks, looking for paths to critical systems. Modern EDR tools can detect and block these reconnaissance activities before attackers find their way to the signing infrastructure. Without EDR, an issuer would be essentially operating blind to threats already inside their network.

Security awareness and phishing resistance. An issuer’s employees are both the first line of defense and the greatest vulnerability. Regular security awareness training and simulated phishing campaigns create a human monitoring layer that technical tools can’t replicate. When employees can recognize and report social engineering attempts, issuers gain critical early warning of targeted attacks.

Reconciliation and operational monitoring. Beyond security monitoring, stablecoin issuers need continuous reconciliation between on-chain stablecoin supply and off-chain reserves. They should set alerts for unusual minting patterns, large transfers, or deviations from expected transaction volumes. When anomalies are detected, these systems should trigger automatic incident response procedures. All monitoring systems must be tested regularly through red team exercises and should use redundant, independent platforms for critical alerts. If an attacker can compromise an issuer’s monitoring infrastructure, they can operate with impunity.

Next steps

Institutional users should use these questions to inform traditional due diligence practices like vendor questionnaires. The amount of money an institutional user deploys to any one stablecoin should be informed based on both their risk tolerance and the security maturity of the stablecoin’s issuer.

Stablecoin issuers should use these questions as a high-level self-assessment tool, and build a roadmap to address any gaps in their operational security. More urgently, issuers need to expect high-volume users to start asking harder questions about their operational security. Gone are the days when an issuer could ignore a security questionnaire due to operational security concerns. Customers, large and small, are going to start demanding deeper answers on issuer security posture.

Need more tailored guidance? Trail of Bits has extensive experience helping stablecoin issuers and other cryptocurrency organizations evaluate and strengthen their operational security posture. Contact us to discuss how we can help protect your stablecoin operations against sophisticated threats.