Lessons from Drift and Resolv: Off-chain trust assumptions and real world consequences

Crypto systems are often described as trustless. But in practice, they rely on layers of trust that extend far beyond the blockchain.

In Turnkey’s recent State of Security ebook, we highlight how some of the most critical vulnerabilities don’t live in onchain code, but in the off-chain infrastructure that supports it. These systems introduce implicit trust assumptions that, when broken, can undermine even the most secure onchain designs.

Blockchains provide strong guarantees around execution. Transactions are predictable, state changes can be verified, and the underlying cryptography is well understood. But most real-world systems depend on components that sit outside those guarantees.

Signing services, cloud infrastructure, backend coordination, and human approvals all operate off-chain. These introduce assumptions that are not enforced by the protocol itself.

When those assumptions fail, the consequences are immediate and often irreversible.

In this article, we unpack the off-chain trust assumptions that define modern crypto systems, show how they break under real-world conditions, and outline a new security model built on constrained, verifiable execution.

Onchain security has improved across the board

At the protocol level, consensus mechanisms and cryptographic primitives have proven highly resilient. Attacks against base layers like Ethereum or Bitcoin are extremely rare and economically impractical, requiring enormous resources with little chance of success.

Smart contract security has improved over time as well. Better audits, stronger testing practices, and bug bounties have made common issues like reentrancy bugs and permission flaws far less frequent. Development standards have matured, and entire classes of vulnerabilities that were once common are now better understood and mitigated.

This progress has meaningfully reduced many of the risks that defined earlier stages of crypto.

But it has also shifted the threat model.

Crypto security’s off-chain threats

As onchain systems have become more robust, attackers have adapted.

Instead of targeting contract bugs or breaking cryptography, they now increasingly target the systems that connect to the blockchain.

The two recent exploits of Drift and Resolv, highlight a broader shift in crypto security. Systems are no longer failing because code is broken, but because trust assumptions are.Here’s what happened with each of them:

Both of these exploits followed the same pattern.

In the Resolv exploit, the contracts behaved exactly as intended. The issue was that an off-chain signer had the authority to mint tokens without enforced limits.

In the Drift exploit, attackers did not break the protocol. They manipulated the approval process and obtained valid signatures for malicious actions.

The system did what it was told. The problem was what it was told to do.

Modern crypto systems and the assumptions we tell ourselves

The blockchain can only enforce what it can see. Everything else becomes an assumption.

Most production systems rely on signing services to authorize transactions, cloud infrastructure to manage keys, backend systems to coordinate flows, humans to approve sensitive actions, and external data sources like oracles. These components exist for good reasons. They improve usability, enable automation, and make systems more flexible. But, they also expand the trust boundary. 

“When it comes to operational security, people need to consider what details someone, through open source intelligence gathering or even from close association with the team, could learn about your vulnerabilities. Even if you’re not publishing details about your operational security, assume bad actors can learn it over time. Prepare for them to target your weakest links and harden those as quickly as possible.”  – Michael Lewellen, Head of Solutions Engineering

Here are seven assumptions builders make when designing off-chain systems, often without realizing it:

Assumption 1: Off-chain infrastructure is trustworthy

Cloud environments, backend systems, and signing services are often treated as secure by default. This is not necessarily the case.They can also very much be part of the attack surface.

In the Resolv exploit, access to their infrastructure effectively gave the attacker control over the protocol’s minting authority.

Similar patterns have been seen across compromised deployment pipelines, leaked API credentials, and access to internal signing systems.

Once infrastructure is compromised, the attacker inherits its privileges.

Assumption 2: Humans will make correct decisions

Many systems rely on human approvals for sensitive operations, whether through multisig signers, admin permissions, or manual transaction reviews. In practice, this introduces a different class of risk.

The Drift exploit demonstrated how this assumption breaks down. Attackers did not bypass controls at the code level. They worked around them by convincing legitimate signers to approve transactions that granted elevated access. From the system’s perspective, these actions were authorized.

Human judgment is not a reliable security boundary. People can be deceived, rushed, or operating without full context. Systems that depend on consistently correct human decisions for critical actions are inherently fragile.

Assumption 3: Failures will be contained

Crypto systems are highly composable, and that composability introduces systemic risk.

When one system fails, the impact rarely stays contained. Liquidity is drained, collateral values collapse, and downstream protocols absorb losses. The Resolv exploit triggered a sharp de-peg in its stablecoin, affecting users and integrations across the ecosystem.

This pattern is not unique. Similar cascading failures have followed oracle manipulation attacks, bridge exploits, and stablecoin collapses. 

Composability increases efficiency and unlocks new product experiences, but it also amplifies the blast radius when assumptions break.

Assumption 4: Key storage alone defines security

Key security alone does not define system security. If a key has broad, unconstrained authority, compromising how it is used is enough.

This is what happened in Resolv. The key itself remained protected within a secure environment. It was not extracted or exposed in the traditional sense. But once the surrounding infrastructure was compromised, the attacker was able to use that key to authorize arbitrary minting.

This highlights a more complete view of security. Protecting keys is necessary, but it must be paired with clear constraints on what those keys are allowed to do.

Without those constraints, a secure key can still produce insecure outcomes.

Assumption 5: A valid signature means a valid action

Many systems treat signatures as proof that an action is correct. This is a flawed assumption.

In Resolv, the contract only checked for a valid signature before minting tokens. It did not enforce any maximum minting constraints or collateral ratios.  Once the signing key was compromised, the attacker could mint tens of millions of unbacked tokens. 

In Drift, attackers used social engineering to get legitimate signers to approve malicious transactions. The signatures were valid. The intent was not.

A signature proves authorization. It does not prove correctness.

Assumption 6: Audits cover the full risk surface

Audits are critical, but they have limits. They focus on whether code behaves as intended. They do not always evaluate whether the system design is safe under adversarial conditions.

Resolv was audited multiple times. The issue was not incorrect code. It was that the system trusted an external signer without enforcing constraints.

This is a design problem. A system can pass every audit and still fail in production.

Assumption 7: Monitoring and response are sufficient

Many systems rely on detecting anomalies and reacting to them after the fact. In theory, this provides a safety net. In practice, it does not.

The Resolv exploit unfolded in minutes. The attacker was able to mint and extract tens of millions in value before any meaningful response could occur. By the time the issue was detected, the transactions had already been finalized and the funds had moved across the ecosystem.

This is the fundamental limitation of reactive security. Detection does not prevent execution. It only explains what happened after the damage is done.

Modern attacks are automated, fast, and designed to complete within a single execution window. There is no opportunity for human intervention once a malicious transaction is in flight.

Security needs to move from trust to enforcement 

The core problem is not that systems rely on off-chain components. It is that they trust those components without enforcing constraints on what they can do.

This creates a brittle model. If everything behaves correctly, the system is safe. If anything fails, the system fails completely. There is no margin for error, and no containment when assumptions break.

This is the common failure mode across modern exploits. The system delegates authority to a component, whether that is a signer, a backend service, or a piece of infrastructure, and assumes it will act correctly. When that assumption fails, the system has no way to limit the impact.

A more resilient approach starts from a different premise. Any component can be compromised. Any credential can be misused. Any approval can be coerced. Security must be designed with that reality in mind.

This shifts the model from trust to enforcement. Instead of focusing on who is allowed to act, systems must define what actions are allowed. Authority should be scoped, constrained, and continuously validated at execution.

In this model, a compromised component does not imply total system failure. It is limited to a predefined set of safe actions.

How Turnkey reduces off-chain trust assumptions

Turnkey is designed to minimize and constrain the assumptions that lead to these failures.

Private keys are generated, stored, and used entirely within secure enclave infrastructure. They are never exposed to application code or general-purpose cloud environments in a way that allows extraction or misuse. But key protection is only one part of the model.

Every action is governed by policy at the moment of signing. Instead of treating a signature as sufficient proof of correctness, the system evaluates whether the requested action is allowed under a defined set of constraints.

Developers can define policies that control where funds can be sent, how much value can move, which contracts can be called, and what approval structure is required. These rules are enforced in real time, at the point of execution.

This fundamentally changes the impact of a compromise.

Even if a credential is exposed or a signer is manipulated, it can only be used within the boundaries defined by the system's policies. A properly configured policy can prevent a key from minting unlimited value or a signer from approving transactions outside defined boundaries.

The system does not rely on intent. It enforces the constraints developers set. 

This directly addresses the failure modes seen in Resolv and Drift. Instead of assuming that components behave correctly, the system constrains what is possible.

Off-chain security and policy that move applications from assumptions to guarantees with Turnkey

Onchain security has improved dramatically. Smart contracts are safer. Cryptographic primitives are well understood. Core blockchain infrastructure is more robust than it has ever been. But the highest impact risks no longer originate from these layers.

They come from the assumptions systems make about everything around them. Off-chain infrastructure, human processes, and signing authority now define the real security boundary.

The next generation of secure systems will not eliminate these components. They will constrain them. Because in practice, there is no such thing as trustless infrastructure. There are only systems that rely on trust, and systems that enforce it.

Get started with Turnkey today. 

‍

‍

‍




‍