A Look at Built-In Privacy on General-Purpose Chains

Key Takeaways

• Recently, Sui and Starknet each rolled out privacy features, Confidential Transfers and STRK20 respectively. Both chains put privacy front and center, but they made nearly opposite design choices on what to hide and who holds the authority to disclose.
• Starknet's STRK20 uses a shielded pool model that hides the sender, the recipient, and the amount, severing the transaction graph itself. Auditors are given only read access for tracing and cannot seize assets. Sui's Confidential Transfers, by contrast, hides only the amount while leaving the sender and recipient public, and it follows an issuer-centric structure in which the issuer holds the power to freeze, seize, and audit, all at the code level. Starknet set out to build user-sovereign privacy aimed at DeFi users who want to protect their assets, while Sui aimed for compliance-friendly privacy targeting stablecoin issuers and institutions that cannot give up compliance.
• Privacy is no longer the preserve of dedicated chains. It is becoming a standard feature of general-purpose L1s. As general-purpose chains begin to absorb privacy that is good enough to use, privacy-focused chains with only middling liquidity and technology are bound to lose ground. The space where they can survive will be the far ends of the spectrum that general-purpose chains struggle to reach by design, such as comprehensive privacy that also covers metadata and the network layer, or private computation.

0. Sui and Starknet Announce Privacy Features

On June 8 and 9, a day apart, Sui and Starknet each announced privacy features. Sui released a public beta of Confidential Transfers, and Starknet launched a privacy framework called STRK20 on its mainnet. Both put privacy front and center, but a look at their structures reveals nearly opposite designs in terms of what they aim to hide and where control sits. This piece compares the two and discusses what it means that general-purpose Layer 1 chains have recently begun building in privacy features.

1. Starknet STRK20: Bringing the Privacy Pool Into the Wallet

Source: Starknet

STRK20 is a privacy framework that can be applied to any ERC-20 asset on Starknet, and it adopts a note-based privacy pool structure. When an asset is shielded, it is deposited into the STRK20 privacy pool and represented as an encrypted note. From then on, private actions work by consuming existing notes and creating new ones. This is close to porting Zcash's UTXO-style shielded pool model onto Starknet's proving stack.

In a private transfer, an outside observer can see nothing about the sender, the recipient, the amount, or which private balance was used. Each transfer is verified with a zero-knowledge proof, which confirms only such facts as whether the consumed note exists, whether the sender owns it, and whether double-spending has occurred. This is a model that fully severs the transaction graph itself.

STRK20 is being rolled out to wallets first. It lets users shield assets with a single click in the Ready X and Xverse wallets, and shielded assets can immediately be used for private swaps and private transfers within the pool. A shielding transaction is priced at 4 STRK, roughly 0.12 dollars at current prices. DeFi protocols across the ecosystem have signaled support for shielded assets, including the lending protocol Vesu, the liquid staking protocol Endur, the decentralized exchange Ekubo, and the dark pool project Zylith.

In this way, Starknet chose to layer privacy as a feature on top of the assets and liquidity already in Starknet DeFi. The details of this design are laid out in a technical paper published by StarkWare's researchers. Unlike Sui, which opened up its contract code repository, STRK20 published a protocol specification as a paper rather than implementation code, so the discussion below works from the core structure the paper defines.

1.1. Notes and Nullifiers

In STRK20, assets exist in units of notes. When a note is spent, a nullifier is revealed as a marker that the note has been consumed, and the two values are produced in different ways.

The note_id points to where the note is stored, but the nullifier revealed when the note is spent additionally incorporates a private key k known only to the owner. As a result, outsiders cannot link a given nullifier to the note it spent, and even the sender who created the note cannot tell when that note was used.

1.2. Note Discovery and Compliance

In a privacy pool, the biggest challenge is how a recipient finds their own notes. Zcash requires checking every transaction in the pool one by one, so it slows down as the pool grows. STRK20, by contrast, has the sender store a note at a location derived from a secret shared with the recipient, so the recipient only needs to look for their own notes. This makes the discovery cost proportional to each account's own activity rather than to the entire pool. The trade-off is that the recipient's address is exposed on-chain once when sending to someone for the first time, so the fact of receiving cannot help but be revealed.

For regulatory compliance, STRK20 encrypts a user's viewing key with the auditor's public key at registration and stores it on-chain. The auditor can unlock a specific user's viewing key and trace that person's transaction history only when there is a legitimate regulatory request, and unrelated users are not affected. Because the auditor does not hold the signing key needed to move funds, it can trace activity but cannot freeze or seize assets.

1.3. Anonymous DeFi and Its Limits

STRK20 supports not only transfers inside the pool but also interactions with existing Starknet DeFi, though here it focuses on anonymity rather than confidentiality across the board. Since the trade size in an AMM swap affects the AMM's price, the amount cannot be hidden, so the choice was to conceal only identity. STRK20 therefore keeps the amount and the token in plaintext while hiding only the owner, which lets users perform anonymous swaps or staking from their existing accounts.

Also, depositing and withdrawing the same amount, or withdrawing right after a deposit, can link the two transactions, so STRK20 is less a mixer for quick in-and-out movement and closer to a design for users who park funds in the pool and transact inside it. The user's identity itself can be concealed through a structure in which a paymaster pays the fee and submits the transaction on their behalf.

2. Sui's Confidential Transfers: Confidentiality That Hides Only the Amount

Source: Sui

Unlike Starknet, Sui has explicitly drawn a line, saying that full anonymity does not solve the problem. In the blog post announcing the launch of Confidential Transfers, Sui argued that financial systems require auditability and the ability to intervene when necessary, and that what on-chain payments lack is not opacity but control.

In keeping with this, Sui built Confidential Transfers to hide only balances and transfer amounts. The sender and recipient remain public, and the asset issuer decides whether to enable confidential mode for its token and defines who can access sensitive data and under what conditions. Even with amounts kept private, exchanges can still receive the signals they need to process deposits and withdrawals, and analytics firms can continue to support monitoring and investigation workflows. What Sui is after is closer to balance confidentiality than anonymity, and it looks less like a privacy pool than a move of traditional finance's data access control model onto the chain.

The roster of partners makes it clearer who this feature is for. Sui is working with Bridge to explore confidential financial flows within the stablecoin ecosystem, and intelligence services such as TRM Labs and Merkle Science are reviewing with Sui how risk scoring, monitoring, and investigation can work within this model. Sui's Confidential Transfers therefore appears to be aimed more at stablecoin issuers, payment companies, and institutional treasury operators than at existing DeFi users.

Looking directly at the Move contracts in the implementation that Mysten Labs released confirms that Sui's Confidential Transfers is more institution-focused.

2.1. Account Structure

The core data structure, TokenAccount, makes the public and private boundary of Sui's model clear at a glance.

The code above shows that the only things encrypted are two EncryptedBalance values, active and pending. Because the account itself is an on-chain object derived from the user's address, who owns the account and who they sent to remain public information.

Two points stand out.

• The is_frozen flag is built into the account struct, so the freeze function is implemented at the protocol level.
• The verified_key_encryption field holds the user's viewing key encrypted with the auditors' public keys, so for a token whose issuer has set auditors, auditability is enforced from the moment an account is registered. A user can register an account only by proving with a zero-knowledge proof (KeyConsistencyProof) that their key has been correctly encrypted. This means compliance is enforced from the point of registration.

On top of this, whereas STRK20 uses a note-based pool and STARK proofs, Sui encrypts the balance itself with homomorphic encryption. The scheme it uses is Twisted ElGamal over Ristretto255, a design similar to Solana Token-2022's confidential transfer extension.

Thanks to additive homomorphism, where adding two ciphertexts coordinate by coordinate yields a ciphertext of the sum of the plaintexts, the contract can accumulate deposits without decrypting the balance.

2.2. The Issuer's Power to Intervene

The function that shows the issuer-centric nature of Sui's model most starkly is set_balance_by_issuer.

An issuer holding TreasuryCap<T> can bypass the homomorphic operations and directly overwrite the encrypted balance of any account. Sui states that this is meant for purposes such as court orders, recovery from lost keys, and clawing back fraud. Beyond this, through ManagementCap the issuer can designate who has freeze authority, rotate the auditor key set, and use set_policy to place each of the register, wrap, and unwrap steps behind its own contract, such as a KYC whitelist or a withdrawal delay. The repository in fact includes reference examples that implement whitelist-based registration and a throttler that imposes a mandatory waiting period on withdrawals. In short, this means that in Sui's Confidential Transfers the issuer defines every policy and holds the powers to freeze, seize, and audit, all at the code level.

3. How Starknet's and Sui's Privacy Designs Differ

The differences between the two designs can be summed up in two points.

1. What gets privacy: STRK20 hides the sender, the recipient, and the amount to cut off the transaction graph, while Sui hides only the amount and keeps the graph public. This is a difference in the strength of protection and, at the same time, a difference in how analyzable the activity is. In Sui's model, even without the amount, the relational information of who transacts with whom and how often remains intact. In the STRK20 model, by contrast, the relational information disappears as well, but the effectiveness of the privacy then depends on the size of the anonymity set participating in the pool.
2. Who controls disclosure: In STRK20 the user is private by default, and disclosure through a viewing key exists as an exceptional procedure. In Sui the issuer defines whether confidential mode is enabled and sets the access policy, and as seen above, it follows an issuer-centric structure where the issuer even holds freeze and seizure powers. The former starts from user sovereignty and attaches compliance as an exception, while the latter starts from compliance requirements and permits confidentiality within that scope.

This difference lines up exactly with each chain's positioning. For Starknet, privacy is a differentiating feature for its DeFi ecosystem. Recalling that Vitalik, earlier this year, named a focus on privacy as the first value L2s should pursue, STRK20 can be seen as the most direct response to that call.

For Sui, on the other hand, Confidential Transfers is an update directed at payment and stablecoin infrastructure. Sui appears to have built Confidential Transfers on the view that, for financial systems to move on-chain at scale, a chain must support the confidentiality, compliance, and interoperability requirements that financial activity already relies on.

4. What Built-In Privacy on L1 Chains Tells Us

STRK20 and Sui's Confidential Transfers are leading examples of privacy-related features starting to be built into major general-purpose L1 chains. And the two chains are each trying to claim two different markets that this feature can reach. Starknet targets DeFi users and traders who want to protect their own assets, while Sui targets issuers and institutions that cannot give up compliance.

This is hard to dismiss as Sui and Starknet simply jumping on a narrative, because Ethereum is moving in the same direction as well. In the Hegota upgrade cycle currently scheduled for the second half of 2026, three proposals related to privacy infrastructure are under discussion. These are EIP-8182, which would introduce a shared shielded pool managed directly by the protocol to unify the anonymity sets of fragmented privacy apps; EIP-8141, which would let privacy pools pay fees with the assets being withdrawn; and EIP-8250, which would introduce a keyed nonce for a shared sender-privacy design. EIP-8182 in particular is built on a UTXO structure and Groth16 zero-knowledge proofs, yet it deliberately leaves out admin keys, proxy contracts, and a pause function, making it a model tilted even further toward user sovereignty than STRK20. EIP-8182 is of course still at the draft stage and not confirmed for inclusion in Hegota, but the direction itself looks clear, given that the Ethereum Foundation's leadership has named compliant privacy, alongside fast finality, as a core priority for 2026.

Solana, if anything, was at the front of this trend. Back in April 2025, Solana launched Confidential Balances, an expansion of Token-2022's confidential transfer feature, presenting a model that uses homomorphic encryption and zero-knowledge proofs to hide transfer amounts, mint and burn quantities, and fees while still maintaining regulatory compliance. It is a structure in which the issuer designates an auditor key to allow decryption for compliance purposes, and PayPal's PYUSD has already adopted the extension on Solana.

To sum up the current state of things: Ethereum and Starknet are converging on a shielded pool model that cuts the transaction graph, while Solana and Sui are converging on an issuer-controlled confidentiality model that hides only the amount. Among the major general-purpose chains, privacy features are now trending toward becoming standard, and the point of differentiation is shifting from whether privacy is offered at all to differences in regulatory compliance and the degree of data sovereignty.

This situation is a double-edged signal for privacy-focused Layer 1s. The market is clearly responding strongly to the privacy narrative. Privacy-focused chains are drawing keen interest in the market right now, and capital is flowing in structurally as well. In Zcash's case, the Zcash Open Development Lab was established with a 25 million dollar investment led by Paradigm and a16z crypto. At the same time, as general-purpose chains begin to absorb privacy that is good enough as a built-in feature, privacy chains resting on middling liquidity and technology seem bound to decline quickly. If an ordinary user can shield assets instantly in their existing wallet without moving them, the incentive to migrate to a separate privacy chain is bound to fade. In the end, the place where privacy-focused chains can survive will be the areas that general-purpose chains struggle to provide by design, the far ends of the spectrum. These include full shielding as a default that also covers metadata and the network layer, private computation based on FHE or MPC.