Search
Search projects, tokens and protocols by name or address
PayyPayy
Badges
About
A shielded ledger L2 for USDC payments in a mobile app, with payment links and a card, that hides amounts but not which notes fund which.
Badges
About
A shielded ledger L2 for USDC payments in a mobile app, with payment links and a card, that hides amounts but not which notes fund which.
Payy is a mobile app for USDC payments. The user deposits USDC, sends it to other users or as a payment link, and withdraws it to Ethereum or tops up the Payy card. Note amounts and owners stay hidden. Which notes fund which, and every deposit and withdrawal with its address and amount, are public.
Users trust Payy, which runs the only validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier, 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. and nodeA software client that participates in the network., delivers notes between users and holds the keys of link and ramp notes. The 2/4 multisig can upgrade the RollupV1 contract and overwrite its state rootA cryptographic hash succinctly representing a state using a Merkle tree. without delay. Leaving needs Payy: withdrawals settle only in its proven state updates, and transaction data lives only on its servers.
Architecture
Each balance is a set of notes. A note holds an amount of USDC and an owner key, and only its commitment enters the state tree. A transaction spends up to two notes, creates up to two and names the commitments it spends, since the circuits use no nullifiers. Payy’s node serves every blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. with its proofs. Ethereum receives only state roots, deposits and withdrawals.
Flow
- Deposit. The app gives each wallet one fixed deposit address. You send USDC there, and Payy’s relayer moves it into the RollupV1 contract with your signed authorization. Deposit address and amount are public.
- Send. Your phone proves the transfer and submits it to Payy’s node. The note reaches the recipient through Payy’s registry, encrypted to the recipient’s key, or as a payment link whose URL holds the note’s secret.
- Withdraw. You burn notes to an Ethereum address, which the next state updateA mechanism that allows to update the claimed state of a project. It usually involves verifying a state transition proof, but it can also be done in a trusted manner by a permissioned actor. pays out. A whitelisted account may pay at once and get refunded at settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals.. Recipient and amount are public. Card top-ups are withdrawals to the card issuer’s contract.
Keys
The app is closed source, so how it creates and backs up keys is unverified. Payy’s backend keeps wallet backups, and its diagnostics reports have a required field for the recovery phrase.
App
The Payy mobile app is closed source. The repository publishes the contracts, circuits, node and backend interfaces. Its open TypeScript 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. knows only Payy’s testnet.
Compliance
KYC is required for the Payy card and fiat ramps, not for transfers. Payy’s backend can block a wallet or an IP address from its services, and its validator can refuse any transaction. The protocol has no view key.
Fees
The RollupV1 contract charges no fee. Payy pays the 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. of deposits and settlement.
What the protocol promises: Hides note amounts and owners. Which notes fund which, and every deposit and withdrawal, are public.
- Payy mobile appReference
The ratings assume this app, since 2026-10-13 · Closed source
Ethereum is public by default. Each protocol is rated on its main privacy promise, like hiding who paid, who received, how much, or which deposit became which withdrawal. Against each adversary, the colour says whether it holds for a careful user with the app's own settings: green yes, yellow only with significant extra work, red no. Fields marked at risk stay private only under the condition in their note.
Every transaction names the notes it spends and creates, so which notes fund which is public. Empty padding notes have a zero commitment, so single-input and single-output transactions are recognizable. Each deposit or withdrawal shows address and amount and points at one nodeA software client that participates in the network. of that graph. The per-transaction proofs use a flavor its authors document as not zero-knowledgeA cryptographic technology and sub-discipline of cryptography that allows an individual to prove that a statement or computation is true without revealing any additional information., and how much of a note it leaks is not established.
Along a path without splits or merges, the deposit and withdrawal amounts fix every amount in between. Each wallet has one fixed deposit address, so all its deposits link to each other and to whoever funded them.
The payment-link website hands each link’s redeem secret to PostHog analytics, which records the full page URL. PostHog also records the session with inputs unmasked, and the download page passes the full link to Framer. The mobile app is untraced.
One company runs the only validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier and 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., the nodeA software client that participates in the network., the note registry, the deposit relayer and the KYC checks. Its backend ties each session to a wallet address and keeps, per wallet, the deposit address, KYC record, country, IP country and the commitment and owner of every note the app reports. For payment links and fiat ramps it holds the notes’ private keys and can read and spend them. Its registry sees which wallet delivers a note to which recipient key, and in which blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over..
The per-transaction proofs are public and not zero-knowledgeA cryptographic technology and sub-discipline of cryptography that allows an individual to prove that a statement or computation is true without revealing any additional information., and the commitments inside them rest on elliptic curves. How much more whoever breaks elliptic-curve cryptography extracts from those proofs is not established.
Escrow drained, network halted
24 Sep 2026
Two state updates pay out almost all escrowed USDC for an invalid burn. Payy halts the networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes..
Critical circuit vulnerability disclosed
10 Jun 2026
An aggregation circuitA program written for the purpose of being proven within a proving system. A circuit is a mathematical representation of the computation to be executed, arithmetic circuits and zkVM execution trace are examples of circuits. Circuits can be written in different languages, ranging from low-level to high-level. bug allowed forged burn messages, was patched by the team.
Funds can be stolen if
- the verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. or the circuits accept an invalid withdrawal.
- the PayyMultisig deploys a malicious upgrade of RollupV1 or overwrites its state rootA cryptographic hash succinctly representing a state using a Merkle tree., with no delay.
Funds can be lost if
- a user loses the note data or the keys required to spend their notes.
- the offchain transaction data becomes unavailable, as data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. is not verified on Ethereum.
- the operators stop including withdrawals in proven state updates, as there is no forced exit mechanism.
Privacy can be lost if
- anyone with Payy’s blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. data follows which notes fund which, from a deposit address to a withdrawal address (see public observer).
- a path without splits or merges reveals every amount between a deposit and a withdrawal (see chain analyst).
- a payment link is opened in a browser, which hands its redeem secret to PostHog and Framer (see networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. observer).
- Payy’s backend, which ties each wallet to its KYC record, deposit address and notes, leaks or uses this data (see privileged insider).
- the public per-transaction proofs, which are not zero-knowledgeA cryptographic technology and sub-discipline of cryptography that allows an individual to prove that a statement or computation is true without revealing any additional information., are opened in the future (see future adversary).
All privileged functions are ultimately controlled by the PayyMultisig (2/4). It owns the ProxyAdmin, which can instantly upgrade the RollupV1 proxy, and it is the owner of the RollupV1 contract, allowing it to manage provers, validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier, ZK verifiers, supported tokens and burn substitutors, and to directly overwrite the state rootA cryptographic hash succinctly representing a state using a Merkle tree. via setRoot(). There is no timelock or exit windowThe amount of time that users have to exit a system before an unwanted upgrade. It takes into account upgrade delays, forced transaction delays and other time factors. To be considered Stage 1, a rollup needs to have an exit window of at least 7d if upgrades are initiated by a permissioned actor less decentralized than a Security Council. For Stage 2, a rollup needs at least 30d in all cases outside of onchain provable bugs. on any of these actions.
Aztec Ignition
- 1Phase 1 · Universal176participants
Detailed description
Aztec Ignition is a trusted setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits. ceremony for KZG commitmentsA polynomial commitment scheme that allows a prover to compute a commitment to a polynomial, with the properties that this commitment can later be opened at any position: the prover shows that the value of the polynomial at a certain position is equal to a claimed value. KZG is widely used as it’s applicable both for univariate and k-variate polynomials, is efficient for batch proofs, and is able to generate many proofs at once relatively fast. It is also proof generation time efficient: the time for prover to commit to a polynomial is linear on the degree of the polynomial. over BN254 curve that was run by Aztec for KZG commitment over BN254 curve in 2019. It included 176 participants and was publicly open for participation.
- Github repo to download and verify the ceremony artifacts: https://github.com/AztecProtocol/ignition-verification.
- Github repo with instructions for ceremony participants: https://github.com/AztecProtocol/Setup.
- Ceremony announcement with a call to participate: https://aztec.network/blog/announcing-ignition.
High severity3changesNew 7702-delegation for on the Payy ms members.
New 7702-delegation for on the Payy ms members.
| EOA (eth:0x111e5feA3D613EB866fd41B30c8257C930180428) { | |
| +++ description: None | |
| proxyType: | |
| - | "EOA" |
| + | "EIP7702 EOA" |
| sourceHashes: | |
| + | ["0x1f44812af62d28f019e30e8eb2af596fb36c7db9d34576972c0405e110a6ef45"] |
| values: | |
| + | {"$implementation":"eth:0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B","delegationManager":"eth:0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3","DOMAIN_VERSION":"1","eip712Domain":{"fields":"0x0f","name":"EIP7702StatelessDeleGator","version":"1","chainId":1,"verifyingContract":"eth:0x111e5feA3D613EB866fd41B30c8257C930180428","salt":"0x0000000000000000000000000000000000000000000000000000000000000000","extensions":[]},"entryPoint":"eth:0x0000000071727De22E5E9d8BAf0edAc6f37da032","getDeposit":0,"getDomainHash":"0xa74a149b2a448a709aeba5259239a6059bde080dcb5769af7fdbd3c537d44b57","getNonce":0,"NAME":"EIP7702StatelessDeleGator","PACKED_USER_OP_TYPEHASH":"0xbc37962d8bd1d319c95199bdfda6d3f92baa8903a61b32d5f4ec1f4b36a3bc18","VERSION":"1.3.0"} |
| } | |
4changesDiscovery 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 | |
Ethereum
Actors:
A Multisig with 2/4 threshold.
- Can upgrade with no delay
- RollupV1 ProxyAdmin
- Can interact with RollupV1
- can manage provers, validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier, ZK verifiers, supported tokens and burn substitutors, and can overwrite the current state rootA cryptographic hash succinctly representing a state using a Merkle tree. via setRoot()
- Can interact with RollupV1
- can sign state updates as a validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier. Signatures from more than 2/3 of the current validator set are required for each update
- Can interact with RollupV1
- can submit state updates (new state rootsA cryptographic hash succinctly representing a state using a Merkle tree.) via verifyRollup(), providing an aggregated ZK proof and validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier signatures
Ethereum
UltraHonk proof verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. generated with Aztec’s Barretenberg from Payy’s final aggregation Noir circuitA program written for the purpose of being proven within a proving system. A circuit is a mathematical representation of the computation to be executed, arithmetic circuits and zkVM execution trace are examples of circuits. Circuits can be written in different languages, ranging from low-level to high-level.. It verifies the aggregated validity proofThe output of a cryptographic proving system attesting to correct computation. ZK-Rollups use succinct validity proofs (also called zero-knowledge proofs) to prove a batch of rollup transactions and blocks were properly executed. Validity proofs are submitted to a verifier, such as an Ethereum smart contract, which accepts them if properly constructed. of each state updateA mechanism that allows to update the claimed state of a project. It usually involves verifying a state transition proof, but it can also be done in a trusted manner by a permissioned actor. submitted to the RollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. contract.
Main contract of the Payy ZK rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup.. It stores the state rootA cryptographic hash succinctly representing a state using a Merkle tree., 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 validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier 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).