Jack Kearney

The through-line

Jack Kearney's consistent claim is that crypto security reduces to one problem, and it is not the blockchain: it is the private key. "Protecting those private keys is essentially equivalent to storing that crypto," he argues, and every risk that follows comes from moving that key around, because "if you're moving the actual key around, if you're moving the actual key around, that exposes it to tons of different kind of software that could ultimately be doing something sketchy with it" [1]. From that starting point he has built a position that key management is undifferentiated work most builders should never touch, and that whoever does it for them owes customers proof rather than promises.

The shift over time is from securing keys to making security auditable. The earliest public framing of Turnkey was private key as a service, an API for creating, managing and using keys, running on Amazon Nitro to give customers of any size a secure enclave in the cloud [4][7]. The later preoccupation is verifiability: not only keeping a key locked in an enclave, but proving to a customer exactly which version of which application touched it, on every request [1][2].

On what crypto custody actually is

Kearney treats custody as a plainly explainable idea that people over-mystify. A blockchain is a decentralised ledger running on many computers, and the only way to change it is to digitally sign a transaction with a private key, so guarding the key is guarding the funds [1]. He is also alert to the word's regulatory weight: custody is "kind of a trigger word when it comes to regulation," since funds and other regulated financial institutions past a certain size must store assets with a qualified custodian holding a particular registration [1]. His own route into the problem was practical rather than theoretical. He was one of the first engineers on Coinbase Custody, partly because a childhood friend running a crypto hedge fund kept telling him about the trouble of storing assets, and he later did custody work at Polychain Capital, where he concluded there was "a kind of gap in the market on programmable great tools to store crypto keys" [1]. That work on custody, alongside validators, is what he and his co-founders point to as the origin of Turnkey's approach to key management [2][3].

On being infrastructure, not the product

The analogy he reaches for is AWS at the moment companies stopped racking their own servers. Hiring an ops team to rack machines and do internal networking just to ship a web API was "a really like undifferentiated piece of work," so the cloud absorbed it and let entrepreneurs spend their energy on what distinguished their business [1]. He puts key management in the same category: developers who want to move crypto from point A to point B, or build front ends where users hold crypto and interact with DeFi protocols, all have to store private keys on behalf of customers, and doing that is the same work every time [1]. Turnkey's ambition is to do it as well and as securely as possible so builders can "get back to making what's differentiated for their product" [1], with the practical shape of that being an API that lets developers spin up thousands of wallets and sign millions of transactions [3].

On verifiability and key provenance

The technical bet is on secure enclaves, specifically AWS Nitro Enclaves, which he describes as constrained and in some cases auditable computers: at boot you can observe exactly what loads into the machine, and Amazon's key infrastructure signs an attestation of that boot process so you know precisely what is running [1][4][7]. Turnkey has "invested really really heavily into the ability to be able to audit like precisely what particular piece of source code is running in each of these secure enclaves at any point in time," to the point of proving that a specific commit or version of an application is live in a given machine [1]. Mechanically these are EC2 instances on the Nitro stack, with CPU cores and memory carved out into an enclave that Amazon then attests to; dedicated hardware is not required for attestation, though he sees benefits to avoiding multi-tenancy for "super sensitive stuff" [1].

The current push is to make that attestation user-facing rather than internal. He wants every API request that hits an enclave to return proof in the response that it was served by a particular version of the enclave, which delivers what he calls key provenance: knowing where a key has been across its whole life cycle [1]. The claim he wants to be able to make is definitive: "this key was generated in this enclave and it's never left this enclave," with proof attached to every interaction [1]. He frames this as cutting edge and as the thing that separates Turnkey technically. Competitors do "bits and pieces" of the same job, naming Fireblocks as an API-driven crypto storage and asset movement platform and Privy as somewhat similar, but in his view "no one's quite doing the verifiable thing" [1]. The supporting stack he and his co-founder have described publicly includes QuorumOS, a deterministic operating system for secure execution of applications such as the Policy Engine, Signer and EVM Parser, along with the provisioning process for initialising those applications securely and the risk profile of hardware security modules and HSM cloud providers [4][7], and the broader theme of verifiable key management using trusted execution environments [2].

On policy as a second layer of defence

Keeping a key still is not sufficient on its own, so Turnkey pairs enclave isolation with a policy engine that governs the conditions under which a key will sign anything [1]. His worked example is a rule requiring two named people to approve a transaction before it is signed, which changes the blast radius of a breach: "one person's account being compromised won't lead to a compromise of the funds," because both parties would have to be compromised [1]. He presents this as control handed to the developer rather than a setting Turnkey chooses, which fits the wider argument that the platform supplies primitives while the customer supplies the product.

On security through transparency

He rejects secrecy as a security strategy and treats openness as a duty. "I like to be super transparent actually, like I like to talk about what we're doing you know kind of at every level of the stack," he says, invoking the principle that "security shouldn't be through obscurity" and adding that "shining light on where you might have flaws is the best way to sort of illustrate and improve your product" [1]. This is the cultural counterpart to the verifiability work: publishing the architecture and proving the runtime are two versions of the same refusal to be trusted on faith.

On new technology built from old parts

Kearney resists the framing of crypto as purely novel. What is interesting to him is the recombination: much of the cryptography underpinning the most important cryptocurrency networks, and much of what Turnkey uses under the hood, "has been around for decades," and the novelty comes from putting those pieces together in new ways [1]. His own entry point was 2011, between his junior and senior years of college, when Bitcoin was "a really nascent weird technology" with perhaps a couple thousand people tinkering with it, sitting at the intersection of the maths and economics he was studying [1]. He ran full nodes and moved money around, but waited until 2016 to go professional, largely because few companies were doing anything with Bitcoin at scale, joining Coinbase as roughly its thirtieth engineer on a combined infrastructure and security team [1]. He and his co-founders have also reflected publicly on how much crypto changed between that entry and Turnkey's launch, and on how they reached conviction on the opportunity before starting [3].

On team, culture and how the work gets done

His view of startups is blunt: "ideas are cheap, let's say, and execution is incredibly hard," and Turnkey would not be possible without the team behind it [1]. That team leans senior, heavy on people who have been in crypto a long time, and a number of the core founding engineers were people he and his co-founder Bryce worked with directly at Coinbase Custody, arriving with direct experience of key management and the product problems that come with handling keys at scale [1]. What he selects for beyond that is autonomy and agency, people who drive initiatives forward on their own, captured in an internal phrase: "we're looking for high context, low ego people," meaning people deeply informed about what they are building who will not be "the brilliant jerk in the room," which he calls critical to a successful engineering culture [1]. The co-founding relationship itself came out of shared work, meeting at Coinbase Custody where he was one of the first engineers and Bryce the first product manager, scaling the system from essentially zero to around a hundred billion dollars of assets and attacking a net new problem from the engineering and business sides respectively [1][3][4].

On location he is deliberately hybrid. About half the team sits in the New York office, but he accepts that "talent is everywhere in the world" and wants to hire excellent people wherever they are, while bringing them together in person frequently [1]. His reason is qualitative: "there's nothing quite like high-fidelity, low latency conversations that you get in person," and he doubts complicated problems can be tackled without occasionally standing in front of a whiteboard together [1].

On the founder's transition

Moving from engineer to CTO and co-founder he describes as "a totally different job than when I was an engineer through and through," and he is explicit that there are many valid ways to hold the role [1]. It was his first time founding a real company and his first time raising money, aside from a small venture in college that is what led him into programming in the first place [1]. Turnkey started in early 2022; the seed round was led by Sequoia Capital, with Alfred Lin taking the lead, and the investor base has since grown to include Variant, Coinbase and Exponent, through to a thirty million dollar Series B [1][3].

Takeaways

• Custody is key protection, nothing more mysterious: signing a blockchain transaction requires a private key, so guarding that key is functionally identical to holding the funds [1].
• The largest exposure is movement. Every time a key travels between systems it meets software that might misuse it, so the design goal is a key that is generated in an enclave and never leaves it [1].
• Verifiability is the differentiator: Turnkey aims to return proof on every API response that a specific version of a specific enclave served the request, giving customers key provenance across the key's life cycle [1][2].
• Enclave attestation runs on AWS Nitro Enclaves, where the boot process is signed by Amazon so the exact source code running can be audited, and Turnkey pairs this with QuorumOS, a deterministic OS running its Policy Engine, Signer and EVM Parser [1][4][7].
• A policy engine gives developers rules such as requiring two approvers before signing, so a single compromised account does not compromise the funds [1].
• Security should not depend on obscurity: publish the architecture at every level, because exposing flaws is how the product improves [1].
• Key management is undifferentiated work, the same job for every builder, and should be absorbed by infrastructure the way AWS absorbed racking servers [1].
• Hire "high context, low ego people" with autonomy and agency, keep the team senior, and get everyone in front of a whiteboard often enough to solve hard problems [1].