Search

Search for projects by name or address

Privacy

STRK-20 logo
STRK-20

Real-time monitoring for this project is not supported.

About

A privacy pool on Starknet for arbitrary-amount private transfers and DeFi actions, using Cairo execution proofs and auditor-accessible compliance data.


  • Total Value Locked
    $838.73 Kacross 7 assets and 7 buckets
  • TVL
    $838.73 K
  • Assets tracked
    7
  • Buckets tracked
    7
  • Deposits 7D
    190
  • Deposits 30D
    594
  • Deposits Total
    15.79 K
  • Trusted setup
  • Exit window
  • Privacy
  • Reproducibility
  • Attributes
    ZKTransfersDeFiAny amount

  • About

    A privacy pool on Starknet for arbitrary-amount private transfers and DeFi actions, using Cairo execution proofs and auditor-accessible compliance data.

    STRK-20 is a privacy pool deployed as a smart contract on starknet. It uses a UTXO-style note model: users deposit ERC20 tokens into the pool, create encrypted notes, spend notes by publishing nullifiers, and withdraw to public Starknet addresses.

    The pool contract source code was reviewed for this entry. Other parts of the protocol stack are open source in the starknet-privacy repository — the Cairo pool contract, TypeScript SDK, discovery service, audit reports, and Lean formal verification — and StarkWare published instructions to run a local transaction prover. Users can therefore audit what is actually proven and generate ZK proofs themselves without revealing private data to the proving service run by Starkware, although proving is compute-intensive (a ~48 vCPU / 96 GB machine is recommended).

    Note that the proven (L1-verified) Starknet OS only checks that submitted proof facts are well-formed, reference a real recent block, and claim an allowlisted virtual OS program hash — the client’s STARK proof itself is verified by the permissioned Starknet sequencer before transaction inclusion and is not re-verified on L2 or L1. As a consequence, the protocol would accept forged withdrawals from the Sequencer as valid.

    Privacy considerations

    The protocol supports private transfers, arbitrary amounts, partial withdrawals through private change notes, and DeFi actions through external helper contracts. DeFi integrations use open notes: the pool creates a note whose final amount is filled after an external helper, such as a swap or lending adapter, measures the onchain output.

    Fees

    The pool currently charges a flat fee of 4 STRK plus gas for any action that uses the privacy pool, including deposits, swaps, and withdrawals.

    Compliance

    The compliance model relies on an ‘auditor’ public key. Users register an encrypted private viewing key, but all ‘private’ actions must include auditor-encrypted metadata. Whoever controls the auditor private key can decrypt user metadata offchain from onchain-emitted cyphertexts; this does not grant spending authority, but it can centrally remove any user’s privacy, even retroactively.

    Anonymity set

    The anonymity set, in the best case, corresponds to the set of all users of the privacy pool. But metadata leaks and the centralized auditor reduce the anonymity set in practice.

    STRK-20 stores notes onchain in encrypted channels organized by recipient, sender, and token. Instead of scanning all pool activity, the wallet currently sends its Starknet account address and private viewing key to a discovery service, which reads the relevant contract storage, decrypts channels and notes, checks public nullifiers, and returns the user’s unspent notes.

    A third-party discovery operator therefore receives the private viewing key and can see the user’s counterparties, tokens, amounts, note history, and which notes remain unspent, together with sync timing and normally the user’s IP address. Oblivious HTTP can separate the IP address from the request content unless the relay and operator collude, but it does not hide note data from the operator. The discovery service is open source, so users can avoid this disclosure by running it themselves against their own or a trusted Starknet RPC node.

    • A third-party discovery service retains the supplied viewing key or decrypted results, revealing the user's private transfer history and unspent notes.

    2026 Apr 21 — Aug 23

    2026 Apr 21 — Aug 23

    Asset
    Deposits 7D
    Deposits 30D
    Deposits Total
    Value Locked
    XSTRKXSTRK
    0
    $0.00
    1
    $80.50
    11
    $16.28 K
    $285.72 K
    USDCUSDC
    39
    $15.42 K
    224
    $61.31 K
    5.97 K
    $618.67 K
    $255.96 K
    ETHETH
    4
    $16.41 K
    20
    $59.51 K
    159
    $180.06 K
    $113.97 K
    WBTCWBTC
    1
    $119.79
    11
    $6.91 K
    67
    $68.35 K
    $84.09 K
    STRKSTRK
    140
    $31.07 K
    317
    $309.96 K
    8.34 K
    $1.12 M
    $60.51 K
    strkBTCstrkBTC
    6
    $105.59
    21
    $17.98 K
    1.23 K
    $421.52 K
    $28.12 K
    USDTUSDT
    0
    $0.00
    0
    $0.00
    10
    $15.14 K
    $10.33 K
    Total
    190
    $63.13 K
    594
    $455.76 K
    15.79 K
    $2.44 M
    $838.73 K

    Funds can be stolen if

    1. the proof system or virtual Starknet execution model is broken or backdoored, allowing invalid server actions to be applied.
    2. the Starknet sequencer includes a transaction with fabricated proof facts.
    3. the escrow smart contract is maliciously upgraded (no delay).
    4. an external DeFi helper or target protocol invoked by the user mishandles assets.

    Funds can be lost if

    1. a user loses the Starknet account key or private viewing key required to spend their notes.
    2. the pool is paused or upgraded in a way that prevents users from applying valid actions.

    Privacy can be lost if

    1. the auditor private key holder decrypts registered users’ viewing keys or withdrawal and metadata.
    2. a third-party-hosted prover or note discovery service leaks user secrets or metadata (both can be self-hosted).
    3. deposits, withdrawals, open-note fills, timing, unique amounts, or DeFi helper calldata make a user’s activity linkable.

    The pool uses StarkWare-style role components and an instantly upgradeable smart contract implementation.

    • APP_GOVERNOR can set the fee amount, fee collector, and proof validity window.
    • GOVERNANCE_ADMIN can grant governance and upgrade-governor roles.
    • SECURITY_ADMIN can grant pause, unpause, and auditor-key administration roles.
    • SECURITY_AGENT can pause the pool, if granted.
    • SECURITY_GOVERNOR can unpause the pool and change the auditor public key, if granted.
    • UPGRADE_GOVERNOR can approve and execute upgrades, if granted.
    • UPGRADE_AGENT can execute approved upgrades, if granted.

    The live role holders observed were:

    • APP_GOVERNOR: 0x2796da10aba2e1f445c38eba07e5a4393d6dab30d203d3432deb824e891619a (2/4 Multisig)
    • GOVERNANCE_ADMIN: 0x3103066e6c7037ba947ea9a7b5b8d110ae7f3d631fa5849435d0dc1fc5ef785 (EOA)
    • GOVERNANCE_ADMIN and SECURITY_ADMIN: 0x663cc699d9c51b7d4d434e06f5982692167546ce525d9155edb476ac9a117d6 (7/12 Multisig)

    Transparent setup

    Detailed description

    Transparent proving systems require no trusted setups and have no additional setup-related trust assumptions.