Search
Search for projects by name or address
Payy
Badges
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.
Tokens breakdown
Badges
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.
Why is the project listed in others?
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 here.
The section shows the operating costs that L2s pay to Ethereum.
2026 Feb 17 — Sep 01
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.
2026 Aug 02 — Sep 01
Critical circuit vulnerability disclosed
2026 Jun 10th
An aggregation circuit bug allowed forged burn messages, was patched by the team.
Payy Network is live on Ethereum
2026 Feb 19th
Payy launches its rollup on Ethereum, migrating from its previous deployment on Polygon.
Funds can be stolen if
Funds can be lost if
Funds can be frozen if
Users can be censored if
MEV can be extracted if
There is no mechanism to have transactions be included if the sequencer is down or censoring.
SNARKs are succinct zero knowledge proofs that ensure state correctness, but require trusted setup.
Proof construction and state derivation rely fully on data that is NOT published onchain.
There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.
Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
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.
Funds can be lost if the external data becomes unavailable (CRITICAL).
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.
Payy transactions are proven with Noir 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. The final proof is verified onchain by a Barretenberg-generated UltraHonk verifier.
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.
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.
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.
2026 August 25, 10:47 UTC4changesDiscovery rerun on the same block number with only config-related changes.
Discovery rerun on the same block number with only config-related changes.
Initial discovery
| + | Status: CREATED |
| contract HonkVerifier (eth:0x14DACD534ddc676601B27f41Eb541a7951524a2F) [payy/HonkVerifier] | |
| +++ description: 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. |
| + | Status: CREATED |
| contract PayyMultisig (eth:0x230Dfb03F078B0d5E705F4624fCC915f3126B40f) [GnosisSafe] | |
| +++ description: None |
| + | Status: CREATED |
| contract RollupV1 (eth:0x367C1eAF14AA06b78ce76bd0243297de79d85270) [payy/Rollup] | |
| +++ description: 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. |
| + | Status: CREATED |
| contract ProxyAdmin (eth:0xfE455baCAF1968F1Ae6a322b8Ffbe56840e2f590) [global/ProxyAdmin] | |
| +++ description: None |
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.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
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.
Users can be censored if the operator refuses to include their transactions.
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.
Funds can be frozen if the operators fail to include withdrawals in state updates, as there is no forced exit mechanism.
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.
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.
Funds can be stolen if the owner overwrites the state root or registers a malicious verifier.
Ethereum
Actors:
A Multisig with 2/4 threshold.
- Can upgrade with no delay
- RollupV1 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()
- Can interact with RollupV1
- can submit state updates (new state roots) via verifyRollup(), providing an aggregated ZK proof and validator signatures
Ethereum
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.
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.
- 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).