Privacy · P3

Onchain linkability

What do calldata and events reveal about who paid whom for what?

Why it matters

Public chains are permanent. Invoice IDs or payee tags in events let anyone reconstruct a merchant's revenue and customer list.

Scoring anchors

3 Strong	No payee identifiers, invoice metadata, or payer-payee linkage in calldata or events beyond what settlement needs; fresh addresses or stealth/privacy patterns available.
2 Partial	Minimal linkage, documented.
1 Weak	Invoice IDs or payee tags in events, disclosed.
0 Fails	Plaintext metadata (emails, order contents) onchain, or undisclosed linkage.
No evidence	No admissible evidence submitted yet. Counts as 0 in the pillar.

Admissible evidence

Event definitions and calldata encoding at a pinned commit verified
Sample transactions on an explorer verified

Common failures

Treating a direct transfer as private; the transfer itself links payer and payee.

Current ratings

Provider	Score	Finding
Aleo (credits.aleo private transfers)	3 Strong	A transfer_private with a private fee reveals no payer, payee or amount onchain; the program and function name, timing and transaction size are visible. Paying the fee publicly (fee_public) reveals the payer's address, and public transfers are fully transparent; both are explicit choices in the SDK and CLI. The anonymity set depends on how much activity uses records, which we do not score. Judgment call: we score what the protocol offers for a private transfer, which is anchor 3.
AnomaPay	2 Partial	Deposits and withdrawals reveal address, token and arbitrary amount; shielded transfers between AnomaPay users carry only tags and payload blobs and are submitted by the service, not the user. We did not verify from code that payload blobs are encrypted end to end (the SDK has AES-GCM helpers). Judgment call: 2, minimal linkage documented; not 3 because entry and exit amounts are plaintext and the payload encryption was not traced. The proving service sees everything (P2, P4).
Avalanche Card	No evidence	No admissible evidence yet.
Avici Card	No evidence	No admissible evidence yet.
Aztec (Alpha mainnet private token transfers)	2 Partial	A private token transfer hides the recipient and amount. Unless the payer uses a private fee payment contract, the payer's own account pays the fee and is recorded publicly as fee payer, so the chain shows who sent a private transaction, though not to whom. Side-effect counts give transaction fingerprints, and the docs warn that the zk property is not yet guaranteed. All of this is documented. Judgment call: minimal, documented linkage is anchor 2.
Bitget Wallet Card	1 Weak	Every card spend is public and linked to the cardholder's account number, address, card id and amount, though not to the merchant. The linkage is disclosed in the terms. Account tags in events, disclosed, so 1.
Blanksquare (Shielder)	2 Partial	Onchain data shows who deposited and who received, and the exact amounts, but not which deposit funded which withdrawal. Amounts are arbitrary and in plaintext, so amount and timing matching can link payer and payee. The anonymity-revoker key holder (set by the owner Safe) can link every action of an account. Judgment call: 2, minimal linkage by design and documented, but not 3 because amounts are public and a designated party can deanonymise.
COCA Card	No evidence	No admissible evidence yet.
Coinbase Commerce (Onchain Payment Protocol)	1 Weak	Every payment publishes payer, payee, amount and a per-charge id in a single event, with Coinbase's operator address indexed. Anyone can list all of a merchant's Commerce payers and revenue by filtering on the operator and recipient. The README documents the event fields. The protocol offers no fresh-address or privacy option, because the recipient is the merchant's fixed wallet.
Curvy	2 Partial	Payers send to fresh portal addresses, so no stable payee address appears onchain. Transfers inside the pool emit encrypted note fields. Entry amounts are plaintext in PendingNotes. The ownerHash sits in shield calldata, and we did not verify from code whether it changes for each note. Exits reveal amount and destination. Amount and timing matching are behavioural and not scored. Judgment call: stealth-style receipt fits anchor 3, but the plaintext entry data and the unverified ownerHash freshness hold it at 2.
Daimo Pay	1 Weak	Each session gets a fresh CREATE2 deposit address. That freshness does not protect privacy, because the manager's events publish the payee, the refund address (usually the payer), and any integrator calldata together in one log. Anyone can join payer to payee from a single event. The sample transaction also shows integrator tags in plaintext onchain. Judgment call: we score 1 and not 0, because the event definitions are in public verified source and the policy says payments are onchain. No user-facing document describes this linkage.
Deblock Card	No evidence	No admissible evidence yet.
Ethena Pay	1 Weak	No merchant data goes onchain, but every card spend is a public transfer from one long-lived wallet to a known Ethena Pay/Rain collateral address, so anyone can read a cardholder's spend amounts and timing; daily USDe boost payouts from a single Safe tag the wallet further. No fresh addresses. Judgment call: linkage is minimal but not documented to users, so below 2; it is not plaintext metadata, so 1 rather than 0.
ether.fi Cash	1 Weak	No merchant or order data goes onchain. Every purchase is still a public event from a long-lived Safe, carrying a per-transaction card id, the BIN sponsor and USD amounts. Referral cashback events publicly link two users' Safes. Judgment call: the txId works like an invoice id that the issuer side can join to merchant data; it is disclosed in the docs' event list. Disclosed tags = 1, not 2.
Exa Card	2 Partial	Every card spend is publicly tied to the user's long-lived Exa account (amount and time), and the Collected event marks the account as an Exa cardholder. No merchant data goes onchain, and there are no fresh addresses. Minimal linkage that is documented, so 2.
Fluidkey	2 Partial	Receiving uses fresh addresses with no metadata. Spending can combine several stealth accounts in one payment, linking them, and Safes created with the earn-module initializer are recognisable as Fluidkey accounts; both are documented. Fluidkey itself sees all links (P2). Judgment call: 2, minimal documented linkage, because the linking comes from the app's spending logic rather than user behaviour.
Fuse Card	2 Partial	No merchant data goes onchain. Every purchase is still a public, exactly sized transfer from a long-lived card vault, signed by Bridge's well-known key, so anyone can list a cardholder's spending amounts and timing. There are no fresh addresses or privacy patterns. Minimal linkage, documented, so 2.
Gnosis Pay	2 Partial	No merchant or order data goes onchain. Every card purchase is still a public transfer from one long-lived Safe to one well-known settlement address, so anyone can read a cardholder's spending amounts and timing and identify the Safe as a Gnosis Pay card. There are no fresh addresses or privacy patterns. This is minimal linkage that is documented, so 2.
HesabPay	No evidence	No admissible evidence yet.
Hinkal	2 Partial	Private transfers inside the pool reveal only nullifiers and new commitments, and recipients use stealth addresses. Deposits reveal depositor, token and amount. Withdrawals reveal recipient, token and amount. Proofless deposits carry a plaintext orderId in calldata, and their UTXOs are emitted in plaintext. Amounts are arbitrary, not fixed denominations, so amount and timing matching across entry and exit is a behavioural risk; we note it here and do not score it. Judgment call: the core shielded transfer fits anchor 3, but the documented orderId and plaintext-UTXO path adds linkage, so we score 2.
Holyheld Card	0 Fails	Every top-up publishes a per-account receiver code next to the payer's address, so all top-ups to one Holyheld account can be linked onchain, and all top-ups visibly go to a single Holyheld wallet. I found no user-facing disclosure of this. Judgment call: the receiver code is a payee tag; with no disclosure found, this takes the lower anchor (0) rather than 1.
Houdini Swap	1 Weak	By design, the chain shows a plain transfer from the payer to a one-time partner deposit address and a separate payout from a partner wallet to the payee. There is no contract call or memo linking the two. The link exists off-chain, in partner logs and in Houdini's 72-hour transaction data. Amount and timing correlation remain possible, and the docs say so for the single-hop flow. We examined no sample transactions, so this rests on docs only and is capped at 1. Judgment call: the substance looks like anchor 2 (minimal onchain linkage, documented), held at the documented cap.
Hyperbeat Card	No evidence	No admissible evidence yet.
Jupiter Card	No evidence	No admissible evidence yet.
M-Pesa	No evidence	No admissible evidence yet.
MetaMask Card	2 Partial	No merchant or order data goes onchain. Every card spend is still a public transfer from the cardholder's everyday wallet to a known Baanx address, and the FoxConnect approval flags the wallet as a MetaMask Card holder. Anyone can read spend amounts and timing. There are no fresh addresses. Minimal linkage that the provider discloses, so 2.
Opera MiniPay	0 Fails	Each payment is a plain stablecoin transfer, which links payer and payee publicly. In addition, MiniPay's issuer publishes onchain an attestation that ties each registered wallet address to an ODIS-obfuscated phone identifier. That marks the address as a MiniPay account, and anyone with ODIS quota can resolve a phone number to it. The user-facing privacy statement says no personal data goes to blockchain networks. Judgment call: the attestation is described in developer docs but not to users, so the linkage is treated as undisclosed; 0 rather than 1.
Monero	3 Strong	By default every payment goes to a one-time stealth address, hides the amount, and hides the spent output among 16 ring members. Fee, transaction size, input and output counts, timing and tx_extra contents are visible. The sender is hidden only probabilistically: decoy-selection and timing heuristics, and transactions that spend outputs created together, can narrow the ring; we record these in the finding and do not score them. Judgment call: we score what the protocol reveals by default, which is anchor 3.
Nullmask	No evidence	No admissible evidence yet.
Oobit Card	No evidence	No admissible evidence yet.
Payy Card	3 Strong	A card purchase is a shielded send inside the rollup. Ethereum sees only state roots and a proof, so nothing public links a cardholder to a purchase, a merchant or an amount. Deposits and withdrawals do expose an EVM address and an amount, which bridging needs. The design is a privacy pattern (UTXO notes, nullifiers, link-based sends). Judgment call: I did not observe how Payy funds Rain onchain. If that leg exists it carries Payy's aggregate, not a user's notes, so I scored 3. The privacy is against the public, not against Payy: the backend receives the note for each card debit, which falls under P2 and P4. The card-specific Polygon deposit addresses mentioned in the FAQ are outside the rollup and were not assessed.
Phantom Cash	Under review	Each card payment is a public transfer from a long-lived Cash address, so amounts and timing are visible; merchant data is not onchain. Judgment call: this is "minimal linkage, documented" (2), but no sample transaction could be tied to the debit-card contract, so it rests on documentation and is capped at 1.
Plasma One	2 Partial	No merchant data goes onchain, but each card funding is a public pull from a long-lived wallet into its own collateral, tagged with a Rain transaction id, so amounts and timing are linkable to the wallet. Public visibility is disclosed. Minimal linkage, documented, so 2. Judgment call: the sample is a Rain collateral on Plasma not confirmed as a Plasma One account.
Privacy Pools (0xbow)	3 Strong	The chain shows who deposited and how much, and who received and how much, but not which deposit funded which withdrawal. There is no memo or invoice field. Amounts are arbitrary, not fixed denominations, so an unusual amount withdrawn in full can be matched to its deposit; partial withdrawals and round amounts reduce that. The ASP sees nothing beyond the chain. Judgment call: amount matching depends on user choices and is noted here, not scored; on what the code reveals, 3.
Railgun	3 Strong	Shielding is public (who, which token, how much) and unshielding is public (to whom, which token, how much), but a private transfer between 0zk addresses reveals no sender, recipient, token or amount onchain; ciphertexts are encrypted to the parties. Linkage can come from the shield/unshield amounts and timing, and from self-signing with a known gas address (the Action event names the caller). Judgment call: behavioural linkage is noted, not scored; on what the code reveals, 3.
Request Network	0 Fails	Each payment event publishes the payee, amount, token, and a payment reference, and the token Transfer log names the payer. Request contents are unencrypted by default: payee, payer, amount, and in the invoicing flow line items and any buyer or seller contact details. They are stored in an IPFS swarm whose key is public. Their CIDs are anchored on Gnosis and indexed in plaintext by a public subgraph. Anyone can recompute the paymentReference from the stored requestId, salt, and address, and so join a Base payment to its invoice contents. Encryption (ECIES or Lit) exists, but it is opt-in. Judgment call: we score 0 and not 1. Order contents and optional emails are public by default via an onchain pointer, which matches anchor 0, even though the docs say storage is IPFS with optional encryption.
Rizon Card	No evidence	No admissible evidence yet.
SafePal Card	1 Weak	Every card spend is public and linked to the cardholder's account number, address, card id and amount, though not to the merchant. The linkage is disclosed in the terms. Account tags in events, disclosed, so 1.
Solayer Card (Emerald Card / Solayer Pay)	No evidence	No admissible evidence yet.
Tongo (confidential ERC-20 on Starknet)	1 Weak	Tongo hides transfer amounts but not who paid whom. Every transfer publishes the payer's and payee's Tongo public keys. Funding ties a Starknet address to a key, and withdrawal ties a key to a Starknet address, both with plaintext amounts. Users can make fresh keys, but each must be funded. Judgment call: payer-payee linkage is public by design and implied rather than stated in the docs, which stress hidden amounts. Between 1 and 0 we take 1, because the event schema is public in the repo.
Tornado Cash (Classic pools)	3 Strong	Onchain data shows who deposited and who received, but not which deposit paid which withdrawal. Amounts are fixed denominations, and there is no memo or invoice field. Linkage can still come from timing, distinctive gas or funding patterns, low pool activity, reused addresses, or the optional router EncryptedNote event, which ties the depositor's address to an encrypted note backup. Judgment call: anonymity-set size depends on user behaviour and is not scored; we score what the code and chain reveal, which is anchor 3.
Tria	No evidence	No admissible evidence yet.
Tuyo Card	No evidence	No admissible evidence yet.
Umbra Cash	3 Strong	Each payment goes to a fresh stealth address that observers cannot tie to the payee; the payer, amount and token are public. The link reappears if the payee withdraws to a known address, funds the stealth address from a known account, or batches withdrawals; the README states these limits. Judgment call: this is a stealth-address pattern with no invoice data, so 3 on what the code reveals; withdrawal hygiene is behavioural.
Wirex One	1 Weak	Every card purchase is published onchain against the user's wallet, with its type, currency and amount and a stable wallet address, so anyone can rebuild a cardholder's spending history. The linkage is disclosed in the privacy policy, so 1.
Wise	No evidence	No admissible evidence yet.
WORM (BETH proof-of-burn)	2 Partial	The chain shows a payer sending ETH to what looks like an ordinary address, and later a mint to the payee. The proof hides which burn funded which mint. Both amounts are plaintext and arbitrary, so the burned amount and the revealed amount, minus fees, can be matched. Partial reveals through spendCoin weaken this. Judgment call: 2, minimal linkage, because amounts are revealed. The size of the anonymity set and any timing correlation are behavioural, so we leave them out of the score.
XPlace Card	No evidence	No admissible evidence yet.
Zcash (shielded transfers)	3 Strong	A fully shielded payment reveals no payer, payee, amount or memo onchain; the fee, timing, transaction size and the number of actions are visible. Transparent addresses are fully public, as on Bitcoin, and moving between pools reveals the amount. The anonymity set depends on how many users stay shielded and on pool migrations, which we do not score. Judgment call: we score what the protocol reveals for a shielded transfer, which is anchor 3.
zERC20 (zBNB on BNB Chain)	2 Partial	The chain shows the sender paying an unknown burn address, and later a recipient minting via teleport, with no onchain link between the two. Amounts are plaintext and not fixed denominations, so unusual amounts and timing can link a payment to its redeem; the docs say so. Judgment call: 2 (minimal linkage, documented) rather than 3, because plaintext arbitrary amounts are revealed by the protocol itself. Anonymity-set size (17356 indexed zBNB transfers) is behavioural and not scored.