The Final Piece of BTCFi: Starknet Privacy

Table of Contents

1. The Final Piece of Starknet BTCFi: Privacy

2. Starknet as an Institutional-Grade Privacy Execution Layer

3. Starknet Privacy Architecture

4. Phased Privacy Rollout and STRKBTC

5. Market Implications and the Future of BTCFi

 

 

1. The Final Piece of Starknet BTCFi: Privacy

Institutional BTC holdings have expanded rapidly, rising from 0.8M BTC in 2021 to 3.66M BTC within five years. If this trajectory continues, institutional ownership is projected to reach 36% over the next five years; on a liquid supply basis, the share could exceed half, reaching 51.9%. Rising institutional dominance in BTC ownership points to a structural shift in BTCFi: the market is increasingly driven by institutions rather than individuals.

As outlined in Xangle’s previous Starknet research, “BTCFi: From Retail to Institutions, from Institutions to Starknet,” Starknet satisfies the core conditions required to position itself as the execution layer for institution-driven BTCFi:

• connectivity with custody infrastructure
• stable BTC staking yields
• a large and mature DeFi ecosystem

Institutional participation, however, does not remain limited to custody-based staking. As infrastructure matures and regulatory clarity improves, institutions move toward active onchain operations; this includes direct asset management, position rebalancing, hedging execution, and liquidity provision. At that stage, blockchain’s defining characteristic, complete transparency, no longer functions purely as an advantage but instead introduces structural risk.

From an institutional perspective, security and reliability are baseline requirements. Equally important is avoiding real-time exposure of trading strategies. Onchain systems reveal position sizes, entry timing, collateral structures, and liquidation thresholds; each can serve as a signal to competitors or adversarial actors. A clear example emerged in May 2025 on the Hyperliquid futures market, where a large trader, James Wynn, experienced a targeted liquidation attack by coordinated short positions after his positions became publicly visible. The case illustrates how onchain transparency can erode information asymmetry and create conditions for market manipulation.

Risk extends further. Over recent years, onchain analytics platforms such as Arkham, Lookonchain, Dune Analytics, and Artemis have advanced rapidly, weakening practical anonymity. Address clustering, behavioral pattern analysis, and temporal correlation techniques are now routinely used to connect offchain identities with onchain activity. As reflected in Arkham’s X post, institutional accumulation, including timing and size, can be tracked and disclosed in near real time. The implication goes beyond visibility; such data can enable front-running, targeted liquidations, and other adversarial strategies.

Institutional demand, therefore, is not for absolute anonymity but for strategy-level privacy. Sender and receiver relationships, transaction amounts, and inter-transaction linkages must not be easily reconstructable; large position movements should not translate directly into market signals. Without these conditions, institutions are more likely to remain in custody-based exposure rather than engage in active onchain operations.

Privacy, in this context, is not an optional feature but a prerequisite for scaling institution-driven BTCFi. For Starknet to establish itself as the execution layer for institutional BTCFi, it must extend beyond scalability and security to include a privacy architecture that protects strategic activity. This defines the next stage of the Starknet BTCFi narrative.

 

2. Starknet as an Institutional-Grade Privacy Execution Layer

2-1. Core Design Requirements for Institutional-Grade Privacy

A range of privacy solutions has emerged across the Web3 ecosystem: mixer-based approaches that obscure fund origins by pooling assets; application-layer designs that implement privacy at the app level; and chain-level architectures that render the entire execution environment private. Despite this diversity, institutional privacy requirements differ fundamentally from the commonly perceived notion of “complete anonymity.” Institutions operate within regulatory frameworks and cannot adopt systems detached from source-of-funds verification, accounting transparency, and auditability. What is required is not unconditional secrecy, but privacy that protects capital and strategy while remaining compatible with regulatory systems.

An institutional-grade privacy blockchain, therefore, is not defined by the strength of anonymity alone. It must simultaneously satisfy four structural conditions:

First, resistance to traceability.

Institutional concern extends beyond simple amount disclosure to the reconstruction of asset flows into identifiable strategies. Even if individual transactions remain private, protection is insufficient if address interactions and behavioral patterns can be linked and inferred as a coherent strategy. A viable design must ensure that the activity flow of a specific entity cannot be structurally reconstructed from external observation.

Second, sufficient liquidity.

Capital efficiency sits at the core of institutional execution. Shallow depth or fragmented markets undermine execution regardless of privacy strength. Many privacy-focused chains have encountered this structural limitation: introducing privacy often led to disconnection from public liquidity, isolating assets in separate private pools, increasing slippage, and reducing execution efficiency. Institutional-grade systems must preserve access to public liquidity while maintaining privacy; privacy cannot come at the cost of market depth.

Third, availability of essential financial services.

Institutional participation extends far beyond transfers or custody. Staking, collateralized lending, derivatives hedging, and liquidity provision form a baseline requirement. If privacy applies only to transfers while core financial interactions remain transparent, its practical value is limited. Institutional strategies consist of sequential asset movements and position adjustments; if that sequence is externally traceable, strategy exposure becomes unavoidable regardless of scale. A viable architecture must support a full range of financial services while maintaining consistent privacy across all interactions.

Fourth, regulatory compatibility.

Institutional capital cannot operate outside regulatory frameworks. AML, KYC, sanctions compliance, and the Travel Rule are foundational requirements. A structural tension emerges here: AML requires traceability of fund origin and movement, whereas privacy seeks to limit external visibility of transaction data. Institutional demand, therefore, centers on privacy that coexists with regulation rather than circumvents it. Transaction details should remain hidden at the market level, while enabling user-specific auditability under legitimate legal requests and enforcing controls over sanctioned interactions.

An institutional-grade privacy blockchain is not simply “the most anonymous chain”; it is an execution layer that satisfies traceability resistance, liquidity, financial functionality, and regulatory compatibility in tandem. Only under these conditions can institutions realistically consider active onchain asset management. The next section evaluates how Starknet aligns structurally with these requirements.

2-2. Structural Analysis: How Starknet Satisfies These Requirements

As outlined above, the four core conditions an institutional-grade privacy blockchain must satisfy are as follows:

1. Resistance to traceability
2. Sufficient liquidity
3. Essential financial services
4. Regulatory compatibility

The four conditions are not merely ideal benchmarks; they function as practical criteria for structurally distinguishing privacy projects in the current market. Most projects demonstrate strength in specific areas, while architectures that satisfy all four conditions simultaneously remain rare. Rather than listing individual technical features, the analysis below focuses on structural limitations across each requirement and evaluates how Starknet addresses them.

(1) Resistance to traceability

Institutional concern extends beyond simple asset visibility to whether asset flows can be reconstructed into identifiable operating strategies and traced accordingly.

Public blockchains such as Solana and Sui have introduced privacy-oriented features. Solana provides functionality that encrypts transaction amounts and balances, while maintaining publicly visible addresses and transaction graphs. As a result, although value can be obscured, it remains possible to trace which addresses interact with which protocols and how the activity patterns of specific addresses are formed.

Sui focuses on preventing direct linkage between offchain identity and onchain addresses. The approach is designed to protect the connection between real-world identity or Web2 accounts and blockchain addresses. However, asset flows and activity records onchain remain publicly observable. Identity is protected, but behavior itself remains traceable.

Both approaches represent meaningful progress in protecting either value or identity. At the same time, neither provides a structure that fundamentally prevents the reconstruction of operational flow itself.

Starknet takes a different approach. Assets are managed as encrypted units through the note model, while the paymaster structure reduces direct exposure of the transaction sender. As a result, individual transactions do not provide sufficient information to directly identify overall asset flow or the controlling entity behind it.

Not all information is fully hidden. In DeFi interactions such as swaps, Starknet adopts an anonymous interaction model in which user identity is concealed, while transaction amounts and token types remain publicly visible.

The key distinction lies not in making all information private, but in preventing individual transactions from being linked into a coherent strategy. Transactions remain observable at the surface level; however, reconstructing them into a unified flow or attributing them to a specific entity becomes structurally difficult.

Starknet’s privacy model, therefore, is not designed to hide all data, but to break linkability between transaction actors and strategic behavior. This approach preserves public liquidity and price discovery while structurally limiting exposure of institutional strategies.

(2) Sufficient liquidity

Market depth is a fundamental requirement for institutional execution. Even with strong privacy guarantees, shallow liquidity constrains strategy execution. This becomes especially critical in institutional contexts, where large-scale asset movements require sufficient depth to be absorbed without significant market impact.

Aztec aims to support both public and private smart contracts as a privacy-focused L2. However, despite its mainnet launch in November 2025 and token launch in February 2026, the ecosystem remains at an early stage. At present, no DEXs or DeFi protocols are actively deployed on mainnet, and meaningful trading activity has yet to emerge. Regardless of its privacy capabilities, forming sufficient market depth to support institutional-scale operations is likely to require considerable time.

Source: DefiLlama

Starknet presents a different structural approach. Operating as a public execution layer for more than four years, it already supports a diverse set of DeFi protocols and established liquidity. Rather than constructing isolated private liquidity pools, Starknet integrates privacy directly into the existing public DeFi ecosystem.

This approach does not attempt to recreate liquidity from scratch. Instead, it leverages existing market depth while enhancing privacy, aligning more closely with institutional requirements. Privacy is introduced without compromising access to liquidity.

(3) Essential financial services

Institutional participation is defined by active capital deployment rather than simple transfers. Staking, lending, derivatives, and liquidity provision must function as part of an integrated financial system.

Zcash and Monero are optimized for private transfers. Their architectures are designed around private payment networks and do not support smart contract-based execution environments. As a result, complex DeFi primitives such as AMMs, lending markets, and derivatives are difficult to implement onchain. In practice, no meaningful DeFi ecosystem has developed on top of these networks. While both can function as private payment tools, they do not provide execution environments suitable for institutional financial activity.

Aztec aims to enable private smart contract execution, making DeFi theoretically possible. However, no live DEXs or major DeFi protocols are meaningfully active on mainnet. Ecosystem maturity remains insufficient to support institutional-scale operations.

Starknet integrates privacy into a public execution layer where DeFi is already actively functioning. Financial functionality is not rebuilt from the ground up; instead, privacy is layered on top of existing infrastructure. The network has been operating for several years, maintains approximately $250M in TVL, and supports an ecosystem where real asset management activity is taking place.

Source: DefiLlama

Core DeFi components, including lending protocols, decentralized exchanges, liquidity provision models, and derivatives infrastructure, are already implemented. Privacy is introduced within an environment where financial infrastructure is already operational, rather than within an isolated or experimental setting. From an institutional perspective, this distinction is critical. Starknet is not simply a chain where privacy has been implemented; it is a chain where execution is already possible, with privacy added on top.

(4) Regulatory compatibility

Zcash and Monero provide strong transfer privacy, but their coexistence with regulatory frameworks has remained a persistent challenge. Monero processes transactions privately by default, making it difficult to trace the origin and movement of funds. As a result, it has faced exchange delistings, and in some cases has been classified as a higher-risk asset from an AML and sanctions compliance perspective.

Zcash supports selective use of shielded transactions and includes viewing key-based disclosure mechanisms. This introduces elements of regulatory compatibility. However, in practice, usage of shielded transactions has often remained limited, and privacy functionality has not been widely adopted at scale. Regulatory authorities continue to raise concerns regarding traceability. Although a selective disclosure model exists at the technical level, cases of structural integration with institutional financial infrastructure remain limited.

Starknet incorporates compliance considerations directly at the architectural level. A user-level selective disclosure model based on Viewing Keys is combined with wallet-level screening mechanisms. Privacy is maintained as the default, while user-specific auditing becomes possible under legitimate legal requests. The model does not attempt to circumvent regulation. Instead, it is designed to coexist with regulatory requirements, balancing strategy protection with compliance.

 

3. Starknet Privacy Architecture

As established earlier, an institutional-grade privacy blockchain is not defined by stronger anonymity alone. It must preserve liquidity and financial functionality while protecting operational strategy. Starknet’s privacy model is designed precisely to meet these conditions. Its architecture is built around three core components: the note model, client-side execution, and a compliance framework capable of coexisting with regulatory systems.

3-1. Note-Based Asset Model

In conventional public blockchains, the balance of a specific address is directly recorded in the global state. When a transaction occurs, the system updates state by decreasing one address balance and increasing another. Under this structure, both address relationships and asset flow are fully exposed, making it possible to trace who sent how much to whom using only onchain data. In effect, the blockchain functions as a publicly accumulated ledger of asset transfers between addresses.

Starknet’s privacy architecture departs from this model. Assets are not represented as balances tied to addresses; instead, they exist as discrete units referred to as “notes.” Each note contains information such as ownership, asset type, and amount, but all such data is recorded onchain in encrypted form. External observers cannot directly determine ownership or value from the note itself.

Transactions within the note model do not modify balances. Execution occurs through the consumption of existing notes and the creation of new ones. Consuming a note does not imply deletion; rather, it involves computing a corresponding nullifier and registering it onchain. A nullifier is a deterministically derived value associated with a specific note, and the chain verifies only whether that value has been previously used. Once registered, a nullifier cannot be reused, making double-spending structurally impossible.

Consider a transfer in which A sends 1 ETH to B. A first deposits 1 ETH into the privacy pool, generating a note representing that amount. To transfer funds, A selects this note as the input to be consumed. During execution, the corresponding nullifier is computed and included in the transaction, while a new note representing 1 ETH with B as the owner is created.

Upon submission, the chain verifies that the nullifier has not been previously registered. If valid, the nullifier is recorded, marking the original note as spent, and the newly created encrypted note is added to state. The entire process is validated via zk-proof. Verification is limited to three conditions: consistency of input and output amounts, legitimacy of ownership, and non-reuse of the nullifier. The chain does not re-execute the transaction logic itself.

As a result, the only data recorded onchain consists of the nullifier, the newly created encrypted note, and the proof attesting to transaction validity. No explicit information such as “A sent 1 ETH to B” is stored. Instead, the system records only that a note has been consumed once and a corresponding new note has been created. This abstraction fundamentally disrupts address-based balance tracking and prevents direct reconstruction of asset flows.

3-2. Client-Side Execution Architecture

Another defining characteristic of Starknet Privacy lies in its transaction execution architecture. Private transactions do not follow a model in which all computation is performed onchain. Core state transition logic and proof generation are executed offchain first, while only minimal verification data is submitted onchain.

Under this design, the role of the blockchain shifts from a computation layer to a verification layer. All transaction-level operations—including note selection, note merging and splitting, nullifier generation, and balance preservation checks—are executed offchain by the user’s wallet or a designated operator. Starknet subsequently verifies, via zk-proofs, that the offchain execution complies with protocol rules. No re-execution of transaction logic occurs onchain; validation is limited to correctness of the resulting state transition.

Execution in private transactions is therefore divided into two distinct stages. The first stage computes the new state offchain; the second stage verifies, onchain, that the computation is valid through cryptographic proof. Rather than directly executing transaction logic, the chain verifies a mathematical proof attesting to its correctness.

The transaction flow can be simplified as follows:

1. The user initiates a transaction through their wallet.
2. The wallet (or operator) executes the transaction offchain, selecting input notes, determining output notes, and computing the resulting state transition.
3. A nullifier is generated for each consumed note, and a zk-proof is constructed to demonstrate that the transition satisfies protocol constraints.
4. The transaction submitted onchain includes only the nullifier, newly created encrypted notes, and the zk-proof.
5. Starknet verifies the zk-proof without re-executing the transaction and records the updated state.

Two implications follow from this architecture.

First, information exposure during execution is minimized. Offchain computation prevents intermediate states and strategic intent from being recorded onchain. Verification is restricted to a single question: whether the proposed state transition satisfies protocol rules.

Second, compatibility with the public execution environment is preserved. Starknet does not modify its consensus mechanism or base execution model. Privacy is introduced as a layered extension on top of the existing execution layer. As a result, connectivity with public DeFi infrastructure is maintained while transaction-level detail remains protected.

From an institutional perspective, this property is particularly important. Liquidity does not need to be fragmented into a separate private network, while strategy and position flow remain protected. Execution continues to occur within the public market, yet the identity of participants and the internal structure of their transactions remain concealed.

3-3. Compliance Framework and Selective Disclosure

For institutional adoption of privacy infrastructure, the primary requirement is not anonymity itself, but the ability to coexist with regulatory frameworks. Fully anonymized systems can offer strong privacy at a technical level; however, they face structural limitations in satisfying requirements such as AML, auditability, and responsiveness to legal requests within institutional finance. Starknet Privacy is designed with these constraints in mind. Baseline transaction privacy is preserved, while a selective disclosure mechanism enables limited reconstruction of transaction history when required.

1) Viewing Keys

Each user in Starknet Privacy is associated with a unique Viewing Key. This key allows users to decrypt their own private transaction history and corresponding notes. The Viewing Key does not function as a global access key; it is a user-specific decryption key limited to data associated with a single account.

A critical property of this design lies in user-level isolation of privacy. Disclosure of one user’s Viewing Key does not compromise the privacy of others. No centralized authority exists with the ability to decrypt the entire network state.

2) Auditing Entity

Starknet Privacy introduces an auditing mechanism through the Auditing Entity. The design enables reconstruction of transaction flow on a per-user basis in response to legitimate regulatory requests, without exposing broader network activity.

When a user enters the privacy pool, their Viewing Key is registered onchain in encrypted form using the public key of the Auditing Entity. The encrypted data remains inaccessible under normal conditions and can only be recovered through a defined process triggered by a valid legal request.

Under such conditions, the Auditing Entity can reconstruct transaction flows associated with the specific user. Asset movements can be traced both forward and backward; however, access remains strictly scoped to that user. Continuous or global visibility into all transactions is not enabled under this model.

The architecture therefore occupies an intermediate position between full transparency and complete anonymity. From an institutional perspective, this positioning is a critical differentiator. Fully anonymous systems introduce regulatory risk, whereas Starknet Privacy explicitly incorporates controlled disclosure pathways at the user level, enabling compatibility with regulated financial environments.

3) Wallet-Level Screening

Regulatory compatibility is further supported at the wallet layer in addition to the protocol layer. According to the design, wallets can integrate blockchain analytics providers such as Elliptic, TRM Labs, and Chainalysis to pre-screen deposit and withdrawal addresses.

This enables enforcement of policies such as blocking blacklisted addresses, restricting inflows from sanctioned entities, and identifying high-risk counterparties at the wallet level. Enforcement is not imposed as protocol-level censorship. Instead, compliance policies are implemented by wallets or service providers, allowing flexibility across different regulatory contexts.

The overall structure establishes a balance between privacy and compliance. Transaction-level detail and strategic activity remain protected, while auditability and regulatory response are preserved within a controlled scope. This balance defines Starknet Privacy not as an anonymous network, but as a privacy infrastructure designed for institutional participation.

 

4. Phased Privacy Rollout and STRKBTC

Starknet’s privacy model is structured as a phased roadmap rather than a single-step implementation. Privacy is not a feature that can be completed in isolation; it requires coordinated development across protocol infrastructure, wallet architecture, compliance mechanisms, and real-world usage environments. The roadmap therefore reflects not only technical maturity, but also ecosystem readiness and practical deployment scenarios, positioning it as a staged expansion strategy.

Phase 1: Private Asset Custody and Transfers

The first phase focuses on establishing foundational infrastructure for storing and transferring assets within a privacy environment. Asset flows are organized around a privacy pool: users deposit public tokens into the pool (private deposit), transfer assets within a private state (private transfer), and convert them back into public tokens when required (private withdrawal). Multi-asset private balance management further enables multiple assets to be held and managed simultaneously within a unified privacy environment.

The objective at this stage is to reliably implement the minimum viable infrastructure for secure asset custody and transfer under privacy conditions. Prior to enabling complex financial activity, the system establishes an environment where strategic asset movement and position adjustments cannot be easily reconstructed externally. From an institutional perspective, this forms the baseline requirement for shielding large-scale transfers and internal portfolio rebalancing from market visibility.

Phase 2: Expansion to Anonymous DeFi

The next phase extends privacy beyond asset transfers into financial interactions. The key design choice is not fully private DeFi, but an anonymous interaction model in which user identity is concealed while transaction amounts and asset types remain visible. This preserves market functions such as price discovery and liquidity while protecting the identity of participants and the linkage between transactions and strategy.

Integration occurs at the execution layer rather than through the creation of isolated private markets. Privacy is layered onto existing public DeFi infrastructure; liquidity is not rebuilt, but leveraged. Exposure of transaction actors and strategy is minimized without fragmenting the underlying market.

The architecture further incorporates atomic multi-call functionality, allowing multiple DeFi interactions to be executed within a single transaction. Complex strategies—such as swaps, deposits, and lending—can be processed as a unified execution flow, reducing the risk of intent leakage across intermediate steps.

STRKBTC

STRKBTC is the first asset introduced within this privacy roadmap. It represents BTC within the Starknet ecosystem and carries significance beyond that of a simple wrapped token; it is the first Bitcoin-based asset designed for operation within a privacy-enabled execution environment. Bitcoin has established itself as a store of value based on strong trust and verifiability, yet its fully transparent transaction history, balances, and activity records introduce structural limitations. From an institutional perspective, this transparency can lead to position exposure and strategy leakage.

Bitcoin remains the core asset in an institution-driven BTCFi environment. Enabling BTC to operate within a privacy framework is therefore essential for preventing strategic asset movement and position adjustments from being externally traceable. STRKBTC serves as the initial bridge connecting Bitcoin to Starknet’s execution environment and privacy layer, marking the transition from passive custody to active onchain deployment.

Taken together, the shift toward institution-driven BTCFi is already supported by data. Within this context, strategy exposure represents a structural risk rather than a secondary concern. Starknet positions itself as an execution layer designed to address this challenge through its privacy model; the phased roadmap and STRKBTC represent the first step in translating that design into real-world operational environments.

 

5. Market Implications and the Future of BTCFi

The next phase of BTCFi extends beyond simply bringing Bitcoin onchain. Institutional capital requires more than liquidity and financial infrastructure; a privacy environment capable of preventing strategy exposure must also be established for onchain deployment to become viable.

Demand for such privacy has already emerged within the Bitcoin ecosystem. CoinJoin provides a representative example. Research analyzing Wasabi and Samourai indicates that approximately 227,480 BTC (around $4.7B) was processed through mixing between 2018 and early 2022, while cumulative mixing volume through Samourai Whirlpool is estimated to exceed 300,000 BTC. Even basic transaction-level privacy tools have demonstrated meaningful demand.

These figures, however, represent a lower bound rather than the full scale of the institutional private finance market. CoinJoin is limited to transfer-level privacy and does not extend to financial operations such as swaps, collateral movement, or portfolio rebalancing.

Institutional Bitcoin holdings are currently estimated at approximately 3.66M BTC, equivalent to roughly $256B based on a BTC price of $70,000. The implication is clear: BTCFi is not a marginal liquidity experiment, but a market grounded in a substantial underlying asset base.

Assuming that 10% of these assets are reallocated within a privacy environment twice annually, annual private transaction flow could reach approximately $50B. The estimate reflects an expanded market that goes beyond transfer-level privacy and incorporates active asset management.

Applying a privacy-enabled onchain transaction fee of 0.1–0.3% yields an estimated annual revenue range of $50M to $150M. Even partial migration of institutional capital into privacy-enabled environments would be sufficient to establish a meaningful financial market.

Within this context, Starknet’s approach is notable. The objective is not to construct an isolated privacy chain, but to build an execution layer that preserves public DeFi liquidity while enabling strategy protection. The note-based asset model, combined with selective disclosure within the compliance framework, reflects a design that simultaneously addresses both privacy and regulatory compatibility.

Competition in BTCFi is therefore not defined by scalability alone. The defining question is whether an environment exists in which institutions can actively deploy and manage capital. Privacy is unlikely to remain optional; it is positioned to become a foundational component of BTCFi infrastructure. Starknet’s privacy roadmap and STRKBTC illustrate a concrete direction in which institutional finance and onchain infrastructure converge.