STRK-20

STRK-20 lets the user shield any ERC-20 token on Starknet, send it privately to other users, use it in DeFi and withdraw it to any address. Senders, amounts and which deposit funds which withdrawal stay hidden inside the pool. Deposits, withdrawals, the first payment to each new contact and DeFi calls are public.

Users trust the holder of the auditor key, which can decrypt every user’s history, and the holder of the screener key, which approves deposits. Multisigs can upgrade the pool and the contract that owns every shadow account without delay. Leaving needs StarkWare’s sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs., which alone checks proofs and includes pool transactions.

Architecture

Each user registers a viewing key, which the pool stores encrypted to the auditor key. Payments travel over channels: the first payment to a contact opens one and names the recipient, later ones only add encrypted notes. A private transfer needs a registered recipient, and registering takes a transaction and fee from the recipient’s own account. A note holds an amount of one token, and spending it publishes a nullifier. DeFi actions use open notes, whose amount a helper contract fills after the swap or loan.

Flow

1. Register. The wallet publishes your viewing key, encrypted to the auditor key.
2. Deposit. The holder of the screener key signs off on your address, and the pool takes the tokens and creates a note. Address, token and amount are public.
3. Transfer. The wallet proves offchain that you may spend your notes and creates notes for the recipient. A paymaster submits the transaction and takes its fee from your notes.
4. Withdraw. The pool pays out to any address. Recipient, token and amount are public, and the withdrawing user is encrypted to the auditor key.

Shadow accounts

A shadow account is a contract the pool deploys for one user, app and index. The pool withdraws tokens to it, runs the app’s calls through it and moves the results back into the user’s notes. Shadow account addresses derive from the user’s viewing key, so whoever holds that key can find them. The anonymizer owns every shadow account and can move what it holds.

Keys

The user’s Starknet account signs every action, and their viewing key decrypts their notes. Ready’s servers create the viewing key for most accounts, while Xverse derives it from a wallet signature. Registration cannot be changed, so a leaked viewing key exposes the user’s history for good.

App

StarkWare lists Ready and Xverse as wallets, and both are closed source. Both send the user’s viewing key to their own servers, which run note discovery and proving and relay pool transactions. The SDK is open, and a custom clientSometimes labelled interchangeably as a “node”, they are tasked with processing transactions and managing the blockchains's state. They run the computations for each transaction according to the rollup's virtual machine and protocol rules. If comparing to Ethereum clients, these would be execution clients such as Geth, as opposed to consensus clients. on it can use its own prover (high hardware requirements), its own note discovery and an oblivious relay. Deposits still need the screening signature.

Compliance

Every deposit from a Starknet address needs a fresh signature from the pool’s screener key. The wallet’s proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. requests it from a screening service, which checks the address with Elliptic and serves only its credentialed partners. Governance sets a screening policy per helper contract. Five helpers are exempt, among them the CCTP bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge., so USDC bridged in from other chains skips screening. The auditor key is one public key in the pool’s storage. Who holds the screener and auditor private keys is not visible onchain, and governance can replace either key at once.

Fees

Every pool transaction pays a fixed STRK fee, which governance can change at any time, plus gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources.. Paymasters take their cost from the user’s notes.

Anonymity setIn privacy protocols, anonymity set denotes all users, to which a particular withdrawal could be plausibly attributed. Anonymity set depends on a particular withdrawal, the size of the anonymity set is a metric for level of user's privacy.

One pool holds every token, but each token forms its own set. Registered users are the upper bound.