The New Security Bar for Onchain Finance
Private Today, Durable Tomorrow
As onchain finance moves closer to traditional markets, digital assets are being held to higher standards and sharper requirements.
Two critical issues exist in this new world: the movement of capital onchain is open for all to see, and the cryptographic signatures underpinning the entire technology are at risk from quantum developments.
Nowhere does this matter more than Bitcoin.
Currently representing over 56% of the total crypto market cap, Bitcoin still anchors the crypto market, despite offering little native programmability.
To improve its utility and programmability, Bitcoin has been exported across chains, introducing it to the onchain financial world through wrappers.
But Bitcoin in DeFi does not just need higher yield; it needs a way to move in size without a broadcast, and the assurance that it will be safe when the quantum computers of tomorrow arrive.
The same is true across onchain finance: assets need to move, settle, and compose without exposing every position to the public, and without relying on cryptography that may not survive the next decade.
We have been tracking one protocol in particular that appears to have understood these issues and built around both problems earlier than most.
Despite its BTCFi campaign earlier in the year, Starknet is not simply making Bitcoin usable onchain. It is using Bitcoin as the first clear test case for conditions both individuals and institutions actually care about: private by default, discloseable when required, and hardened for a post-quantum future.
For background reading on Starknet’s work in this area, we covered why $2 trillion of Bitcoin sits idle and how Starknet’s roadmap charts a path to trustless BTC, and Starknet’s new privacy framework, STRK20, and why they designed the system for “privacy through ownership”.
Privacy and the quantum ticking clock
A core mantra in crypto has always been “don’t trust, verify”, and that’s what public, transparent blockchains have always allowed us to do. Verify balances, snoop on transfers, inspect capital flows, and monitor contract interactions. All open for everyone to see.
You can understand how this started.
Transparency builds trust, but total transparency undermines one’s intellectual property, strategy, personal safety, and operational privacy. This is especially true today, where AI-driven de-anonymisation can link public addresses to real identities at up to 90% precision.
Privacy is not only a human right but also a critical infrastructure required onchain for both user protection and institutional adoption.
Individuals need privacy to avoid surveillance, profiling, harassment, crime, and political exposure. Institutions need privacy to ensure confidentiality of positions, order flow, and other data, as well as protection from counterparty visibility and strategy leakage. Additionally, privacy needs to be configured so that selective disclosure is available to auditors, regulators, or compliance.
Previous attempts at onchain privacy have repeatedly highlighted the trade-offs:
Purely anonymous privacy pools like Tornado Cash ran into compliance pressure, leading to OFAC sanctions, as well as criminal charges and prison sentences for developers, living proof that non-compliant pathways are fraught with political and legal risks.
Privacy coins on native chains (e.g. Monero, Zcash) proved hidden transactions are possible, but have consistently struggled to integrate with the rest of the onchain world, unable to compose with DeFi primitives at scale, pointing to a problem larger than privacy alone, but one of liquidity, interoperability and compliance.
Private execution systems like Aztec saw early demand for private DeFi, but they often faced high costs, liquidity fragmentation, and subpar user experiences.
The problems arising from a lack of privacy do not exist in an isolated onchain world, but have bled into the physical one. Onchain addresses tied to real people with public balances present heightened attack risks. CertiK reported 34 verified physical attacks on crypto holders in the first four months of 2026, up 41% year-on-year, representing only the recorded portion of these extremely underreported incidents. More specifically, in France, there were 41 crypto-linked kidnappings from January to May 2026, around one every 2.5 days.
Privacy is not only about hiding trading activity or protecting alpha, but also increasingly about reducing personal and operational risk.
While the privacy issue is actively being addressed in the industry, another threat has surfaced in quantum computing. A path to address both visibility and durability can drive blockchains closer to becoming the next generation of financial infrastructure.
In March of this year, Google Quantum AI’s report, co-authored by Justin Drake (Ethereum Foundation) and Dan Boneh (Stanford), identified multiple attack paths and estimated roughly $100 billion was at risk across the Ethereum ecosystem. It also singled out Starknet as having a stronger post-quantum position than other major L2s because its proof system is based on hash-based STARK assumptions rather than elliptic-curve cryptography.
The paper focused on secp256k1 public-key exposure, relevant to Bitcoin and Ethereum wallets, stating a sufficiently powerful quantum computer could attack a wallet in under 9 minutes, with Justin Drake later warning there is “at least a 10% chance” a quantum computer can recover a private key from an exposed public key by 2032.
Whilst this is not a reality today, the long-term security, and hence longevity, of an asset meant to be held across decades has been called into question.
Bitcoin is the most important digital asset in the world, and as it increasingly serves as collateral, treasury reserves, and an asset on institutional balance sheets, its security and privacy requirements rise.
In the following section, we highlight one solution being developed around Bitcoin, the largest and clearest test case for these privacy challenges.
strkBTC: private Bitcoin on Starknet
We’ve all likely used BTC wrappers before. They let Bitcoin move into other ecosystems and become composable: as a tradable asset, as collateral, as liquidity.
What they haven’t solved is visibility.
While wrapped BTC can become productive, every movement can still be monitored, inspected, and traded against. Deposits, loans, trades, LP positions, repayments, withdrawals, wallet clusters, treasury movements. All public by default.
That is not how serious financial markets work, and until this is solved, onchain finance will keep hitting an institutional ceiling.
In traditional finance, privacy is built into the plumbing, whether you are a retail mouse or an institutional behemoth. In fact, a large share of equity volume moves through private or off-exchange venues like dark pools, where counterparties see what they need to see, regulators retain access where required, and the public sees aggregated volume rather than every move as it happens.
Crypto has treated visibility as standard. In reality, privacy should be the norm.
strkBTC is Starknet’s attempt to enable Bitcoin to move through the onchain financial world without that restriction.
strkBTC is an ERC-20 on Starknet, backed by BTC locked on the Bitcoin network, and built on STRK20, StarkWare’s privacy framework for shielded balances and private transfers.
STRK20 gives strkBTC two modes:
In public mode, it behaves like a standard ERC-20: users can hold it, transfer it, supply it to lending markets, provide liquidity, or use it as collateral.
In shielded mode, selected balances and transfers are hidden from public view. Users can shield, transact privately, and unshield back into a public balance, directly from inside their wallet.
Before Starknet v0.14.2, the upgrade that enabled STRK20, an application that wanted to verify a STARK proof on Starknet would have had to do so inside a smart contract, making it prohibitively expensive and complex due to the size of the proofs. But now, transactions can reference offchain proofs directly, with Starknet consensus handling verification natively through in-protocol proof verification.
This has unlocked privacy at the protocol level, rather than the historical friction of using separate apps, chains, pools, or mixers, which add complexity, cost, and liquidity fragmentation. This allows apps to focus on building better products, as the underlying infrastructure has made private actions easily accessible to builders.
Compliance is a key part of the design, the piece that opens up Starknet to the institutions coming onchain.
When a user shields strkBTC, an associated viewing key is shared with Financial Privacy Inc, also known as FPI, the independent third-party auditor operating the compliance infrastructure for STRK20, granting it scoped access in the event of a valid regulatory request. Whilst this may be at odds with pure cypherpunk philosophies, it aligns much more closely with traditional markets. Privacy from the public, with disclosure to the regulator.
The bridge follows a similar logic and is operated by a trusted strkBTC Federation made up of Twinstake, NEAR Intents, Luganodes, UTXO Management, and Xverse. Currently, these independent signers support the minting and burning between BTC and strkBTC. The Federation is not the end state; however, Starknet is set on progressively hardening the roadmap over time.
strkBTC is not meant to be another wrapper, but to unlock the potential of a programmable, composable BTC whose movements are not broadcast, thereby solving the first problem: visibility.
The next problem is durability.
Blockchain’s quantum problem
Every blockchain relies on public-key cryptography. When a user signs a transaction, they reveal their public key while keeping the private key hidden. This is routine across Bitcoin and most other blockchains, and is considered completely normal and safe in today’s environment. But in a post-quantum world, that assumption gets a little shaky.
As alluded to earlier, a sufficiently powerful quantum computer running Shor’s algorithm could, in theory, derive a private key from an exposed public key. That means public-key exposure, a harmless part of transaction verification, could soon turn into a potential attack surface. This is not unique to any one chain, as the same elliptic-curve foundations sit under Bitcoin, Ethereum, and Solana alike.
The threat is shared, but the ability to respond to it is not. The chains most exposed tend to be the ones that move the slowest, and Bitcoin is the clearest example.
Bitcoin is not short of ideas for a post-quantum future. If anything, it has too many. The problem is agreeing trade-off the network is willing to accept: bigger signatures, higher costs, legacy coin treatment, user migration, wallet support, miner policy, or a fight over freezing dormant and unmigrated coins.
It’s clear the issue with Bitcoin is just as much social and political as it is technical.
Dan Boneh, one of the co-authors of Google’s paper, calmed everyone’s nerves in a recent interview: “Bitcoin should not panic, but it cannot ignore this either. Moving too fast could be worse than waiting, because a rushed post-quantum migration may introduce a catastrophic bug before quantum ever becomes a live attack.”
Bitcoin will probably solve its quantum problem, but not quickly or cleanly.
That sluggishness is, in part, a feature of sound money, but it also leaves the door open. While the base layer debates, more agile stacks can build the durability that Bitcoin itself cannot yet commit to.
Ethereum and, by extension, L2s do not escape this problem. Most rollups settle to Ethereum and rely on it for data availability, thereby inheriting the base layer’s exposure. Ethereum is aware of this and has published a multi-year migration plan of its own, but until that arrives, every chain built on top of it is exposed to Ethereum’s post-quantum migration problem.
This is where Starknet has a head start. Although it settles to Ethereum like any other L2, the core of Starknet, its proving layer, was built on a foundation not dependent on the quantum-vulnerable cryptography. Although the inherited exposure from Ethereum is real, everything within Starknet’s own stack carries less migration debt than on most major chains, and it has more in the pipeline.
The Architecture Advantage
Starknet’s position of strength originates from two design choices, both made long before quantum was an urgent concern.
The first is the proving layer, the system that generates the STARK proofs securing every state transition on the network. It relies on hash functions rather than the elliptic-curve mathematics quantum computers threaten, and has done since the 2018 paper co-authored by StarkWare CEO Eli Ben-Sasson. This is the key, security-critical layer, and it’s why Google’s paper named Starknet as the one major L2 already ahead of the game.
The second is native account abstraction. On most chains, the signature scheme is fixed at the protocol level, so replacing it requires a hard fork that every user and application must follow. Starknet, on the other hand, lets the account define how it authenticates, so a user can move to a post-quantum signature without any protocol-level change. S2morrow, a quantum-proof wallet, has already been deployed using Falcon-512, and OpenZeppelin is building a standardised version, according to StarkWare.
On many chains, this kind of change means a coordinated protocol migration. On Starknet, much of it can begin as a wallet upgrade. Now, this does not mean every Starknet wallet is post-quantum; it means the model gives users on Starknet an easier way to get there.
StarkWare is now working to close the remaining gaps. Last week they published a roadmap to make Starknet post-quantum secure end-to-end before Q-day, the point at which a quantum computer becomes powerful enough to break today’s cryptography.
It runs in three phases:
None of this makes Starknet fully quantum-safe today, and the roadmap doesn’t claim otherwise.
What still has to be proven?
Starknet can replace Pedersen with BLAKE2, improve post-quantum wallet support, and provide legacy contracts with a migration path, but it cannot eliminate all the issues it inherits from its base layer. Bridge messaging and blob data availability still sit downstream of Ethereum’s own post-quantum roadmap. Starknet can harden the surfaces it controls, but surfaces inherited from Ethereum will move on Ethereum’s timeline. That being said, the Ethereum Foundation has outlined structured fork milestones targeting completion of core post-quantum infrastructure by approximately 2029.
strkBTC has a similar phased story. Today, the bridge relies on a Federation to coordinate minting and burning between BTC and strkBTC. A credible starting point, but not the desired trustless end state. Starknet aims to move from a federated model toward Bitcoin-native verification, then a more trust-minimised BitVM design, and finally a fully trustless OP_CAT-based design if Bitcoin enables the required opcode in the future.
Viewing keys are the other piece still to be proven. They are Starknet’s practical answer to institutional privacy: public opacity with selective disclosure, but have yet to be pressure-tested in real-world circumstances, raising questions about who can request disclosure, under what conditions, and with what safeguards.
Conclusion
Digital assets, Bitcoin included, do not need another wrapper. They need the infrastructure around them to operate onchain without compromising the two things institutions care about most: confidentiality today and durability tomorrow.
strkBTC addresses confidentiality by giving BTC a private, selectively disclosable route into DeFi. Starknet’s existing architecture and roadmap target durability: its proof layer already avoids the elliptic-curve assumptions that create post-quantum migration debt for others, and its roadmap now extends that advantage across the remaining surfaces, with the stated goal of making Starknet post-quantum secure before “Q-day”.
While the result is still early, the direction is clear: onchain finance’s next institutional phase will require more than yield. It will need privacy, compliance, programmability, and durability all in the same stack.
Originally published in the Castle Labs newsletter. Subscribe at research.castlelabs.io/subscribe.