# Payy Markdown version of https://l2beat.com/layer2s/projects/payy ## Summary **Warning:** The protocol was [exploited](https://x.com/PeckShieldAlert/status/2103041942405960096) on September 24, 2026. Do not deposit funds. **Warning:** Why is the project listed in others? There is no data availability bridge. Consequence: projects without a data availability bridge fully rely on single entities (the sequencer) to honestly rely available data roots on Ethereum. A malicious sequencer can collude with the proposer to finalize an unavailable state, which can cause loss of funds. Learn more about the [recategorisation](https://medium.com/l2beat/framework-update-l2-projects-recategorisation-5d43b0d1fe50). - Total Value Secured: $710.57 (0.00% compared to seven days ago; canonically bridged $710.57, natively minted $0.00, externally bridged $0.00; 0.00% with additional trust assumptions compared to the tokens involved and the Stage assigned to the project's canonical messaging bridge) - TVS by asset: Stablecoins $710.57 (100%) - Past day UOPS: No data - Type: Other - Purposes: Payments, Privacy - Host chain: Ethereum ### Risks - Sequencer failure: No mechanism (sentiment: bad) - State validation: Validity proofs (SN) (No execution delay; sentiment: good) - Data availability: External (sentiment: bad) - Exit window: None (sentiment: bad) - Proposer failure: Cannot withdraw (sentiment: bad) ### About Payy is a payments-focused ZK network for private stablecoin transfers, settled on Ethereum with aggregated validity proofs and validator signatures, while transaction data is kept offchain. ### Links - Website: https://payy.network - Docs: https://docs.payy.network - Explorer: https://payy.network/explorer - Repository: https://github.com/polybase/payy - Social: https://x.com/payy_link - Contracts explorer (Disco): https://disco.l2beat.com/ui/p/payy ### Badges - Application-specific chain: This project is built to operate a specific application - Custom DA solution: This project is using a custom DA solution - Privacy: This project supports private transactions natively ## Value Secured The interactive TVS charts are shown on [the HTML page](https://l2beat.com/layer2s/projects/payy#tvs). Token by token: [TVS breakdown](https://l2beat.com/layer2s/projects/payy/tvs-breakdown). - [TVS chart (JSON)](https://l2beat.com/api/scaling/tvs/payy) - [TVS breakdown by token (JSON)](https://l2beat.com/api/scaling/tvs/payy/breakdown) ## Onchain costs The section shows the operating costs that L2s pay to Ethereum. The interactive costs chart is shown on [the HTML page](https://l2beat.com/layer2s/projects/payy#onchain-costs). ### Tracked transactions #### State updates - functionCall: 2026-02-17 10:32 UTC - now; currently used; address: [0x367C1eAF14AA06b78ce76bd0243297de79d85270](https://etherscan.io/address/0x367C1eAF14AA06b78ce76bd0243297de79d85270); selector: 0xb8cdbd27; signature: `function verifyRollup(uint256 height, bytes32 verificationKeyHash, bytes aggrProof, bytes32[] publicInputs, bytes32 otherHashFromBlockHash, tuple(bytes32 r, bytes32 s, uint256 v)[] signatures)` ## Liveness This section shows how "live" the project's operators are by displaying how frequently they submit transactions of the selected type. It also highlights anomalies - significant deviations from their typical schedule. ### Potential ongoing anomaly - No state updates have been performed for the past 18d 16h (since 2026-09-24 09:30 UTC). These typically occur every 2h 2m on average. The interactive liveness chart is shown on [the HTML page](https://l2beat.com/layer2s/projects/payy#liveness). ### Tracked transactions #### State updates - functionCall: 2026-02-17 10:32 UTC - now; currently used; address: [0x367C1eAF14AA06b78ce76bd0243297de79d85270](https://etherscan.io/address/0x367C1eAF14AA06b78ce76bd0243297de79d85270); selector: 0xb8cdbd27; signature: `function verifyRollup(uint256 height, bytes32 verificationKeyHash, bytes aggrProof, bytes32[] publicInputs, bytes32 otherHashFromBlockHash, tuple(bytes32 r, bytes32 s, uint256 v)[] signatures)` ### Last 30 day anomalies All liveness anomalies detected for this project in the last 30 days, helping you review recent downtime and availability issues. - No state updates have been performed for the past 18d 16h (since 2026-09-24 09:30 UTC). These typically occur every 2h 2m on average. ## Milestones & Incidents - 2026-06-10 (incident): [Critical circuit vulnerability disclosed](https://github.com/polybase/payy/security/advisories/GHSA-fhxc-63vg-9gwr). An aggregation circuit bug allowed forged burn messages, was patched by the team. - 2026-02-19: [Payy Network is live on Ethereum](https://payy.network/blog/payy-network-is-live-on-ethereum). Payy launches its rollup on Ethereum, migrating from its previous deployment on Polygon. ## Risk summary ### Funds can be stolen if 1. the owner overwrites the state root or registers a malicious verifier, 2. a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL). ### Funds can be lost if 3. the external data becomes unavailable (CRITICAL). ### Funds can be frozen if 4. the operators fail to include withdrawals in state updates, as there is no forced exit mechanism. ### Users can be censored if 5. the operator refuses to include their transactions. ### MEV can be extracted if 6. the operator exploits their centralized position and frontruns user transactions. ## Risk analysis **Warning:** The protocol was [exploited](https://x.com/PeckShieldAlert/status/2103041942405960096) on September 24, 2026. Do not deposit funds. ### Sequencer failure No mechanism (sentiment: bad) There is no mechanism to have transactions be included if the sequencer is down or censoring. ### State validation Validity proofs (SN) (No execution delay; sentiment: good) SNARKs are succinct zero knowledge proofs that ensure state correctness, but require trusted setup. ### Data availability External (sentiment: bad) Proof construction and state derivation rely fully on data that is NOT published onchain. ### Exit window None (sentiment: bad) There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable. ### Proposer failure Cannot withdraw (sentiment: bad) Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen. ## Data availability ### Data is not stored on chain Transaction data and the private note tree are kept offchain by the Payy network. Only state roots and public deposit (mint) and withdrawal (burn) messages are posted to Ethereum with each state update. Although each update includes a data commitment hash, the onchain function intended to assert its availability on a DA layer (`verifyCommitHash()`) is an empty placeholder, so Ethereum does not verify data availability. While Payy has announced Celestia as its DA layer, the commitment format posted onchain cannot be linked to any Celestia blob, and no trace of Payy data on Celestia could be identified. **Risks** - Funds can be lost if the external data becomes unavailable (CRITICAL). **References** - [RollupV1.sol - empty verifyCommitHash() placeholder](https://etherscan.io/address/0x7d8837b547F4FEa0053571CB149e845FC58e9B2D#code) ## State validation Each state update submitted via `verifyRollup()` must include a ZK proof that is verified by the registered verifier contract, and signatures from more than 2/3 of the current validator set. The proof attests to the correct state transition of the private note tree, and public deposit (mint) and withdrawal (burn) messages are checked against the public inputs. ### ZK Circuits Payy transactions are proven with [Noir](https://noir-lang.org/) circuits: individual UTXO transaction proofs are recursively aggregated (`utxo` → `agg_utxo` → `agg_agg` → `agg_final`) into a single proof per state update. The circuits are published in the [payy repository](https://github.com/polybase/payy/tree/main/noir). The final proof is verified onchain by a Barretenberg-generated UltraHonk verifier. **References** - [HonkVerifier - Etherscan](https://etherscan.io/address/0x14DACD534ddc676601B27f41Eb541a7951524a2F#code) ### Verification Keys Generation The Rollup contract maps verification key hashes to verifier contracts. Each state update references one of the registered keys. The owner can add, replace and remove verifiers at any time without delay. **References** - [RollupV1.sol - addZkVerifier()](https://etherscan.io/address/0x7d8837b547F4FEa0053571CB149e845FC58e9B2D#code) ### State root proposals In addition to the validity proof, each state update requires signatures from more than 2/3 of the current validator set, which reflects finalization by the Solid BFT consensus of the Payy network. The current validator set registered onchain consists of a single address, making the effective threshold 1-of-1. ### Prover: [Barretenberg](https://l2beat.com/zk-catalog/barretenberg) #### Trusted setups - UltraHonk (Plonk): - Aztec Ignition, risk green (lowest risk) per the [Trusted Setups Risk Framework](https://forum.l2beat.com/t/the-trusted-setups-framework-for-zk-catalog/381): Aztec Ignition is a trusted setup ceremony that was run by Aztec for KZG commitment over BN254 curve in 2019. It included 176 participants and was publicly open for participation. - Onchain verifiers: [HonkVerifier](https://etherscan.io/address/0x14DACD534ddc676601B27f41Eb541a7951524a2F#code) (1 successful (verified by [L2BEAT](https://l2beat.com))) - Used in: [Payy](https://l2beat.com/privacy/projects/payy) - Verifiers: 1 successful (verified by [L2BEAT](https://l2beat.com)) ## Upgrades & Governance All privileged functions are ultimately controlled by the PayyMultisig (2/4). It owns the ProxyAdmin, which can instantly upgrade the Rollup proxy, and it is the owner of the Rollup contract, allowing it to manage provers, validators, ZK verifiers, supported tokens and burn substitutors, and to directly overwrite the state root via setRoot(). There is no timelock or exit window on any of these actions. ### Past upgrades The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included. - Count of upgrades: No upgrades - Last upgrade: N/A - Avg upgrade interval: N/A - 2026-02-17 10:32 UTC, deployment of [RollupV1](https://etherscan.io/address/0x367C1eAF14AA06b78ce76bd0243297de79d85270#code): transaction [0x8d002955fe594ded0ee57519c15a7c9dcf52e759be1fdd628eaf810dc2558abd](https://etherscan.io/tx/0x8d002955fe594ded0ee57519c15a7c9dcf52e759be1fdd628eaf810dc2558abd), implementations: [0x7d8837b547F4FEa0053571CB149e845FC58e9B2D](https://etherscan.io/address/0x7d8837b547F4FEa0053571CB149e845FC58e9B2D#code) ## Updates Each date links the update on the HTML page, which also shows its contract diffs. ### [2026-08-25 10:47 UTC](https://l2beat.com/layer2s/projects/payy?update=706e79b8) (4 changes) Discovery rerun on the same block number with only config-related changes. ## Operator ### The system has a centralized operator The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system. Payy blocks are produced by validators running the Solid BFT consensus protocol, and state updates are settled on Ethereum by a whitelisted prover. Onchain, the current validator set consists of a single address, and a single prover address has been whitelisted since initialization. **Risks** - MEV can be extracted if the operator exploits their centralized position and frontruns user transactions. **References** - [Payy docs - Rollup](https://docs.payy.network/payy-network/04_rollup) ### Users can't force any transaction There is no general mechanism to force the sequencer to include the transaction. Deposits (mints) can be made permissionlessly on Ethereum, but they only become spendable once the Payy network includes them in a proven state update. **Risks** - Users can be censored if the operator refuses to include their transactions. ## Withdrawals ### Regular exit Users can withdraw by burning notes on the Payy network. The burn is included as a public message in the next proven state update, upon which the Rollup contract transfers the escrowed tokens to the specified Ethereum address. Whitelisted burn substitutors can front withdrawals from their own funds before settlement and are refunded when the original burn is processed. There is no mechanism for users to exit independently of the operators. **Risks** - Funds can be frozen if the operators fail to include withdrawals in state updates, as there is no forced exit mechanism. ## Other considerations ### Confidential notes over a public spend graph Funds on Payy are represented as UTXO-like notes, and the chain state is a tree of note commitments. Each transaction proof hides the note contents (owner address, value, asset and entropy) but publishes the commitments of the two notes it consumes and the two it creates, and spending removes the input commitment from the tree. The deployed circuits do not use nullifiers, so anyone with Payy block data (served by the public node RPC and the explorer) can follow which commitments were spent into which, i.e. the transaction graph is public while its contents are not. Deposits to and withdrawals from the Ethereum escrow are public, and a withdrawal reveals asset, amount and Ethereum recipient onchain together with a burn hash that equals the first consumed note commitment, which anchors the withdrawal to a specific node in that graph. **References** - [noir/utxo - commitments are public inputs of the UTXO proof](https://github.com/polybase/payy/blob/main/noir/utxo/src/main.nr) - [Payy docs](https://docs.payy.network) ### Owner can overwrite the state root The Rollup contract owner can directly overwrite the current state root via `setRoot()` without providing a validity proof or validator signatures, and can replace the ZK verifier contracts referenced by state updates. **Risks** - Funds can be stolen if the owner overwrites the state root or registers a malicious verifier. ## Permissions Explore these contracts and permissions in Disco, L2BEAT's contract explorer: https://disco.l2beat.com/ui/p/payy ### Ethereum #### Actors ##### PayyMultisig Addresses: [0x230Dfb03F078B0d5E705F4624fCC915f3126B40f](https://etherscan.io/address/0x230Dfb03F078B0d5E705F4624fCC915f3126B40f) A Multisig with 2/4 threshold. - Can upgrade **with no delay** - RollupV1 [via: ProxyAdmin] - Can interact with RollupV1 - can manage provers, validators, ZK verifiers, supported tokens and burn substitutors, and can overwrite the current state root via setRoot() Participants (4): [0x54e22ad93DE7Dad5C83e9b1caC257F3aB384b02c](https://etherscan.io/address/0x54e22ad93DE7Dad5C83e9b1caC257F3aB384b02c), [0x111e5feA3D613EB866fd41B30c8257C930180428](https://etherscan.io/address/0x111e5feA3D613EB866fd41B30c8257C930180428), [0xCa1Df6eDf8adaCA00FC24DBD919578dD2e9EcBb6](https://etherscan.io/address/0xCa1Df6eDf8adaCA00FC24DBD919578dD2e9EcBb6), [0xAF657A8Fa036bcc99AC3cCd5b7fFa4AaddFBE501](https://etherscan.io/address/0xAF657A8Fa036bcc99AC3cCd5b7fFa4AaddFBE501) ##### EOA 1 Addresses: [0x41582701CB3117680687Df80bD5a2ca971bDA964](https://etherscan.io/address/0x41582701CB3117680687Df80bD5a2ca971bDA964) - Can interact with RollupV1 - can sign state updates as a validator. Signatures from more than 2/3 of the current validator set are required for each update ##### EOA 2 Addresses: [0x5343B904Bf837Befb2f5A256B0CD5fbF30503D38](https://etherscan.io/address/0x5343B904Bf837Befb2f5A256B0CD5fbF30503D38) - Can interact with RollupV1 - can submit state updates (new state roots) via verifyRollup(), providing an aggregated ZK proof and validator signatures ## Smart contracts Explore these contracts and permissions in Disco, L2BEAT's contract explorer: https://disco.l2beat.com/ui/p/payy ### Ethereum #### HonkVerifier Addresses: [0x14DACD534ddc676601B27f41Eb541a7951524a2F](https://etherscan.io/address/0x14DACD534ddc676601B27f41Eb541a7951524a2F#code) UltraHonk proof verifier generated with Aztec's Barretenberg from Payy's final aggregation Noir circuit. It verifies the aggregated validity proof of each state update submitted to the Rollup contract. #### RollupV1 (escrow) Addresses: [0x367C1eAF14AA06b78ce76bd0243297de79d85270](https://etherscan.io/address/0x367C1eAF14AA06b78ce76bd0243297de79d85270#code), [0x7d8837b547F4FEa0053571CB149e845FC58e9B2D](https://etherscan.io/address/0x7d8837b547F4FEa0053571CB149e845FC58e9B2D#code) (Implementation (Upgradable)), [0xfE455baCAF1968F1Ae6a322b8Ffbe56840e2f590](https://etherscan.io/address/0xfE455baCAF1968F1Ae6a322b8Ffbe56840e2f590#code) (Admin) **Past upgrades** (Count of upgrades: No upgrades, Last upgrade: N/A, Avg upgrade interval: N/A) - 2026-02-17 10:32 UTC, deployment of [RollupV1](https://etherscan.io/address/0x367C1eAF14AA06b78ce76bd0243297de79d85270#code): transaction [0x8d002955fe594ded0ee57519c15a7c9dcf52e759be1fdd628eaf810dc2558abd](https://etherscan.io/tx/0x8d002955fe594ded0ee57519c15a7c9dcf52e759be1fdd628eaf810dc2558abd), implementations: [0x7d8837b547F4FEa0053571CB149e845FC58e9B2D](https://etherscan.io/address/0x7d8837b547F4FEa0053571CB149e845FC58e9B2D#code) Main contract of the Payy ZK rollup. It stores the state root, escrows USDC backing the notes on the rollup, processes deposits (mints) and withdrawals (burns), and accepts state updates that must include an aggregated ZK proof and signatures from more than 2/3 of the current validator set. - Roles: - **admin**: ProxyAdmin; ultimately PayyMultisig - **getValidatorSets**: EOA 1 - **initialProver**: EOA 2 - **owner**: PayyMultisig All supported tokens in this escrow are included in the value secured calculation. Can be upgraded by: PayyMultisig with no delay #### ProxyAdmin Addresses: [0xfE455baCAF1968F1Ae6a322b8Ffbe56840e2f590](https://etherscan.io/address/0xfE455baCAF1968F1Ae6a322b8Ffbe56840e2f590#code) - Roles: - **owner**: PayyMultisig The current deployment carries some associated risks: - Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).