STRK20: An Institutional-Grade Privacy Framework

Table of Contents

1. Institutional-Grade BTCFi Strategy and the Need for STRK20

2. What STRK20 Changes: From the Account Model to the STRK20 Model

3. STRK20 Architecture and Transaction Flow

4. Starknet BTCFi Roadmap

5. Final Remarks: Key Challenges for Institutional Adoption

 

 

1. Institutional-Grade BTCFi Strategy and the Need for STRK20

Bitcoin is increasingly being reframed from a retail-oriented asset for “holding and transferring” into an institutional asset management vehicle, or BTCFi. Over the past several years, institutional bitcoin holdings have grown rapidly and expanded as a share of total holdings, suggesting that BTCFi’s next phase is more likely to be driven by institutional capital than by individual users. Xangle covered this trend and structural shift in detail in “BTCFi: From Retail to Institutions, from Institutions to Starknet".

For institutions, direct on-chain asset management turns blockchain transparency into a risk rather than a pure advantage. Position sizes, transaction timing, and asset movement paths become fully visible, creating exposure to attacks such as frontrunning or liquidation-triggering strategies. As on-chain analytics infrastructure continues to advance, the problem is becoming even more pronounced. Institutions therefore need an environment that can prevent strategy leakage.

Institutional demand centers not on simple anonymity, but on privacy capable of protecting strategic asset management. Four conditions must be satisfied at the same time: tracking resistance, sufficient liquidity, core financial services, and regulatory alignment. Existing privacy chains show strengths in some of these areas, but none of them fully satisfy all four conditions at once.

The current privacy landscape leaves a gap across these requirements. Solana and Sui offer sufficient liquidity and financial functionality, but they lack a structural mechanism for concealing transaction flows and activity patterns. Aztec is pursuing an architecture that combines privacy with smart contracts, but it remains at an early stage in terms of liquidity and ecosystem maturity. Zcash and Monero sit at the other end of the spectrum: they provide strong privacy, but are constrained by the lack of smart contract-based financial infrastructure. Xangle examined this comparison in greater detail in its previous research,“The Final Piece of BTCFi: Starknet Privacy".

https://x.com/Starknet/status/2031339399015804954

Starknet’s strategy is to integrate privacy without giving up existing public DeFi liquidity or execution environments. In March 2026, Starknet officially announced STRK20 as a framework that formalizes this direction. Rather than issuing a new token, STRK20 adds privacy functionality to existing assets. The same asset can therefore be used selectively in either a public or private state, laying the foundation for institution-led BTCFi expansion.

strkBTC serves as the first concrete implementation of that strategy. Announced on February 26, 2026, strkBTC is a wrapped bitcoin asset designed directly by Starknet to enable bitcoin usage on Starknet. The asset is also designed to allow users to choose between a public state and a private state when needed. When used in a public state, balances and transfer histories are visible on-chain, similar to a standard ERC-20 token. In shielded mode, or private mode, balances and transaction histories are not exposed externally. The design positions Bitcoin as more than a passive holding asset. It allows Bitcoin to function as a payment, collateral, and asset management instrument within DeFi, while reducing institutional concerns around position exposure and trading strategy leakage.

The discussion below centers on the STRK20 structure and examines, step by step, what changes it introduces compared with Starknet’s existing token model, how assets are actually managed and transacted, and which technical mechanisms make this possible. It also analyzes what this structure means from an institutional perspective and how it may expand going forward.

 

2. What STRK20 Changes: From the Account Model to the STRK20 Model

STRK20 is an approach designed to address the limitations that arise in existing ERC-20-based token architectures as privacy functionality is introduced. To understand its significance, it is necessary to first examine the constraints of ERC-20-based token models and then how STRK20 improves on them.

2-1. Limitations of Existing Token Models

Most blockchains today, including Starknet, operate on an account-based model built around ERC-20-style token standards. In this structure, each address maintains an explicit balance, and every transaction is recorded as a change to that balance. In other words, asset ownership and transfer history are directly reflected on-chain.

For example, when address A transfers 100 tokens to address B, the transaction is recorded on-chain along with the sender, recipient, transfer amount, and timing. Anyone can query this information, and not only individual transactions but also relationships between addresses become visible. In a transparent blockchain environment, tracking fund flows around a specific address can make it possible to infer information such as the following:

• Timing of position entry and liquidation
• Transfer paths between assets
• Types of dApps used
• Recurring counterparty addresses

In other words, under the existing blockchain structure, not only asset holdings but also broader activity, including transaction patterns and strategies, can be exposed.

While such transparency strengthens blockchain reliability, it also creates a structural constraint for institutional investors. When managing large-scale capital, external exposure of trading strategies or positions can increase market impact costs or lead to unfavorable outcomes caused by information asymmetry. As a result, the ERC-20-based Account model has been a key factor limiting institutional participation on-chain.

2-2. Core Concept of STRK20

In Starknet’s privacy architecture, assets are represented not as an “account balance,” but as encrypted notes. Each note contains information such as the owner, asset type, and amount. However, that information is not directly exposed on-chain and is instead stored in encrypted form.

Transactions are handled in the same way. Under the existing model, “who sent how much to whom” was recorded directly on the blockchain. In STRK20, however, transaction details such as the owner, asset type, and amount are not disclosed. Instead, the details of the transaction are stored inside encrypted notes, and external observers cannot directly inspect their contents. The network verifies only the validity of the relevant notes through zk-proofs, checking conditions such as whether the sum of inputs and outputs matches and whether there is no double-spend.

As a result, STRK20 presents a new type of token model: an asset whose specific transaction contents cannot be viewed, but whose validity can still be verified by anyone.

2-3. What Changes for Users and Institutions

The shift creates clearer structural differences from the user perspective, particularly for institutions.

First, the scale of asset holdings is not revealed. In existing blockchains, the asset size of a specific address is exposed directly. For institutions managing large amounts of capital, this creates a problem because their position size or risk exposure can be revealed externally. In STRK20, assets are managed in the form of encrypted notes, and external observers cannot determine the asset size of a specific address. As a result, the risk of exposing institutional positions and risk profiles to external parties can be reduced.

Second, transaction contents are not revealed. Under the existing model, not only “who sent how much to whom,” but also which protocols were used and how they were used could be tracked on-chain. As transaction flows accumulated, investment strategies, position movements, and even rebalancing timing could become exposed externally. In STRK20, the transaction details themselves are not disclosed. Instead, only whether the transaction is valid is verified through a zk-proof. Conditions such as whether the sum of inputs and outputs matches and whether there is no double-spend are verified, while the actual transaction contents remain private. As a result, the structure verifies the validity of the transaction, not the contents of the transaction itself.

Third, STRK20 expands the scope of institutional on-chain usage. Previously, on-chain usage was limited because transparency could expose asset size and trading strategies to external observers. In DeFi environments in particular, transaction flows and position changes were visible as they occurred, creating disadvantages in competitive markets. For this reason, institutions have typically accessed on-chain markets indirectly and in a limited manner, either through products such as ETFs or through custodians and intermediaries, rather than participating directly on-chain. In STRK20, balances and transaction information are kept private, which helps alleviate these constraints. As a result, institutions can manage assets on-chain without intermediaries and without exposing their strategies. STRK20 therefore enables on-chain infrastructure to function as financial infrastructure capable of supporting real asset management.

 

3. STRK20 Architecture and Transaction Flow

The note-nullifier-based privacy model used by STRK20 was first fully articulated in the 2014 Zerocash paper. Zerocash proposed a model in which assets are represented not as public account balances, but as individual notes containing an owner, value, and nonce. Spent notes are then marked with nullifiers, preventing double-spending while hiding linkability between transactions. Notably, StarkWare co-founder Eli Ben-Sasson participated in the research as a co-author, highlighting StarkWare’s deep connection not only to the scalability lineage of zk-rollups, but also to the core technical lineage of zero-knowledge proof-based privacy design.

STRK20 also uses this note-nullifier-based structure as its underlying framework. However, while existing Zcash-style designs were effective for private transfers, they exposed several limitations when extended to on-chain financial environments. For example, users often had to scan large amounts of data themselves to locate their own assets. It was also difficult to connect with existing DeFi liquidity while preserving privacy, and these systems did not sufficiently provide the auditability and regulatory response capabilities required by institutions. Built on Starknet’s execution environment, STRK20 attempts to address these limitations by implementing privacy not merely as a transfer feature, but as an asset structure that can extend into DeFi and institutional use cases.

With that in mind, Sections 3-1 through 3-3 first examine the basic operating principles of STRK20. The discussion focuses on how assets are represented, what data is stored on-chain, and how transactions are generated and verified. Section 3-4 then examines what differentiates STRK20 from existing privacy projects. In particular, it looks at how STRK20 seeks to address practical implementation challenges such as asset discovery, auditability, and DeFi integration.

3-1. Core Architecture: Private State and Proof-Based Verification

The core of STRK20 lies in overturning the conventional assumption that the chain must have direct visibility into all transaction information in order to verify a transaction. Under the existing Account model, both state and execution take place on-chain. The balances and transaction histories of specific addresses are publicly recorded, and the chain directly executes transactions, verifies their outcomes, and then updates state. In other words, “who sent how much to whom” is visible by design, and the chain performs execution and verification together based on that information.

In STRK20, the structure changes fundamentally. Rather than being executed on-chain, a transaction is first constructed off-chain. Users construct transactions by consuming the notes they hold and creating new notes. A zk-proof attesting to the validity of the transaction is then generated. The proof verifies conditions such as whether the spent notes actually exist, whether the user is authorized to use those notes, whether the notes have not already been spent through nullifier verification, and whether the sum of inputs and outputs matches. Crucially, actual amounts and counterparty information are not disclosed during the process.

The user submits the zk-proof on-chain, and the chain verifies it. At that point, the chain does not re-execute the transaction. It only checks the validity of the proof. After verification is complete, state is updated by recording the nullifier associated with the spent note and adding the newly created encrypted note.

As a result, STRK20 shifts from the existing “public state + on-chain execution + on-chain verification” structure to a “private state + off-chain execution + on-chain verification” structure.

3-2. Asset Model: Notes Instead of Balances

In STRK20, the basic unit for representing assets shifts from a balance to a note. Under the existing Account model, the balance of a specific address is recorded directly, and when a transaction occurs, that balance increases or decreases. STRK20, by contrast, does not directly record how much a specific address holds. Instead, assets are represented as multiple encrypted notes, and state changes occur by consuming existing notes and creating new ones when transactions take place.

1)Note Structure

A note is an immutable object that represents an individual asset unit in STRK20. Each note represents ownership of a specific asset and generally contains the following information.

• Owner: the address authorized to use the note
• Token: the asset type, namely the token address of the asset
• Amount: the quantity held

However, this information is not directly disclosed on-chain. A note contains core transaction information such as the owner, asset type, and amount, but it is stored on-chain in encrypted form. As a result, external observers cannot directly determine who a specific note belongs to, what asset it contains, or what amount it represents.

2) Note Spending and Creation

In STRK20, a transaction does not modify an existing balance. Instead, an existing note is consumed, and new notes are created as a result.

For example, suppose A holds a single note containing 100 and transfers 60 of it to B. Under the existing Account model, A’s balance would decrease from 100 to 40, while B’s balance would increase by 60. In STRK20, however, the existing note containing 100 is not partially modified. It is fully consumed. As a result, a new note of 60 assigned to B and a new note of 40 returned to A are created.

In other words, asset movement in STRK20 is closer to “consuming existing asset units and replacing them with new asset units” than to “modifying balances.” In that sense, it resembles Bitcoin’s UTXO model. However, STRK20 differs from a standard UTXO model in that the owner and amount of each note are encrypted, and only the validity of the transaction is proven through a zk-proof.

3) Role of the Nullifier

A note-based structure creates one key problem: it must prevent an already spent note from being used again. The mechanism used for this purpose is the nullifier.

A nullifier is a value that indicates whether a specific note has already been consumed. When a user consumes a note, the nullifier corresponding to that note is recorded on-chain. If the same note is later used again, the same nullifier appears again, and the chain recognizes the note as already spent and rejects the transaction.

The key point is that a nullifier is only a marker used to prevent double-spending. It does not reveal the contents of the original note. External observers can see that a certain nullifier has been recorded, but they cannot know which owner’s note the nullifier came from, what asset and amount it represents, or which transaction it is linked to.

The nullifier therefore performs two roles at once. It prevents the same note from being used twice, while also avoiding exposure of the linkability between notes and transactions.

4) Privacy Pool State

STRK20’s on-chain state is managed through the Privacy Pool contract. In a typical blockchain, balances by address are stored as state. For example, address A may hold 100, while address B may hold 50. As a result, anyone can query a specific address and check that address’s asset size and transaction flows.

By contrast, STRK20’s Privacy Pool does not directly store “who has how much.” Instead, it primarily manages two types of information.

• Encrypted Note Set: A list of encrypted notes that currently exist. Each note contains the owner, asset type, and amount, but external observers cannot inspect its contents.
• Nullifier Set: A list of nullifiers corresponding to notes that have already been consumed. The chain uses this list to prevent the same note from being used again.

Ultimately, what the chain checks in STRK20 is not address-level balances. The chain verifies only whether a new encrypted note has been created, whether the nullifier of the consumed note has not already been used, and whether the submitted zk-proof is valid. As a result, the asset owner and amount are not disclosed externally, while only valid transactions can be processed without double-spending.

3-3. Transaction Flow: A Step-by-Step Example

In STRK20, transactions are not executed on-chain as they are under the existing model. Instead, they are first constructed off-chain and then verified on-chain. The process can be divided into five broad stages.

1) Deposit

The user first deposits a token in a public state, such as an ERC-20 token, into the Privacy Pool. During this process, an encrypted note representing the asset is created and stored inside the Privacy Pool. In other words, this is the stage where an asset in the form of a public balance is converted into a private note.

2) Private Transfer

The user selects a note they hold, consumes it, and simultaneously creates new notes. For example, when an asset is transferred using a single note, the original note can no longer be used. Instead, a new note for the recipient and another note corresponding to the remaining asset are created. During this process, a nullifier is also generated to prevent the note from being reused, thereby recording on-chain that the note has already been spent.

3) Generate zk-proof (Off-chain)

Based on the results of note consumption and note creation from the previous step, a zk-proof is generated to prove that the state transition was performed correctly. The proof demonstrates that the following conditions are satisfied without disclosing the transaction details.

• Whether the spent note actually exists
• Whether the user has the authority to use the note
• Whether the nullifier was calculated correctly, preventing double-spending
• Whether the sum of input and output values matches

4) Submit Transaction (Paymaster)

The generated zk-proof is submitted on-chain through a Paymaster. The Paymaster broadcasts the transaction and pays the gas cost on behalf of the user. As a result, the on-chain sender appears as the Paymaster rather than the actual user address, minimizing exposure of the user’s on-chain identifying information.

5) Verify and Update State

On-chain, the transaction is not executed directly. Instead, only the validity of the submitted zk-proof is verified. During this process, the chain checks the proof’s correctness and confirms whether the nullifier has already been used.

Once verification is complete, the on-chain state is updated as follows.

• The nullifier corresponding to the spent note is recorded, preventing double-spending
• The newly created encrypted note is added to the Privacy Pool

During this process, the chain does not decrypt or re-execute the transaction details. It applies only the minimal state updates based on the proof.

3-4. What Differentiates STRK20’s Privacy Architecture

The previous sections examined STRK20’s basic structure and how transactions are processed. At its core, STRK20 represents assets as encrypted notes, marks spent notes with nullifiers, and proves only transaction validity while keeping transaction details hidden. The design is closely aligned with the privacy model established by the Zerocash/Zcash lineage.

1) Note Discovery: Scalable Asset Discovery

One of the first challenges in a privacy system is how users locate their own assets. In a typical blockchain, users can simply query the balance of a specific address. In a privacy system, however, asset ownership information is not publicly disclosed. As a result, users cannot directly know which notes belong to them, making a separate discovery mechanism necessary.

In existing note-based privacy systems such as Zcash, users must scan all transaction outputs and attempt to decrypt them in order to identify notes sent to them. While this approach has the advantage of preserving strong privacy, it also comes with the limitation that discovery costs increase as network usage grows. In other words, regardless of a user’s actual activity level, the amount of data a wallet must process grows as the overall network scales.

To address this problem, STRK20 does not store notes randomly inside a single pool. Instead, it organizes them into a channel → subchannel → note structure. A Channel is a one-way connection from a specific sender to a recipient, while a Subchannel is the unit that separates notes by asset type within that channel. Notes, which represent the actual asset units, are stored sequentially within each subchannel.

With this structure, users do not need to scan the entire network. They can instead search for assets by focusing on the channels associated with them. The process begins with checking the list of channels connected to the user, then examining the subchannels within each channel, and finally identifying the notes contained in the relevant subchannel. As a result, the discovery scope is limited to the user’s own activity range rather than the total activity of the network.

In simplified terms, the difference can be expressed as follows:

• Existing privacy model: O(N) → proportional to the total number of network transactions
• STRK20: O(k) → proportional to the number of user-related transactions (k ≪ N)

For example, even if there are 10 million transactions on the network, a user who has actually interacted with only 100 transactions would still need to check all 10 million transactions under the existing structure. Under STRK20, the user would only need to search roughly those 100 relevant transactions.

STRK20’s Note Discovery therefore serves as a mechanism for improving wallet usability and scalability while preserving privacy. Beyond cryptographic privacy alone, it is a key differentiator that allows users to manage private assets in practice.

2) Viewing Key: Balancing Privacy and Auditability

For privacy to be used in real-world financial environments, simply hiding transaction information from external parties is not enough. Institutions and enterprises may not want to expose their positions, transaction flows, or counterparty information to the market, but they must still be able to respond to internal audits, accounting, tax reporting, and regulatory requests. In other words, privacy should not mean a structure where “no one can see anything.” It should be a structure where information remains private from general observers, while properly authorized parties can review a defined scope when necessary.

Existing privacy projects also provide some selective disclosure functionality, but their auditability models share similar limitations. For example, Zcash has the concept of viewing keys, allowing users to share their transaction history with a third party when needed. Aztec also uses a viewing-key-like mechanism to receive and decrypt private notes, allowing specific parties to view transaction information if users share their keys or if an application is separately designed to support such access. However, this approach only works when users directly provide their viewing keys, which makes auditing difficult if users do not cooperate. In other words, the viewing keys used by Zcash and Aztec are closer to tools that allow users to voluntarily disclose their transaction history than to foundational audit infrastructure for regulatory response.

STRK20 addresses this by incorporating Viewing Keys into a protocol-level compliance structure. When users enter the Privacy Pool, they generate a Viewing Key that can decrypt their transaction history, encrypt that key with the audit authority’s public key, and register it on-chain. Later, if there is a lawful request, the designated audit authority can decrypt the Viewing Key of a specific user and reconstruct that user’s transaction path.

However, this authority is not concentrated in a single entity. The audit authority capable of decrypting Viewing Keys can be designed as a committee composed of multiple members or as a threshold-based key management structure. To review the transaction history of a specific user, approval from a certain number of members would be required. In other words, the model does not allow a single administrator or institution to arbitrarily access a user’s transaction history. It is closer to a structure that grants limited access only through predefined procedures and approval conditions.

The key point is that this structure does not compromise the privacy of the entire network. Audits are limited to specific users, and even if one user’s Viewing Key is decrypted, other users’ transaction histories are not disclosed. STRK20’s Viewing Key is therefore better understood not as a “backdoor” to the entire blockchain, but as a mechanism that provides user-level selective transparency required in institutional and regulatory environments.

3) Open Note: Bridging Privacy with Public DeFi Liquidity

For privacy to become meaningful in on-chain finance, it must extend beyond simple transfers and interoperate with DeFi. Existing privacy models, however, have exposed limitations at precisely this point.

Zcash and Monero are chains specialized for private transfers. Since their designs are aimed at private payment networks, they do not support smart contract-based execution environments. As a result, complex DeFi structures such as AMMs, lending, and derivatives are difficult to implement on-chain, and in practice, there is almost no active DeFi ecosystem built on these chains. Consequently, Zcash and Monero can function as private payment instruments, but they are difficult to view as execution layers that provide the financial infrastructure institutions require.

Aztec seeks to address these limitations by combining privacy with smart contracts. Private smart contracts allow transaction execution itself to be processed privately, making it possible to implement DeFi logic such as swaps or lending within a privacy-preserving environment. However, this approach is closer to building separate applications and liquidity inside Aztec’s own privacy environment as a new chain, rather than directly using existing public DeFi liquidity such as Uniswap. As a result, privacy can be secured, but liquidity may become separated from the public DeFi market.

STRK20 takes a different approach to this problem. It is designed to protect user identity while preserving existing public DeFi liquidity, and Open Note is the mechanism that enables this.

An Open Note is a special type of Note introduced to process DeFi transactions where the output amount is difficult to determine in advance, such as AMM swaps. A standard encrypted Note must have its asset type and amount fixed at the time it is created. In an AMM swap, however, the final output amount can vary depending on the pool state, price, slippage, and immediately preceding transactions at the time of execution. For that reason, it is difficult for users to know in advance “exactly how much they will receive from the swap” when generating the proof, and a standard Note structure alone cannot naturally connect with a public AMM.

Open Note solves this problem by “first creating an empty Note and then filling it with the actual output after execution.” The user first consumes the existing Source Note and creates an empty Open Note to receive the resulting asset. The Source Token is then transferred to the Helper Contract, and the Helper Contract executes the swap on an existing public AMM. Once the swap is complete, the Destination Token actually received is deposited into the previously created Open Note. In other words, the structure allows the output determined at execution time to be filled into the Open Note without requiring the output amount to be fixed in advance.

The entire process is handled within a single atomic transaction. Source Note consumption, empty Open Note creation, withdrawal via the Helper Contract, AMM swap execution, and Open Note deposit are not executed as separate transactions. Instead, they are bundled into a single flow. If the swap fails at an intermediate stage or the required conditions are not met, the entire process fails together. Only when the process succeeds are the existing Note consumption and resulting Note deposit completed simultaneously.

However, an Open Note-based swap is not a fully private swap. Since it uses an existing public AMM directly, the asset being swapped, the swap amount, and changes in the AMM pool state can be observed on-chain. In other words, the Token and Amount may be public. Instead, STRK20 seeks to protect the identity of the user executing the transaction. External observers can see the swap amount and asset type, but they cannot easily determine which user’s private Note initiated the transaction.

Open Note therefore serves as a key mechanism that allows STRK20 to move beyond simple private transfers and connect with existing public DeFi liquidity. Although it does not provide full privacy, it presents a practical balance between privacy and DeFi usability by preserving the liquidity and price discovery functions of public AMMs while hiding user-identifying information.

 

4. Starknet BTCFi Roadmap

4-1. strkBTC and the Shinobi Upgrade: Applying Privacy to Real Assets

Privacy on Starknet is being built as part of a broader roadmap for institution-led BTCFi, not as a standalone feature. STRK20 emerged within this broader trajectory, while the core infrastructure required to apply the model to real assets is being developed alongside it.

strkBTC sits at the center of this roadmap. Announced on February 26, 2026, strkBTC is a wrapped bitcoin asset designed to make bitcoin usable on Starknet. More importantly, it is the first example designed not only to connect BTC to DeFi, but also to enable BTC to be used in a privacy-enabled form.

Existing wrapped BTC assets generally preserve full on-chain transparency. strkBTC takes a different approach by allowing users to choose between a public state and a private state when needed. In public mode, it operates like a standard ERC-20 token. In private mode, balances and transaction information are not exposed externally, while selective disclosure remains possible when necessary. The design aims to reduce the transaction exposure issues that arise when Bitcoin is used in a DeFi environment.

strkBTC currently operates through a federation-based multisig structure at its initial stage. Multiple independent institutions jointly operate a Bitcoin multisig and verify and sign transactions during the deposit and withdrawal process. Compared with existing wrapped BTC structures that rely on a single custodian or a small number of operators, the design aims to distribute trust assumptions and define them more clearly.

A privacy-enabled asset structure alone is not enough for the model to work in practice. The system also needs an execution environment that can verify transaction validity without revealing transaction contents. The Starknet “Shinobi” upgrade (v0.14.2) provides that foundation.

https://x.com/Starknet/status/2046232796625068334

Starknet’s existing zk-rollup architecture already executes transactions off-chain and submits the results in the form of proofs for verification. The limitation was that final proof verification took place on Ethereum (L1), which restricted the flexible use of proofs at the individual transaction level inside L2.

Shinobi expands this architecture by introducing in-protocol proof verification, allowing Starknet itself to verify proofs directly. When a user submits an off-chain-generated proof to L2, the network can verify it internally in real time. The upgrade therefore creates a more flexible execution structure where proofs can be processed at the transaction level, rather than only at the block level.

User-level proof verification is a key prerequisite for implementing privacy asset models such as STRK20. Privacy-based transactions require each user to generate a proof independently without revealing transaction contents, and that proof must be verifiable independently. By enabling this type of proof verification, Shinobi provides an environment where correctness can be guaranteed without exposing transaction details.

Shinobi provides the “execution structure capable of verifying privacy,” while strkBTC represents the “application of that structure to a real asset.” STRK20 serves as the token standard connecting the two, establishing the foundation for privacy assets to be issued and operated in practice.

4-2. Starknet’s Decentralization Roadmap: Toward Trust-Minimized BTCFi

https://www.starknet.io/roadmap/

STRK20 and strkBTC should be viewed as early-stage infrastructure on the path toward more fundamental decentralization, not as final-state designs. Starknet’s broader objective is to decentralize the network architecture over time, so that execution, proving, and verification can evolve into a model that no longer depends on a single entity.

Network-level decentralization will extend beyond the sequencer to include the proving layer itself. Under the current or earlier setup, specific actors have played important roles in transaction execution and proof generation. Going forward, those responsibilities are expected to be distributed across multiple participants, while verification becomes more independently operated. The intended outcome is a network with stronger censorship resistance and greater reliability.

strkBTC follows the same decentralization trajectory. Its current federation-based structure is an initial model with clearly defined trust assumptions, where multiple institutions manage assets through multisig. The approach is pragmatic because it reduces single-custody risk, but it still relies on trust in a specific set of participants.

The long-term roadmap for strkBTC points toward gradual trust minimization through BitVM- and OP_CAT-based verification mechanisms. The shift is not merely about distributing operating roles across more entities. It represents a move toward a structure where asset validity is guaranteed by code and verification mechanisms. The ultimate goal is to enable BTC ↔ strkBTC conversion without requiring trust in any specific operator.

https://x.com/StarkWareLtd/status/1813929304209723700

StarkWare has already demonstrated an important technical precedent for this direction. In 2024, it succeeded in verifying a ZK proof through a STARK verifier on the Bitcoin Signet testnet. The result is viewed as an early example showing that zk-based verification logic can also be implemented on Bitcoin. In other words, strkBTC’s long-term direction is to move beyond federation-based operation and implement a near-trustless BTC wrapping and redemption model within Bitcoin’s own verification structure.

A successful implementation of this roadmap would position Starknet as more than a conventional Layer 2. It would become an integrated execution environment that uses both Bitcoin and Ethereum as settlement layers. In such a model, assets could move between the two ecosystems in a trust-minimized manner, creating the foundation for more complex on-chain financial activities, including trading, collateralization, and liquidity provision.

 

5. Final Remarks: Key Challenges for Institutional Adoption

Technical implementation alone will not be enough for STRK20 to gain market relevance. For the structure to matter in practice, it must attract institutional capital and liquidity. The current phase still represents an early stage of infrastructure buildout, but meaningful initiatives are already underway in several areas.

First, there is the challenge of securing liquidity. A privacy structure cannot rely on simple transfer functionality alone. It must support real financial activities such as trading, collateralization, and payments. To achieve this, sufficient asset scale and liquidity are essential. Starknet is attempting to secure early liquidity through incentive programs such as BTCFi Season, while also laying the foundation for BTC-based liquidity inflows through the introduction of assets such as strkBTC. However, broader institutional capital inflows will require a more diverse asset base and deeper liquidity.

Second, there is regulatory and compliance alignment. Institutions must be able to explain the provenance of assets and transaction flows, while also responding to audit and reporting requirements. STRK20 seeks to meet these requirements through a Viewing Key-based selective disclosure structure. It is differentiated from existing privacy systems in that it includes a protocol-level structure capable of user-level auditing. However, how this structure will be interpreted and accepted across different regulatory environments remains an important variable.

Third, there is the shift in the trust model. strkBTC currently operates under a federation-based structure. While this is a pragmatic approach at the early stage, it is not a fully trustless structure. That said, strkBTC has adopted a multisig structure based on multiple institutions from the outset, reducing single-custodian risk. At the same time, its roadmap includes a transition toward BitVM- and OP_CAT-based structures, making the direction toward gradual trust minimization clear. Whether this transition can be implemented in practice will be a key factor for institutional adoption.

Resolving these challenges will likely take time. The key point, however, is that Starknet is not merely presenting the core requirements for institution-led BTCFi, such as liquidity, regulatory response, and trust structure, as abstract concepts. Instead, it is implementing them step by step through concrete protocol design and roadmap execution. The approach is not simply an expansion of functionality. It is closer to an attempt to redesign blockchain architecture around structural limitations that existing blockchains have not been able to solve. In particular, integrating privacy, verification, and asset management within a single structure is an essential condition for building an on-chain financial environment in which institutions can actually participate.

As liquidity and use cases expand, Starknet is likely to establish itself beyond a mere Layer 2 as a BTCFi execution layer where institutional capital can participate directly. From this perspective, the current changes should be understood not as the introduction of a simple feature, but as part of a broader structural shift toward institution-led on-chain finance.