Turnkey: Putting verifiable policy around every stablecoin signature

For Range, wallet security extends beyond one question: where is the private key? The full path between a payment request and an irreversible transaction also has to authenticate the request, understand the transaction, apply policy and prove that the approved code produced the signature.

Paula Pettit, VP of Strategy and Growth at Range, spoke with Michael Lewellen, Head of Solutions Engineering at Turnkey, about that wider control boundary. Lewellen moved from smart contract audits and incident response into offchain key management after seeing how often losses began with access, authorization and operational process. Range's view is that institutional stablecoin infrastructure has to preserve settlement speed while making every decision around a signature specific, enforceable and verifiable.

The control boundary extends beyond the key

Lewellen's path to Turnkey started with years of smart contract work, including security audits and incident response. That experience changed where he saw the most consequential failures occurring. As he put it, "For the most part, every year, if you look at the numbers, it was actually key management or access to keys that was being compromised." He pointed to the recent $1.5 billion Bybit loss as an example centered on blind signing and transfer authorization, including a failure that reached a multisig. The distinction matters because a perfectly protected key can still sign a transaction that should never have been authorized.

Traditional hardware security modules secure key material and sign the instructions they receive. They do not independently decide whether an instruction complies with a company's policy. Lewellen described the limitation directly: "The problem with HSMs is they are kind of like dumb cards. They're just their job is to hold a key and sign what you tell it to sign." The controls around access, approvals and transaction intent therefore carry as much operational weight as the storage mechanism itself.

Turnkey's model brings key management, request authentication, transaction parsing and policy enforcement into a secure enclave. In Lewellen's account, the key cannot be accessed by Turnkey or by someone inside the customer's organization who lacks the required authorization. Every transfer request carries end-to-end authentication, and policy is evaluated in the same trusted environment that protects the key. The same environment evaluates what the transaction does, where value is going and which smart contract function is being called before it signs. This reduces the number of critical decisions that sit outside the protected boundary.

Range's view is that this is the right level at which to evaluate institutional stablecoin controls. Finance and risk teams need a connected record of the request, the counterparty, the policy decision, the approval and the resulting transaction. Key custody remains foundational, while operating control comes from linking that custody model to the full decision path.

Stablecoin speed requires policy at authorization

Stablecoins compress settlement time, which changes how companies should place friction in a payment process. Lewellen observed that institutions can carry the slow habits of fiat rails into stablecoin operations, even when the new rail settles much faster. Their existing systems often assume longer settlement windows or known counterparties that can help recover funds. Onchain settlement removes much of that response time. Range's view is that delaying every transaction gives up much of the rail's advantage without necessarily improving the quality of the authorization decision.

His alternative is to distinguish established destinations from new ones. Lewellen explained, "Yes. Users can instantly settle, but you can define allow lists or things that define exactly where they could settle to instantly." An allowlisted destination can support fast settlement, while a newly introduced address can trigger multiple approvals and a cooling-off period before it becomes trusted. That distinction is particularly relevant to business and international payments, the stablecoin use cases Lewellen identified as growing quickly.

That model gives finance teams a more precise control surface. Policy can reflect who may add a destination, how many people must approve it and when it becomes active. Once those conditions are satisfied, routine transfers do not need to inherit the delay of the highest-risk exception. Lewellen's point is that stablecoin speed and institutional control can coexist when policy is attached to authorization rather than imposed as blanket latency.

Range's operating model begins with the regulatory and reporting requirements a company must satisfy, then translates them into operational controls for each transaction. Range orchestrates the risk and compliance providers the company already uses, and monitoring, reconciliation and reporting run from the resulting record. For teams using Range, destination approval, counterparty risk and pre-execution enforcement belong in that shared control path, so the transaction can be evaluated before settlement and explained afterward.

Secure enclaves turn trust into evidence

Turnkey chose secure enclaves after weighing the performance and cryptographic complexity of multi-party computation. Lewellen acknowledged a tradeoff in that architectural choice. In his explanation, MPC signing requires communication among separated key shards, which can add between one and ten seconds to authorization when those shards are properly separated. That delay becomes visible in consumer applications, where users expect a response in a fraction of a second. MPC's more complex cryptography has also produced implementation failures that are difficult to identify without deep specialist expertise.

The enclave approach uses established asymmetric cryptography for signing and places the wider security model inside isolated hardware. That environment can hold the key, parse a transaction and enforce granular policy together. A policy can inspect the destination, chain and contract call, while only someone controlling the Turnkey account through a cryptographic credential, such as a passkey or YubiKey, can set policies. Upgrade authority can also require multiple authorized engineers. The aim is to protect both the key and the logic that determines when it may be used.

Remote attestation is the evidence layer in that model. Turnkey can publish a boot proof, and a customer can check that the code responding to a request matches the code represented by that proof. Lewellen explained, "So there's actually this verification mechanism for end users to verify what they're interacting with, and, you know, that it was audited and all these other things." Customers can compare the code handling each request with a published proof and confirm that the audited version is still running.

Institutional buyers still ask for familiar corporate controls, including IP allowlisting, corporate SSO, audits, penetration testing and top-down administration. They also want clarity about the legal and technical nature of custody, especially when users retain control without managing seed phrases. "But I think most importantly is they just wanna understand the model enough that they can feel comfortable with it." Lewellen described common authentication standards, including passkeys, SSO and OIDC, as a way to give users control through familiar product experiences. Verifiable architecture helps turn that understanding into evidence a risk committee can assess.

Incident readiness is an operating discipline

Lewellen's experience responding to a vulnerability affecting Compound illustrates why architecture alone is incomplete. During an audit, his team found that a deprecated token entry point could bypass a check and move roughly $80 million out of its expected contract. The issue had been present for about a year, since the asset was listed. The funds would have remained under DAO control, but the accounting disruption could have created a profitable borrowing opportunity for an attacker as loans no longer matched the contract's balances.

The response required judgment about disclosure and authority. A governance patch would have remained visible for seven days, giving observers time to reverse engineer the vulnerability. Pausing the protocol for the same period would have imposed a significant operational cost. The team instead contacted the token issuer, explained the issue and asked it to disable the deprecated contract. The issuer joined a call, reviewed the bug and acted promptly. Lewellen's team then verified the change, resolving the vulnerability without exposing it through a public proposal and without an exploit.

That episode informs Lewellen's approach to incident runbooks. Specific scenarios are useful, but novel incidents still require a general operating process: a named incident lead, an on-call group, rapid triage, root-cause analysis, response options and a communications plan. Lewellen's conclusion was that teams discover the weak points in their response process by testing it. War games and response tests scheduled within an announced week reveal whether the people holding emergency authority can act when the process is under pressure.

Compound's emergency multisig became one such test. Lewellen's team ran pager exercises, identified participants who did not respond quickly and moved from a volunteer group to a paid, professional arrangement with explicit obligations. The reason was measurable: "And the speed with which they can move is often a big determinant of how much you can save." A sound policy has to name the people who can act, and a credible runbook has to prove they will.

Put policy, evidence and response around every transaction

Range's view is that institutional stablecoin operations need one control model spanning requirements, counterparties, approvals, signing, monitoring and reconciliation. See how Range supports stablecoin operations and build a process that can move at settlement speed while preserving evidence for every decision.

About Turnkey

Turnkey provides non-custodial wallet infrastructure for payments, stablecoin applications, consumer products and AI agents. Its platform combines wallet creation, transaction signing and programmable policies through a single API, with key operations isolated in secure enclaves. Learn more at turnkey.com.

Want to appear on Range Stablecoin Fireside? If you are building with stablecoins and want a seat on the show, get in touch by email or on X.