cc203ca7 (main)
and
10b3b8d0 (PR)
+30 -0
+30 -0
{
"creator": "Aztec",
"projectsForTvs": [
{
"projectId": "aztecnetwork",
"sinceTimestamp": 1774821600
},
{
"projectId": "payy",
"sinceTimestamp": 1771324355
}
],
"proofSystemInfo": "## Description\n\nBarretenberg is a C++ library that implements several Plonk-based proof systems, developed by Aztec. It notably includes UltraHonk SNARK as an optimized version of previous Plonk implementation, and CHONK (Client-side Highly Optimized ploNK) SNARK for client-side proving on weaker devices. Barretenberg implements actual zero-knowledge SNARK modifications that allow proving over private data, and provides tools to generate UltraHonk smart contract verifiers. It also contains circuits to prove private and public transactions on Aztec L2.\n\n## Proof system\n\nThe main application of Barretenberg is proving Aztec L2 state transition, which includes users locally proving private transactions with true ZK CHONK and more powerful nodes proving public transactions using UltraHonk. CHONK proofs must be verified within UltraHonk, so Barretenberg also includes tools for recursive proving. Both proving systems operate on arithmetic circuits that could be compiled from [Noir](https://github.com/noir-lang/noir) programs into ACIR, which is a [native circuit representation for Barretenberg](https://barretenberg.aztec.network/docs/#relationship-with-noir). \n\n### UltraHonk\n\nUltraHonk is built on top of [Plonk](https://eprint.iacr.org/archive/2019/953/1624533038.pdf) proof system, with several optimizations for performance. It also serves as a basis for CHONK. The main optimization comes from using sumcheck protocol over the boolean hypercube as described in the [HyperPlonk paper](https://eprint.iacr.org/2022/1355). This trick allows reducing prover time and memory requirements at the expense of larger proofs. Barretenberg also contains code for circuits [verifying Honk proofs within UltraHonk verifier](https://github.com/AztecProtocol/aztec-packages/tree/next/barretenberg/cpp/src/barretenberg/stdlib/honk_verifier), allowing prover recursion. For more technical details on UltraHonk see [here](https://github.com/AztecProtocol/aztec-packages/tree/99c1647e91c83a3b1b3e040fce481fb4c7265522/barretenberg/cpp/src/barretenberg/ultra_honk#readme).\n\n### CHONK\n\nCHONK is the proof system that is most optimized for client side proving in memory-restricted environments like mobile and browsers. In addition, CHONK has zero-knowledge property to protect prover private inputs, which is achieved by adding random masking polynomials at several stages of the pipeline and some other measures. For the full description of ZK-related modifications see [here](https://github.com/AztecProtocol/aztec-packages/tree/99c1647e91c83a3b1b3e040fce481fb4c7265522/barretenberg/cpp/src/barretenberg/ultra_honk#zero-knowledge).\n\nOne of CHONK’s key innovations is Goblin architecture that efficiently manages elliptic curve operations over BN254 used e.g. in signatures. Elliptic curve operations are collected in a queue during the circuit proving, but the proof of their correctness is deferred to the very end of the proving process. The final step of the proving is done over a different curve called Grumpkin, which is chosen to make these EC operations native (i.e. extremely efficient). The correctness of translation between BN254 and Grumpkin is handled by the [Translator VM](https://github.com/AztecProtocol/aztec-packages/blob/7d03c441df4935ec5b08069446f3e8d59966532e/barretenberg/cpp/src/barretenberg/translator_vm/README.md) and the correctness of EC operations is proven by the [ECCVM](https://github.com/AztecProtocol/aztec-packages/blob/7d03c441df4935ec5b08069446f3e8d59966532e/barretenberg/cpp/src/barretenberg/eccvm/README.md).\n\nCHONK also introduces a folding scheme inspired by [HyperNova](https://eprint.iacr.org/2023/573) for more memory-efficient proving of recursive smart contract calls. In this case different smart contract are represented by different circuits, which are proven separately and then aggregated. The folding scheme allows efficient aggregation of these proofs that results in only one expensive polynomial commitment check in the end, instead of having to check it for each smart contract call.\n\nFor more technical details on CHONK see [here](https://github.com/AztecProtocol/aztec-packages/tree/7d03c441df4935ec5b08069446f3e8d59966532e/barretenberg/cpp/src/barretenberg/chonk#readme).\n\n### Noir and trusted setups\n\nAlthough not technically a part of Barretenberg proving repo, [Noir language](https://noir-lang.org) represents the most developer-friendly way to create circuits to be proven with UltraHonk or CHONK. It’s a domain-specific language inspired by Rust.\n\nAll Barretenberg proving systems extend Plonk, which is based on KZG commitment schemes. That requires a trusted setup, which is chosen to be Aztec Ignition trusted setup. Some internal proofs, like ECCVM proof, are based on IPA (inner product argument) and thus they require no trusted setup.",
"techStack": {
"zkVM": [
{
"id": "UltraHonk",
"type": "Plonk",
"name": "UltraHonk",
"description": "A KZG-based PLONKish proving system featuring many optimizations, including a sumcheck argument over a boolean hypercube. Developed by Aztec as a part of Barretenberg library."
},
{
"id": "CHONK",
"type": "Plonk",
"name": "CHONK",
"description": "PLONKish proving system, designed for client-side proving. Includes sumcheck argument over a hypercube, HyperNova-like folding schemes and GoblinPlonk EC operation optimization over Grumpkin curve. Developed by Aztec as a part of Barretenberg library."
},
{
"id": "BN254",
"type": "curve",
"name": "BN254",
"description": "BN254, aka BN256, aka alt_bn128 pairing-friendly 254-bit prime field Weierstrass elliptic curve."
},
{
"id": "Grumpkin",
"type": "curve",
"name": "Grumpkin",
"description": "Curve that forms a curve cycle together with BN254, which allows highly efficient recursive proof composition by switching between these two curves."
},
{
"id": "AVM",
"type": "ISA",
"name": "AVM",
"description": "VM that executes the public part of Aztec L2 transactions, conceptually similar to EVM."
}
]
},
"trustedSetups": [
{
"proofSystem": {
"id": "UltraHonk",
"type": "Plonk",
"name": "UltraHonk",
"description": "A KZG-based PLONKish proving system featuring many optimizations, including a sumcheck argument over a boolean hypercube. Developed by Aztec as a part of Barretenberg library."
},
"id": "AztecIgnition",
"name": "Aztec Ignition",
"participantCount": 176,
"risk": "green",
"shortDescription": "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.",
"longDescription": "Aztec Ignition is a trusted setup ceremony for KZG commitments over BN254 curve that was run by Aztec for KZG commitment over BN254 curve in 2019. \nIt included 176 participants and was publicly open for participation.\n\n- Github repo to download and verify the ceremony artifacts: [https://github.com/AztecProtocol/ignition-verification](https://github.com/AztecProtocol/ignition-verification).\n- Github repo with instructions for ceremony participants: [https://github.com/AztecProtocol/Setup](https://github.com/AztecProtocol/Setup).\n- Ceremony announcement with a call to participate: [https://aztec.network/blog/announcing-ignition](https://aztec.network/blog/announcing-ignition)."
}
],
"verifierHashes": [
{
"hash": "0x0f8581a994b714ef6fcffeaea9777e69e6bc7c0140a039a23afc764d8e863328",
"name": "Payy aggregate verifier",
"sourceLink": "https://github.com/polybase/payy/tree/dcd5d96ee15664a59bc24ed0dc2bb78b73ac5e36/noir/agg_final",
"proofSystem": {
"id": "UltraHonk",
"type": "Plonk",
"name": "UltraHonk",
"description": "A KZG-based PLONKish proving system featuring many optimizations, including a sumcheck argument over a boolean hypercube. Developed by Aztec as a part of Barretenberg library."
},
"knownDeployments": [
{
"address": "eth:0x14DACD534ddc676601B27f41Eb541a7951524a2F"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "The verifier was regenerated on Linux. VK generation peaked at approximately 1.7 GiB of memory.\n\nPrepare:\n\n1. Install Nargo 1.0.0-beta.14, e.g. with `noirup -v 1.0.0-beta.14`. `nargo --version` should report noirc git version hash `60ccd48e18ad8ce50d5ecda9baf813b712145051`.\n2. Install the Barretenberg CLI release `v3.0.0-nightly.20251030-2`, the version pinned to Nargo 1.0.0-beta.14 in the official [bb-versions.json](https://github.com/AztecProtocol/aztec-packages/blob/next/barretenberg/bbup/bb-versions.json) mapping, e.g. by downloading `barretenberg-amd64-linux.tar.gz` from the [aztec-packages release](https://github.com/AztecProtocol/aztec-packages/releases/tag/v3.0.0-nightly.20251030-2). Note that the Payy repository README refers to this bb version as `3.0.0-manual.20251030`, for which no release artifact exists.\n\nVerify:\n\n1. Clone [polybase/payy](https://github.com/polybase/payy), then check out commit `dcd5d96ee15664a59bc24ed0dc2bb78b73ac5e36`.\n2. Compile the `agg_final` circuit from source:\n ```bash\n cd noir\n nargo compile --package agg_final\n ```\n3. Generate the UltraHonk verification key with the keccak oracle hash from the newly compiled bytecode:\n ```bash\n mkdir -p /tmp/payy-repro\n bb write_vk --scheme ultra_honk --oracle_hash keccak \\\n -b target/agg_final.json -o /tmp/payy-repro\n xxd -p -c 0 /tmp/payy-repro/vk_hash\n ```\n The final command should print `0f8581a994b714ef6fcffeaea9777e69e6bc7c0140a039a23afc764d8e863328`.",
"description": "UltraHonk verifier generated with Barretenberg from the final proof aggregation Noir circuit (agg_final) of Payy. The hash is the verification key hash hardcoded in the deployed verifier contract."
},
{
"hash": "0x2f0ca3e610369fc41f7fb8a69995a96428fbf69d7dffd2b576e63ba4d9511ee1",
"name": "Barretenberg Aztec verifier v5",
"sourceLink": "https://github.com/AztecProtocol/aztec-packages/tree/v5.0.0/noir-projects/noir-protocol-circuits",
"proofSystem": {
"id": "UltraHonk",
"type": "Plonk",
"name": "UltraHonk",
"description": "A KZG-based PLONKish proving system featuring many optimizations, including a sumcheck argument over a boolean hypercube. Developed by Aztec as a part of Barretenberg library."
},
"knownDeployments": [
{
"address": "eth:0x098f47c00F4df22a8030746Eb11378236C24b4bC"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "The verifier was regenerated on Linux. VK generation peaked at approximately 11.3 GiB of memory.\n\nPrepare:\n\n1. Install the toolchain expected by the repository: Node.js 24.12.0 or newer, Yarn 4.13.0, Rust 1.89.0, CMake 3.24 or newer, Clang 20, Zig 0.15.1, Ninja, `jq`, `xxd`, `base64`, and `gzip`.\n2. Ensure at least 16 GiB of combined memory and swap is available.\n\nVerify:\n\n1. Clone [AztecProtocol/aztec-packages](https://github.com/AztecProtocol/aztec-packages), then check out tag `v5.0.0`. It should resolve to commit `7aa2bd616d632801fe65d97ee8a4434f26886b40`.\n2. Initialize the Noir source pinned by the tag: `git submodule update --init --depth 1 noir/noir-repo`. It should resolve to commit `c57152f91260ecdb9faad4efc20abb14b6d2ece7`.\n3. Build Nargo from the pinned source:\n ```bash\n cd noir/noir-repo\n cargo +1.89.0 build --locked --release --target-dir target --bin nargo\n cd ../..\n ```\n4. Build the Barretenberg CLI from source without AVM components:\n ```bash\n cd barretenberg/cpp\n cmake --fresh --preset clang20-no-avm -DAVM_TRANSPILER_LIB=\n cmake --build --preset clang20-no-avm --target bb --parallel 4\n cd ../..\n ```\n5. Generate the ignored Noir workspace files. Do not run the protocol-circuits bootstrap because it consumes the tracked `pinned-build.tar.gz` instead of compiling the circuit source.\n ```bash\n cd noir-projects/noir-protocol-circuits\n corepack [email protected] install\n corepack [email protected] generate_variants\n ```\n6. Compile `rollup_root` from source:\n ```bash\n ../../noir/noir-repo/target/release/nargo check \\\n --package rollup_root --silence-warnings --show-program-hash\n ../../noir/noir-repo/target/release/nargo compile \\\n --package rollup_root --skip-brillig-constraints-check\n ```\n The monomorphized Noir program hash printed by the first command should be `62fd003ca75d0cd7`.\n7. Generate the UltraHonk verification key from the newly compiled bytecode:\n ```bash\n mkdir -p /tmp/aztec-v5-repro\n jq -r '.bytecode' target/rollup_root.json \\\n | base64 -d \\\n | gunzip \\\n | ../../barretenberg/cpp/build/bin/bb write_vk \\\n --scheme ultra_honk --oracle_hash keccak \\\n -b - -o /tmp/aztec-v5-repro\n xxd -p -c 0 /tmp/aztec-v5-repro/vk_hash\n ```\n The final command should print `2f0ca3e610369fc41f7fb8a69995a96428fbf69d7dffd2b576e63ba4d9511ee1`.\n8. Regenerate the Solidity verifier:\n ```bash\n ../../barretenberg/cpp/build/bin/bb write_solidity_verifier \\\n --scheme ultra_honk --disable_zk \\\n -k /tmp/aztec-v5-repro/vk \\\n -o /tmp/aztec-v5-repro/HonkVerifier.sol \\\n --optimized\n diff -u \\\n /tmp/aztec-v5-repro/HonkVerifier.sol \\\n ../../l1-contracts/script/deploy/HonkVerifier.sol\n ```\n The generated verifier should be identical to the repository copy except for the latter's provenance comment after the Solidity pragma."
}
]
}[ADDED]
payy
+648 -0
+1 -0
"payy"+1 -0
"payy"+1 -0
"Payy"+1 -0
null+1 -0
null+1 -0
1787616000+3 -0
{
"unverifiedContracts": []
}+53 -0
{
"badges": [
{
"id": "AppChain",
"type": "VM",
"name": "Application-specific chain",
"description": "This project is built to operate a specific application",
"action": {
"type": "scalingFilter",
"id": "vm",
"value": "AppChain"
}
},
{
"id": "CustomDA",
"type": "DA",
"name": "Custom DA solution",
"description": "This project is using a custom DA solution",
"action": {
"type": "selfDaHighlight"
}
},
{
"id": "Privacy",
"type": "Other",
"name": "Privacy",
"description": "This project supports private transactions natively",
"action": {
"type": "scalingFilter",
"id": "other",
"value": "Privacy"
}
}
],
"description": "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": {
"websites": [
"https://payy.network"
],
"explorers": [
"https://payy.network/explorer"
],
"documentation": [
"https://docs.payy.network"
],
"repositories": [
"https://github.com/polybase/payy"
],
"socialMedia": [
"https://x.com/payy_link"
]
}
}+1 -0
null+1 -0
null+16 -0
[
{
"title": "Payy Network is live on Ethereum",
"url": "https://payy.network/blog/payy-network-is-live-on-ethereum",
"date": "2026-02-19T00:00:00Z",
"description": "Payy launches its rollup on Ethereum, migrating from its previous deployment on Polygon.",
"type": "general"
},
{
"title": "Critical circuit vulnerability disclosed",
"url": "https://github.com/polybase/payy/security/advisories/GHSA-fhxc-63vg-9gwr",
"date": "2026-06-10T00:00:00Z",
"description": "An aggregation circuit bug allowed forged burn messages, was patched by the team.",
"type": "incident"
}
]+4 -0
{
"apis": [],
"name": "payy"
}+34 -0
[
{
"address": "0x367C1eAF14AA06b78ce76bd0243297de79d85270",
"sinceTimestamp": 1771324355,
"tokens": "*",
"contract": {
"isVerified": true,
"address": "eth:0x367C1eAF14AA06b78ce76bd0243297de79d85270",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"eth:0xfE455baCAF1968F1Ae6a322b8Ffbe56840e2f590"
],
"implementations": [
"eth:0x7d8837b547F4FEa0053571CB149e845FC58e9B2D"
]
},
"chain": "ethereum",
"pastUpgrades": [
{
"timestamp": 1771324355,
"transactionHash": "0x8d002955fe594ded0ee57519c15a7c9dcf52e759be1fdd628eaf810dc2558abd",
"implementations": [
"eth:0x7d8837b547F4FEa0053571CB149e845FC58e9B2D"
]
}
],
"url": "https://etherscan.io/address/0x367C1eAF14AA06b78ce76bd0243297de79d85270#code"
},
"chain": "ethereum",
"includeInTotal": true,
"chainId": 1
}
]+1 -0
null+1 -0
null+1 -0
null+34 -0
{
"capability": "appchain",
"daLayer": [
"None"
],
"hostChain": {
"id": "ethereum",
"slug": "ethereum",
"name": "Ethereum"
},
"layer": "layer2",
"proofSystem": {
"type": "Validity",
"zkCatalogIds": [
"barretenberg"
]
},
"purposes": [
"Payments",
"Privacy"
],
"reasonsForBeingOther": [
{
"label": "No DA bridge",
"shortDescription": "There is no data availability bridge",
"description": "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."
}
],
"stage": "Not applicable",
"type": "Other",
"vm": [
"AppChain"
]
}+3 -0
{
"stage": "NotApplicable"
}+35 -0
{
"self": {
"stateValidation": {
"value": "Validity proofs (SN)",
"description": "SNARKs are succinct zero knowledge proofs that ensure state correctness, but require trusted setup.",
"sentiment": "good",
"orderHint": null,
"permissioned": true,
"executionDelay": 0,
"secondLine": "No execution delay"
},
"dataAvailability": {
"value": "External",
"description": "Proof construction and state derivation rely fully on data that is NOT published onchain.",
"sentiment": "bad"
},
"exitWindow": {
"value": "None",
"description": "There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.",
"sentiment": "bad",
"orderHint": 0
},
"sequencerFailure": {
"value": "No mechanism",
"description": "There is no mechanism to have transactions be included if the sequencer is down or censoring.",
"sentiment": "bad"
},
"proposerFailure": {
"value": "Cannot withdraw",
"description": "Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.",
"sentiment": "bad",
"orderHint": null
}
}
}+18 -0
[
{
"layer": {
"value": "None",
"sentiment": "bad",
"description": "The data is not posted to any data availability layer."
},
"bridge": {
"value": "None",
"sentiment": "bad",
"description": "There is no bridge that can attest if the data has been made available.",
"orderHint": -2
},
"mode": {
"value": "Transaction data"
}
}
]+122 -0
{
"dataAvailability": [
{
"name": "Data is not stored on chain",
"description": "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": [
{
"category": "Funds can be lost if",
"text": "the external data becomes unavailable.",
"isCritical": true
}
],
"references": [
{
"title": "RollupV1.sol - empty verifyCommitHash() placeholder",
"url": "https://etherscan.io/address/0x7d8837b547F4FEa0053571CB149e845FC58e9B2D#code"
}
]
}
],
"exitMechanisms": [
{
"name": "Regular exit",
"description": "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": [
{
"category": "Funds can be frozen if",
"text": "the operators fail to include withdrawals in state updates, as there is no forced exit mechanism."
}
],
"references": []
}
],
"forceTransactions": {
"name": "Users can't force any transaction",
"description": "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": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
}
],
"references": []
},
"operator": {
"name": "The system has a centralized operator",
"description": "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": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
}
],
"references": [
{
"title": "Payy docs - Rollup",
"url": "https://docs.payy.network/payy-network/04_rollup"
}
]
},
"otherConsiderations": [
{
"name": "Confidential notes over a public spend graph",
"description": "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.",
"risks": [],
"references": [
{
"title": "noir/utxo - commitments are public inputs of the UTXO proof",
"url": "https://github.com/polybase/payy/blob/main/noir/utxo/src/main.nr"
},
{
"title": "Payy docs",
"url": "https://docs.payy.network"
}
]
},
{
"name": "Owner can overwrite the state root",
"description": "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": [
{
"category": "Funds can be stolen if",
"text": "the owner overwrites the state root or registers a malicious verifier."
}
],
"references": []
}
],
"stateValidation": {
"description": "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.",
"categories": [
{
"title": "ZK Circuits",
"description": "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": [
{
"title": "HonkVerifier - Etherscan",
"url": "https://etherscan.io/address/0x14DACD534ddc676601B27f41Eb541a7951524a2F#code"
}
]
},
{
"title": "Verification Keys Generation",
"description": "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": [
{
"title": "RollupV1.sol - addZkVerifier()",
"url": "https://etherscan.io/address/0x7d8837b547F4FEa0053571CB149e845FC58e9B2D#code"
}
]
},
{
"title": "State root proposals",
"description": "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.",
"references": []
}
]
},
"upgradesAndGovernance": {
"content": "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."
}
}+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+53 -0
{
"attributes": [
{
"id": "zk",
"label": "ZK",
"description": "Uses zero-knowledge proofs to prove private actions without revealing private data."
},
{
"id": "privateAmounts",
"label": "Private amounts",
"description": "Transfer amounts are private, while sender and recipient addresses remain public."
},
{
"id": "anyAmount",
"label": "Any amount",
"description": "Deposits and withdrawals can have any size."
}
],
"detailedDescription": "Payy is a payments-focused ZK network, designed around private stablecoin transfers. Ethereum receives only state roots and the public deposit and withdrawal messages of each state update. Balances live offchain as UTXO-style notes whose commitments form a sparse Merkle tree maintained by the Payy validators. \n\n### Privacy considerations\n\nTo spend notes, the user's client generates a [Noir](https://noir-lang.org/) `utxo` proof that demonstrates ownership of the input notes and conservation of value; the public inputs of that proof are the commitments of the two notes consumed and the two notes created. Transfers therefore hide who paid whom and how much, but they do not hide which commitments were consumed: the deployed circuits do not use nullifiers, and a spend names its input commitments directly, which the node then marks as spent. Anyone with Payy block data can follow the resulting spend graph.\n\nBecause only commitments are stored in the tree, a recipient cannot reconstruct a received note from chain data alone: the sender must transmit the note contents out of band. In practice it is done by an encrypted registry operated by Payy, which stores the recipient's public key in the clear and serves each client the entries addressed to it. Thus it learns the delivery metadata even though it cannot read note contents. \n\n### Fees\n\nThe protocol charges no transfer or withdrawal fee.\n\n### Compliance\n\nThe deployed protocol enforces no compliance measures and contains no auditor key, view key or other mechanism that could retroactively decrypt past activity. Identity data is collected at the application layer: KYC is required for the Payy card and fiat ramps, but it is not necessary for using Payy L2.\n\n### Anonymity set\n\nPayy hides the contents of each note but not the links between notes, so its anonymity set should not be read as the set of all users. An observer of Payy block data sees a graph of opaque commitments; privacy rests on not knowing which address, asset or amount each node in that graph carries.",
"exitWindow": {
"value": "None",
"sentiment": "bad",
"orderHint": 0,
"description": "The PayyMultisig can instantly upgrade the Rollup contract, replace ZK verifiers and directly overwrite the state root, so users have no time to exit before a malicious change takes effect.",
"walkawayTest": {
"passed": false,
"reason": "Withdrawals must be included in a proven state update by the permissioned Payy operators. There is no mechanism for users to exit on Ethereum if the operators halt."
}
},
"noteDiscovery": {
"description": "Payy operator runs a centralized note discovery service, where the sender submits full transfer data encrypted to the receiver. The centralized operator learns which addresses receive notes and when, and who transacted with whom.\n\nThe protocol itself allows direct peer-to-peer note communication that bypasses the registry.",
"risks": [
"The Payy-operated note registry, note lookup and wallet backup services learn which addresses receive and hold which notes and can link senders to recipients. The same operator holds KYC data for users of the Payy card and fiat ramps, which can tie those addresses to real identities.",
"A compromise of a recipient key or of the encryption scheme exposes all note data ever stored in the encrypted registry."
]
},
"privacy": {
"value": "Linkable notes",
"sentiment": "bad",
"description": "Transactions within the Payy network do not hide the links between token transferred: anyone with Payy block data can reconstruct the spend graph and trace every withdrawal back to contributing deposits. Only the contents of each individual note (owner address, amount and asset) are hidden."
},
"reproducibility": {
"value": "Partially reproducible",
"sentiment": "warning",
"description": "The sources for UI / wallet are not published, so users have to rely on Payy operated software. Also, DA is not posted to identifiable public source, so L2 state could not be independently reproduced.\n\nThe contracts, Noir circuits and node software are published in the Payy repository (without any license) and can be built and run locally."
},
"riskSummary": "## Funds can be stolen if\n1. the proof system is broken and a malicious validator is registered, allowing forged spends or withdrawals.\n2. the PayyMultisig upgrades the Rollup contract or directly overwrites the state root to a malicious version.\n
\n## Funds can be lost if\n1. a user loses the note data or the keys required to spend their notes.\n2. the offchain transaction data becomes unavailable, as data availability is not verified on Ethereum.\n3. the operators stop including withdrawals in proven state updates, as there is no forced exit mechanism.\n
\n## Privacy can be lost if\n1. the Payy-operated note registry, note lookup or wallet backup services are compromised or their records are disclosed, revealing which addresses receive and hold which notes and who transacted with whom.",
"tokens": [],
"upgradesAndGovernance": {
"content": "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."
},
"zkCatalogId": "barretenberg"
}+1 -0
null+1 -0
null+4 -0
{
"associatedTokens": [],
"warnings": []
}+1 -0
null+1 -0
null+3 -0
{
"explanation": "Payy is a ZK network that periodically settles its state on Ethereum. Each verifyRollup() call both submits the aggregated validity proof and updates the state root, so state updates and proof submissions are tracked as the same transactions."
}+6 -0
{
"duplicateData": {
"from": "stateUpdates",
"to": "proofSubmissions"
}
}+1 -0
{}+26 -0
[
{
"projectId": "payy",
"sinceTimestamp": 1771324355,
"type": "liveness",
"subtype": "stateUpdates",
"params": {
"formula": "functionCall",
"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)"
}
},
{
"projectId": "payy",
"sinceTimestamp": 1771324355,
"type": "l2costs",
"subtype": "stateUpdates",
"params": {
"formula": "functionCall",
"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)"
}
}
]+1 -0
null+1 -0
null+1 -0
null+88 -0
{
"ethereum": {
"roles": [],
"actors": [
{
"id": "PayyMultisig",
"name": "PayyMultisig",
"description": "A Multisig with 2/4 threshold. \n* Can upgrade **with no delay**\n * RollupV1 [via: ProxyAdmin]\n* Can interact with RollupV1\n * can manage provers, validators, ZK verifiers, supported tokens and burn substitutors, and can overwrite the current state root via setRoot() ",
"accounts": [
{
"address": "eth:0x230Dfb03F078B0d5E705F4624fCC915f3126B40f",
"type": "Contract",
"isVerified": true,
"name": "0x230D…B40f",
"url": "https://etherscan.io/address/0x230Dfb03F078B0d5E705F4624fCC915f3126B40f"
}
],
"chain": "ethereum",
"references": [],
"participants": [
{
"address": "eth:0x54e22ad93DE7Dad5C83e9b1caC257F3aB384b02c",
"type": "EOA",
"isVerified": true,
"name": "0x54e2…b02c",
"url": "https://etherscan.io/address/0x54e22ad93DE7Dad5C83e9b1caC257F3aB384b02c"
},
{
"address": "eth:0x111e5feA3D613EB866fd41B30c8257C930180428",
"type": "EOA",
"isVerified": true,
"name": "0x111e…0428",
"url": "https://etherscan.io/address/0x111e5feA3D613EB866fd41B30c8257C930180428"
},
{
"address": "eth:0xCa1Df6eDf8adaCA00FC24DBD919578dD2e9EcBb6",
"type": "EOA",
"isVerified": true,
"name": "0xCa1D…cBb6",
"url": "https://etherscan.io/address/0xCa1Df6eDf8adaCA00FC24DBD919578dD2e9EcBb6"
},
{
"address": "eth:0xAF657A8Fa036bcc99AC3cCd5b7fFa4AaddFBE501",
"type": "EOA",
"isVerified": true,
"name": "0xAF65…E501",
"url": "https://etherscan.io/address/0xAF657A8Fa036bcc99AC3cCd5b7fFa4AaddFBE501"
}
],
"discoveryDrivenData": true
},
{
"id": "EOA-1",
"name": "EOA 1",
"accounts": [
{
"address": "eth:0x41582701CB3117680687Df80bD5a2ca971bDA964",
"type": "EOA",
"isVerified": true,
"name": "0x4158…A964",
"url": "https://etherscan.io/address/0x41582701CB3117680687Df80bD5a2ca971bDA964",
"displayName": "EOA 1"
}
],
"chain": "ethereum",
"description": "* Can interact with RollupV1\n * can sign state updates as a validator. Signatures from more than 2/3 of the current validator set are required for each update ",
"discoveryDrivenData": true
},
{
"id": "EOA-2",
"name": "EOA 2",
"accounts": [
{
"address": "eth:0x5343B904Bf837Befb2f5A256B0CD5fbF30503D38",
"type": "EOA",
"isVerified": true,
"name": "0x5343…3D38",
"url": "https://etherscan.io/address/0x5343B904Bf837Befb2f5A256B0CD5fbF30503D38",
"displayName": "EOA 2"
}
],
"chain": "ethereum",
"description": "* Can interact with RollupV1\n * can submit state updates (new state roots) via verifyRollup(), providing an aggregated ZK proof and validator signatures ",
"discoveryDrivenData": true
}
]
}
}+113 -0
{
"addresses": {
"ethereum": [
{
"name": "HonkVerifier",
"isVerified": true,
"address": "eth:0x14DACD534ddc676601B27f41Eb541a7951524a2F",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"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.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x14DACD534ddc676601B27f41Eb541a7951524a2F#code"
},
{
"name": "RollupV1",
"isVerified": true,
"address": "eth:0x367C1eAF14AA06b78ce76bd0243297de79d85270",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"eth:0xfE455baCAF1968F1Ae6a322b8Ffbe56840e2f590"
],
"implementations": [
"eth:0x7d8837b547F4FEa0053571CB149e845FC58e9B2D"
]
},
"chain": "ethereum",
"pastUpgrades": [
{
"timestamp": 1771324355,
"transactionHash": "0x8d002955fe594ded0ee57519c15a7c9dcf52e759be1fdd628eaf810dc2558abd",
"implementations": [
"eth:0x7d8837b547F4FEa0053571CB149e845FC58e9B2D"
]
}
],
"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.\n* Roles:\n * **admin**: ProxyAdmin; ultimately PayyMultisig\n * **getValidatorSets**: EOA 1\n * **initialProver**: EOA 2\n * **owner**: PayyMultisig",
"upgradableBy": [
{
"name": "PayyMultisig",
"delay": "no"
}
],
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x367C1eAF14AA06b78ce76bd0243297de79d85270#code"
},
{
"name": "ProxyAdmin",
"isVerified": true,
"address": "eth:0xfE455baCAF1968F1Ae6a322b8Ffbe56840e2f590",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "* Roles:\n * **owner**: PayyMultisig",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xfE455baCAF1968F1Ae6a322b8Ffbe56840e2f590#code"
}
]
},
"escrows": [
{
"address": "0x367C1eAF14AA06b78ce76bd0243297de79d85270",
"sinceTimestamp": 1771324355,
"tokens": "*",
"contract": {
"isVerified": true,
"address": "eth:0x367C1eAF14AA06b78ce76bd0243297de79d85270",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"eth:0xfE455baCAF1968F1Ae6a322b8Ffbe56840e2f590"
],
"implementations": [
"eth:0x7d8837b547F4FEa0053571CB149e845FC58e9B2D"
]
},
"chain": "ethereum",
"pastUpgrades": [
{
"timestamp": 1771324355,
"transactionHash": "0x8d002955fe594ded0ee57519c15a7c9dcf52e759be1fdd628eaf810dc2558abd",
"implementations": [
"eth:0x7d8837b547F4FEa0053571CB149e845FC58e9B2D"
]
}
],
"url": "https://etherscan.io/address/0x367C1eAF14AA06b78ce76bd0243297de79d85270#code"
},
"chain": "ethereum",
"includeInTotal": true,
"chainId": 1
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "a contract receives a malicious code upgrade. There is no delay on code upgrades.",
"isCritical": true
}
],
"zkVerifiers": [
"eth:0x14DACD534ddc676601B27f41Eb541a7951524a2F"
]
}+7 -0
{
"baseTimestamp": 1787654846,
"contractsDiscoDriven": true,
"hasDiscoUi": true,
"isDiscoDriven": true,
"permissionsDiscoDriven": true
}+1 -0
null+1 -0
null+1 -1
+1 -1
{
"redWarning": {
"text": "The tornado.cash website linked from the official project GitHub is malicious. Using it will result in the loss of deposited funds. Visit the official TORN DAO telegram channel for more info: https://t.me/TornadoCashOfficialDAO."
"text": "The tornado.cash website linked from the official project GitHub is malicious. Using it will result in the loss of deposited funds. See Secure frontend section below."
},
"unverifiedContracts": [
"eth:0xD82ed8786D7c69DC7e052F7A542AB047971E73d2",
"eth:0x6234c4C2734D2B246AE074492F402D8f58ff3226",
"eth:0xbFA347D89Ac54F7C2De2433458cb98A85fc03CEd"
]
}+3 -3
+3 -3
{
"attributes": [
{
"id": "fhe",
"label": "FHE",
"description": "Uses fully homomorphic encryption for private computation over encrypted values."
},
{
"id": "privateAmounts",
"label": "Private amounts",
"description": "Transfer amounts are private, while sender and recipient addresses remain public."
},
{
"id": "anyAmount",
"label": "Any amount",
"description": "Deposits and withdrawals can have any size."
},
{
"id": "defi",
"label": "DeFi",
"description": "Interop with DeFi (swaps, vaults) from within the confidential token."
}
],
"exitWindow": {
"value": "None",
"sentiment": "bad",
"orderHint": 0,
"description": "The confidential token contracts and system contracts are upgradeable without an onchain delay, so users do not get a guaranteed withdrawal window before changes take effect.",
"walkawayTest": {
"passed": false,
"reason": "Only KMS 7/13 multisig members can decrypt FHE ciphertext. Also, FHE coprocessor operator is currently essential for protocol liveness."
}
},
"privacy": {
"value": "Threshold FHE view key",
"sentiment": "warning",
"description": "The 7/13 threshold covers only the current Ethereum verifier context. A threshold with usable KMS key shares can decrypt current and past private balances. Zama states that KMS nodes run inside TEEs, but this is not verified onchain. Compliance can be enforced by confidential token owners blocking users and by configured underlying-token denylist hooks during deposits, transfers, unwrap requests, and unwrap finalization. Confidential token owners can also appoint observer accounts that receive wildcard decryption access to all balances and transfer amounts of their token (currently none are configured)."
"value": "Transparent transfer graph",
"sentiment": "bad",
"description": "Zama confidential tokens do not hide the links between senders and recipients, only the amounts. Anyone can retrace each confidential transfer to its contributing plaintext deposits.\nAdditionally, a threshold with usable KMS key shares can decrypt current and past private balances. Zama states that KMS nodes run inside TEEs, but this is not verified onchain. Compliance can be enforced by confidential token owners blocking users and by configured underlying-token denylist hooks during deposits, transfers, unwrap requests, and unwrap finalization. Confidential token owners can also appoint observer accounts that receive wildcard decryption access to all balances and transfer amounts of their token (currently none are configured)."
},
"quantumResistant": true,
"reproducibility": {
"value": "Partially reproducible",
"sentiment": "warning",
"description": "The smart contracts are source-available, but users also rely on offchain FHE execution and threshold decryption services whose outputs are accepted onchain through signature verification. The offchain data cannot currently be fully reproduced from Ethereum DA."
},
"riskSummary": "## Funds can be stolen if\n1. a malicious upgrade compromises the confidential token contracts or FHEVM contracts with their escrowed underlying tokens.\n2. the threshold of the current or any non-destroyed historical Ethereum KMS context attests an inflated unwrap amount, allowing pooled underlying deposited before or after that context existed to be released. Governance can also install a malicious context or lower the threshold of any live context in place; 7/13 describes only the current context.\n3. the 1/1 coprocessor input verification path accepts invalid encrypted inputs that bypass confidential balance checks.\n
\n## Funds can be lost if\n1. an underlying token admin blacklists a confidential token address or otherwise prevents transfers from the contract.\n2. a user is blocked by the confidential token owner or by a configured underlying-token denylist before finalization/withdrawal.\n3. a confidential token is paused by an owner-appointed pauser and not unpaused by the owner, halting confidential transfers, unwrap requests, and unwrap finalization (no pauser is currently set on any confidential token).\n4. offchain ciphertext data required by the coprocessor or KMS for encrypted handles becomes unavailable and cannot be reconstructed.\n
\n## Privacy can be lost if\n1. enough KMS operators with usable key shares collude or are compromised and decrypt private ciphertext handles. 7/13 describes only the current verifier context, while retained contexts can have different memberships and thresholds.\n2. the confidential token owner appoints an observer: observers receive a wildcard, non-expiring user-decryption delegation over all of that token's encrypted handles and can decrypt its balances and transfer amounts (no observers are currently configured on any confidential token).\n3. the offchain coprocessor, wallet, relayer, frontend, or RPC path records enough metadata to link a user to encrypted inputs or transactions.\n4. deposits and withdrawals are linked by clear boundary amounts, recipient graph, timing, or address reuse.",
"summaryTrackedItemName": "token",
"tokens": [
{
"token": {
"address": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
"iconUrl": "https://assets.coingecko.com/coins/images/6319/large/usdc.png?1696506694",
"symbol": "USDC",
"decimals": 6,
"priceId": "usd-coin",
"sinceTimestamp": 1766750819
},
"buckets": [
{
"id": "zama-cw-cUSDC",
"type": "pool",
"label": "cUSDC token",
"address": "eth:0xe978F22157048E5DB8E5d07971376e86671672B2",
"sinceTimestamp": 1766750819,
"deposit": {
"event": "0xcda691c81d2fd787d8c209adb4ae8b138f857d7575adf7669195ed05482e701b",
"extractor": "zamaWrap",
"params": {}
},
"withdrawal": {
"event": "0x87061fd1a5b3714805472c94c9eb8a6b8491992ee77791aa2594be67b92fd962",
"extractor": "zamaUnwrap",
"params": {
"rate": "1"
}
}
}
]
},
{
"token": {
"address": "0xdAC17F958D2ee523a2206206994597C13D831ec7",
"iconUrl": "https://assets.coingecko.com/coins/images/325/large/Tether.png?1696501661",
"symbol": "USDT",
"decimals": 6,
"priceId": "tether",
"sinceTimestamp": 1766750831
},
"buckets": [
{
"id": "zama-cw-cUSDT",
"type": "pool",
"label": "cUSDT token",
"address": "eth:0xAe0207C757Aa2B4019Ad96edD0092ddc63EF0c50",
"sinceTimestamp": 1766750831,
"deposit": {
"event": "0xcda691c81d2fd787d8c209adb4ae8b138f857d7575adf7669195ed05482e701b",
"extractor": "zamaWrap",
"params": {}
},
"withdrawal": {
"event": "0x87061fd1a5b3714805472c94c9eb8a6b8491992ee77791aa2594be67b92fd962",
"extractor": "zamaUnwrap",
"params": {
"rate": "1"
}
}
}
]
},
{
"token": {
"address": "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2",
"iconUrl": "https://assets.coingecko.com/coins/images/2518/large/weth.png?1696503332",
"symbol": "WETH",
"decimals": 18,
"priceId": "weth",
"sinceTimestamp": 1766750843
},
"buckets": [
{
"id": "zama-cw-cWETH",
"type": "pool",
"label": "cWETH token",
"address": "eth:0xda9396b82634Ea99243cE51258B6A5Ae512D4893",
"sinceTimestamp": 1766750843,
"deposit": {
"event": "0xcda691c81d2fd787d8c209adb4ae8b138f857d7575adf7669195ed05482e701b",
"extractor": "zamaWrap",
"params": {}
},
"withdrawal": {
"event": "0x87061fd1a5b3714805472c94c9eb8a6b8491992ee77791aa2594be67b92fd962",
"extractor": "zamaUnwrap",
"params": {
"rate": "1000000000000"
}
}
}
]
},
{
"token": {
"address": "0xA12CC123ba206d4031D1c7f6223D1C2Ec249f4f3",
"iconUrl": "https://coin-images.coingecko.com/coins/images/70921/large/zama.png?1764591992",
"symbol": "ZAMA",
"decimals": 18,
"priceId": "zama",
"sinceTimestamp": 1766750867
},
"buckets": [
{
"id": "zama-cw-cZAMA",
"type": "pool",
"label": "cZAMA token",
"address": "eth:0x80CB147Fd86dC6dEe3Eee7e4Cee33d1397d98071",
"sinceTimestamp": 1766750867,
"deposit": {
"event": "0xcda691c81d2fd787d8c209adb4ae8b138f857d7575adf7669195ed05482e701b",
"extractor": "zamaWrap",
"params": {}
},
"withdrawal": {
"event": "0x87061fd1a5b3714805472c94c9eb8a6b8491992ee77791aa2594be67b92fd962",
"extractor": "zamaUnwrap",
"params": {
"rate": "1000000000000"
}
}
}
]
},
{
"token": {
"address": "0x27f6c8289550fCE67f6B50BeD1F519966aFE5287",
"iconUrl": "https://coin-images.coingecko.com/coins/images/70647/large/tgbp-square.png?1762953800",
"symbol": "tGBP",
"decimals": 18,
"priceId": "tokenised-gbp",
"sinceTimestamp": 1767000887
},
"buckets": [
{
"id": "zama-cw-ctGBP",
"type": "pool",
"label": "ctGBP token",
"address": "eth:0xa873750ccBafD5ec7Dd13bfD5237d7129832eDD9",
"sinceTimestamp": 1767000887,
"deposit": {
"event": "0xcda691c81d2fd787d8c209adb4ae8b138f857d7575adf7669195ed05482e701b",
"extractor": "zamaWrap",
"params": {}
},
"withdrawal": {
"event": "0x87061fd1a5b3714805472c94c9eb8a6b8491992ee77791aa2594be67b92fd962",
"extractor": "zamaUnwrap",
"params": {
"rate": "1000000000000"
}
}
}
]
},
{
"token": {
"address": "0x68749665FF8D2d112Fa859AA293F07A622782F38",
"iconUrl": "https://assets.coingecko.com/coins/images/10481/large/Tether_Gold.png?1696510471",
"symbol": "XAUt",
"decimals": 6,
"priceId": "tether-gold",
"sinceTimestamp": 1772116091
},
"buckets": [
{
"id": "zama-cw-cXAUt",
"type": "pool",
"label": "cXAUt token",
"address": "eth:0x73cc9aF9d6BEFdb3c3fAf8a5E8c05Cb95FdaEEf1",
"sinceTimestamp": 1772116091,
"deposit": {
"event": "0xcda691c81d2fd787d8c209adb4ae8b138f857d7575adf7669195ed05482e701b",
"extractor": "zamaWrap",
"params": {}
},
"withdrawal": {
"event": "0x87061fd1a5b3714805472c94c9eb8a6b8491992ee77791aa2594be67b92fd962",
"extractor": "zamaUnwrap",
"params": {
"rate": "1"
}
}
}
]
},
{
"token": {
"address": "0xbeeffABcd0dB09589Dd21854aa760C52aB4bf04F",
"iconUrl": "https://coin-images.coingecko.com/coins/images/70647/large/tgbp-square.png?1762953800",
"symbol": "bbqTGBP",
"decimals": 18,
"priceId": "tokenised-gbp",
"sinceTimestamp": 1780585031
},
"buckets": [
{
"id": "zama-cw-cbbqTGBP",
"type": "pool",
"label": "cbbqTGBP token",
"address": "eth:0xBA4cFF6ED6F7Cb2A58776dECa4E984b498446762",
"sinceTimestamp": 1780585031,
"deposit": {
"event": "0xcda691c81d2fd787d8c209adb4ae8b138f857d7575adf7669195ed05482e701b",
"extractor": "zamaWrap",
"params": {}
},
"withdrawal": {
"event": "0x87061fd1a5b3714805472c94c9eb8a6b8491992ee77791aa2594be67b92fd962",
"extractor": "zamaUnwrap",
"params": {
"rate": "1000000000000"
}
}
}
]
},
{
"token": {
"address": "0xbEEF00A59B577423653A1526c7009bdE103F542B",
"iconUrl": "https://coin-images.coingecko.com/coins/images/6319/large/USDC.png?1769615602",
"symbol": "steakcUSDC",
"decimals": 18,
"priceId": "usd-coin",
"sinceTimestamp": 1781877707
},
"buckets": [
{
"id": "zama-cw-csteakcUSDC",
"type": "pool",
"label": "csteakcUSDC token",
"address": "eth:0x66Bf74E96900D1a19c7070D939D124f2F565C458",
"sinceTimestamp": 1781877707,
"deposit": {
"event": "0xcda691c81d2fd787d8c209adb4ae8b138f857d7575adf7669195ed05482e701b",
"extractor": "zamaWrap",
"params": {}
},
"withdrawal": {
"event": "0x87061fd1a5b3714805472c94c9eb8a6b8491992ee77791aa2594be67b92fd962",
"extractor": "zamaUnwrap",
"params": {
"rate": "1000000000000"
}
}
}
]
}
],
"upgradesAndGovernance": {
"content": "Zama Confidential Tokens governance is implemented through an Aragon 'DAO' deployment controlled by two multisigs: ZamaGovMultisigA with a 9/17 threshold and ZamaGovMultisigB with a 3/5 threshold. The Gateway contracts are controlled separately by the SafeL2 multisig listed in the permissions section. These accounts can upgrade contracts or change critical configuration without a timelock. On the Gateway, the owner multisig can create and destroy KMS contexts, change the thresholds of any live context, and disable or remove registered host chains, halting Gateway workflows for those chains.\n\nConfidential token owners and underlying token owners can freeze users. Confidential token owners can further appoint a pauser that halts all confidential transfers, wrapping, and unwrapping of their token (only the owner can unpause), change or disable the underlying-token denylist hook, and appoint observers that gain wildcard decryption access to all balances and transfer amounts of their token. Currently, no pausers or observers are configured. The Ethereum ACL owner can manage ACL-level account blocking, unpause the ACL, change HCU limits, and — through the ProtocolConfig contract — create KMS contexts with arbitrary signer sets and thresholds, retune the thresholds of any live context (including the current one) in place, and trigger or abort FHE key- and CRS-generation in the KMSGeneration contract. A new context immediately becomes the default verifier authority and can attest unwrap amounts for assets deposited before it existed. Superseded contexts remain equally authoritative for all past and future ciphertext handles until the ACL owner explicitly destroys them; the current context cannot be destroyed. Changing an onchain KMS context changes only the accepted ECDSA credentials and does not trigger or verify resharing or destruction of the underlying FHE key shares.\n\nOffchain components like the coprocessor and KMS are trusted for liveness, privacy and security and are currently not decentralized."
}
}