Starknet Ships STRK20, Bringing Privacy to Arbitrary ERC-20 Tokens

Starknet, a layer-2 network built on Ethereum, put a token privacy standard into production on 9 June. The standard, called STRK20, brings confidential transfers to arbitrary ERC-20 tokens — the common Ethereum token format used by stablecoins, governance tokens and most other assets — rather than to a single purpose-built coin. According to Starknet's announcement, the system is live on mainnet and runs as a note-based privacy pool in which every private transfer is validated by a zero-knowledge proof, a piece of cryptography that shows a statement is true without revealing the data behind it. Starknet put the cost of a shielded transaction at roughly 4 STRK.

The Mechanics: Encrypted Notes Held in Contract Storage

A note-based system does not keep a public ledger of account balances the way an ordinary token contract does. Holdings are represented instead as discrete encrypted notes, each standing for an amount, which are consumed and re-created as value moves between parties. The zero-knowledge proof attached to each transfer is what convinces the network the operation was valid — that the notes being spent existed, that nothing was created out of nothing — without disclosing who sent what to whom. The design choice Starknet highlighted is where those notes are kept. Many privacy systems maintain a separate note-commitment tree, a dedicated structure holding short cryptographic fingerprints of every note, alongside the contract itself; STRK20 stores the encrypted notes directly in Starknet contract storage, with no such tree.

Starknet said the arrangement also supports efficient note discovery, meaning a recipient can locate the notes addressed to them without scanning the entire pool. Scanning is the usual overhead of private systems, since a wallet that cannot tell which notes are its own has to work through the whole pool to find out.

The Build: Cairo, the Stwo Prover and One Pool for Many Assets

Both the proof logic and the contract code were written in Cairo, Starknet's own programming language, and the proofs are produced by Stwo, the network's native prover — the software that generates the zero-knowledge proofs the chain then verifies. Starknet said the pool supports multiple assets at once, with double-spend protection so a note cannot be used twice, which means users of different tokens share the same anonymity set rather than each sitting in a thinly used pool of their own.

• Roughly 4 STRK per shielded transaction, according to Starknet.
• Cairo used across both the proof logic and the contract code.
• Stwo, Starknet's native prover, generates the transfer proofs.
• One pool holds multiple assets, with double-spend protection.
• Ready X and Xverse were the launch wallets.

The Ethereum Parallel: pERC-20 and Issuer-Side Compliance

Starknet also pointed to a parallel effort on Ethereum itself, pERC-20, which applies the same idea to tokens on the base layer. Under that scheme, tokens are held as encrypted notes that hide balances, transfer amounts and the counterparties involved, while the total supply of the token remains public — anyone can still verify how much of the asset exists, only the distribution is concealed. The proposal includes issuer-side compliance hooks, allowing the entity that issued a token to retain controls over how it moves. Eli Ben-Sasson framed the remaining obstacle as a matter of usability rather than cryptography: "The big problem of dealing with privacy is UX."

What Shipping Changes: A Live Standard Rather Than a Design Note

Token privacy has been described in papers and testnet deployments for years, so the distinction that matters here is that STRK20 is running on mainnet, with real assets, a stated per-transaction cost and named wallets carrying it. A proposal can defer the awkward parts — what a transfer costs, how long a wallet takes to find its own funds, which client software will implement it. A live standard has to answer them, and the roughly 4 STRK price tag and the note-discovery design are the first public answers on both counts. What remains open is adoption: whether issuers deploy under the standard, whether the shared pool attracts enough volume for the privacy set to be meaningful, and whether the compliance hooks sketched for pERC-20 satisfy the issuers who would rely on them.