Privacy · P2

Data collected beyond settlement needs

Does the flow collect anything beyond addresses, amounts, token, and chain?

Why it matters

Every extra field collected is a field that can leak, be subpoenaed, or be sold. Settlement needs very little. Regulated rails must collect identity data; the rubric credits collection limited to the legal requirement and disclosed with its basis, and marks down anything beyond it.

Scoring anchors

3 Strong	Only what settlement requires (addresses, amounts, token, chain).
2 Partial	Additional fields are either optional and clearly optional in code, or legally required, limited to that requirement, and disclosed with their legal basis in code or a versioned repo document.
1 Weak	Collection beyond settlement needs, disclosed in a policy only.
0 Fails	Undisclosed collection, or collection beyond the stated legal requirement.
No evidence	No admissible evidence submitted yet. Counts as 0 in the pillar.

Admissible evidence

API schema and form code at a pinned commit verified
Privacy policy (may only lower the score) documented

Common failures

Treating a regulated card or mobile-money flow's KYC as undisclosed when the policy discloses it.

Current ratings

Provider	Score	Finding
Aleo (credits.aleo private transfers)	3 Strong	The protocol collects only what settlement needs. No required component holds account or identity data. Optional Provable services see more: the hosted API sees the submitting IP, and the record-scanning service, if used, needs the user's view key.
AnomaPay	1 Weak	Beyond settlement data, the service collects account, device and network data and sees every transfer's sender, receiver, asset and amount in clear while proving; the docs also mention KYC/AML checks. Disclosed in documents. Scored 1.
Avalanche Card	1 Weak	Full KYC, including biometrics, is collected and disclosed in policy only. Collection goes well beyond settlement needs. Disclosed in policy, so 1.
Avici Card	1 Weak	Full KYC, including biometrics, is required for the card and disclosed in policy only. The wallet alone needs none. Collection goes beyond settlement needs. Disclosed in policy, so 1.
Aztec (Alpha mainnet private token transfers)	3 Strong	The protocol and reference token collect only what settlement needs, and no required component holds identity data. A third-party node, if used, sees the user's IP and queries (P4).
Bitget Wallet Card	1 Weak	Full KYC is required and disclosed in Fiat24's and Bitget Wallet's privacy policies; the legal basis (Swiss AML) is stated in the terms but not limited in code or a repo document. Disclosed in policy, so 1.
Blanksquare (Shielder)	1 Weak	Through the SDK the protocol collects settlement data plus an anonymity-revoker ciphertext and MACs that let the revoker link an account's actions; the docs disclose this, but no legal basis is stated. The apps also collect IP, location and analytics data under the privacy policy. Scored 1: collection beyond settlement, disclosed in documents.
COCA Card	1 Weak	Identity and location data beyond settlement needs are collected for the card and disclosed in the policy only. Disclosed in policy, so 1.
Coinbase Commerce (Onchain Payment Protocol)	1 Weak	The public SDK request carries only what settlement needs. The privacy policy says Commerce also collects device, IP and cookie data. It analyses payers' wallet addresses on public chains, and it lets merchants collect further customer fields at checkout. All of this is disclosed only in the policy. The hosted checkout's form code is closed, so we could not see which fields are optional.
Curvy	1 Weak	Beyond settlement data, the flow involves a Curvy ID handle registered through the API, an auth signature, compliance flags from Global Ledger, and portal metadata held by Curvy. The canonical app does no KYC. This is disclosed in policy only. Scored 1.
Daimo Pay	1 Weak	Re-assessed under the updated anchor; the score is unchanged. In code, the crypto deposit flow asks only for what settlement needs. The privacy notice says IP, device, and location data are collected on every flow. That is collection beyond settlement needs, it is not legally required, and it is disclosed only in the policy, which is anchor 1. KYC applies only to fiat flows, which the code keeps separate. The policy says that KYC is required by applicable law, but it names no specific requirement, and neither the basis nor the limit appears in code or a versioned repo document, so the KYC fields alone could not reach 2 either. Following the common-failures note, we do not treat that KYC as undisclosed.
Deblock Card	No evidence	No admissible evidence yet.
Ethena Pay	1 Weak	Collection goes well beyond settlement needs (identity, biometrics, source of funds, device data). It is disclosed in the privacy policy, with GDPR lawful bases for EEA/UK users, but not in any code or versioned repo document, so the documented cap applies: 1.
ether.fi Cash	1 Weak	KYC is legally required for the card and is disclosed with its basis, but only in the hosted policy, not in code or a repo document. Collection also goes beyond the KYC requirement (behavioural biometrics, device fingerprint, marketing). Disclosed in policy only = 1.
Exa Card	1 Weak	Full KYC, including biometrics, is collected for the card. The basis is given only loosely ("Visa regulations") in a versioned doc, and the field list is disclosed in the privacy policy. Collection goes well beyond settlement needs. Judgment call: a stated basis without a field-level limit to the legal requirement does not reach 2, so 1.
Fluidkey	1 Weak	Beyond settlement data, Fluidkey holds the user's viewing-key node (and so the full payment history), login and contact data, and risk signals; KYC applies only to the optional Bank feature. All of it is disclosed in the policy and docs, not limited in code. Scored 1.
Fuse Card	1 Weak	The regulated card requires full KYC. It is disclosed in the policy and is beyond settlement needs, so 1.
Gnosis Pay	1 Weak	Re-assessed against the revised anchor. Full KYC is required for the regulated card: identity documents, a biometric photo, source of wealth and expected spending, collected through Sumsub. The privacy policy discloses each category and gives a legal basis for each purpose: the contract, a legitimate interest in enabling the regulated partner's KYC and AML checks, and explicit consent for biometrics. The partner docs repo and the frontend show the KYC step. Anchor 2 now credits legally required collection disclosed with its legal basis, but only when that disclosure is in code or a versioned repo document. Here the legal basis appears only in the hosted policy, so the documented cap of 1 applies. Judgment call: the policy also covers processing beyond the KYC and AML requirement, namely marketing data, analytics and advertising cookies, and legitimate-interest use of transaction and device data to improve and market the product. The cookie and marketing items are consent-based. I read the whole as collection disclosed in a policy (1) rather than undisclosed or beyond-requirement collection (0). A stricter reading of the legitimate-interest uses would give 0.
HesabPay	0 Fails	KYC collection (name, date of birth, national ID or passport) is disclosed in the privacy policy with a stated legal basis (Da Afghanistan Bank KYC/AML rules); on its own that would score 1, since the basis is disclosed in a policy, not in code or a versioned repo document. But the same policy discloses automatic collection of app usage data (features accessed, transaction frequency, session duration) for product improvement, which goes beyond the stated legal requirement, and the updated anchor 0 covers "collection beyond the stated legal requirement". Score lowered from 1 to 0 on HesabPay's own policy text. Judgment call: usage data is read as collection by the payment flow because the policy ties it to the app that runs payments; device and location data for fraud prevention and the agent finder were not counted against the score.
Hinkal	1 Weak	The protocol itself needs only addresses, amounts and tokens. The apps add analytics and wallet-address screening. Deposits over $10,000 in Hinkal's own apps need a CEX-ownership or zkKYC attestation. All of this is disclosed in policy and docs, not in code. Scored 1.
Holyheld Card	1 Weak	Card use requires full KYC and screening beyond settlement needs. It is disclosed in the privacy policy, not in code or a versioned repo document, so 1.
Houdini Swap	1 Weak	Collection goes beyond settlement needs. Houdini takes the IP address, plus browsing and general location data in the web app. The reference API integration forwards the end user's IP, user agent and timezone. Partners can additionally require KYC under their own rules. All of this is disclosed in the privacy notice and docs, and the 72-hour retention is a mitigation. Disclosed in policy only, so 1.
Hyperbeat Card	1 Weak	Collection beyond settlement needs (identity verification) is disclosed in the privacy policy only. 1.
Jupiter Card	1 Weak	KYC data beyond settlement needs is collected and its legal purpose is stated, but only in hosted docs; no privacy policy for Jupiter Spend was found. Documented cap, so 1.
M-Pesa	0 Fails	Each C2B payment sends the payee the payer's name as held in the M-Pesa register and a partial phone number (v2) or an enumerable SHA-256 of it (v1); settlement does not need either. Re-assessed under the updated anchors: 1 needs collection beyond settlement needs "disclosed in a policy", and 0 covers undisclosed collection or collection beyond the stated legal requirement. The only disclosure read is the integrator documentation; Safaricom's data privacy statement returned 403, so no payer-facing disclosure and no stated legal basis for passing the name to payees was read. The National Payment System Regulations, 2014 (see context) require Safaricom to keep a register of customer ID details (reg 12), not to pass customer names to payees. Score lowered from 1 to 0. Judgment call: between 1 and 0 the lower anchor is taken because the evidence for 1 (policy disclosure within a stated legal requirement) was not seen; a reviewer who can read the privacy statement and finds a disclosed legal basis for this sharing could restore 1.
MetaMask Card	1 Weak	Full KYC is required and is disclosed with a legal basis in the terms, but only in policy documents, not in a code or repo document. Collection goes well beyond settlement needs. Disclosed in policy, so 1.
Opera MiniPay	0 Fails	MiniPay collects identity, device and behavioural data and links transactions to a user ID, well beyond addresses and amounts. All of this is disclosed in the privacy statement, and part of it is used for marketing and product analytics rather than any legal requirement. Judgment call: anchor 1 (disclosed in a policy) and anchor 0 (collection beyond the stated legal requirement) both fit; took 0.
Monero	3 Strong	The flow collects only what settlement needs: a transaction whose outputs, amounts and optional encrypted payment ID are readable only by the recipient. No required component holds an account or identity. A remote node, if used, sees the user's IP and the transactions and outputs they request (see P4).
Nullmask	Under review	The operator holds every user's viewing keys and can link deposits to transfers and withdrawals; screening also covers connected addresses and fund sources. Disclosed in terms and docs. Scored 1.
Oobit Card	1 Weak	KYC plus profile data (education, job title) goes beyond settlement needs. It is disclosed in the policy, so 1.
Payy Card	1 Weak	The regulated card requires full KYC. The fields are disclosed in the docs and visible in code, but no legal basis is given in the repo. Disclosed beyond settlement needs, so 1.
Phantom Cash	1 Weak	KYC is legally required and its basis is disclosed, but only in a hosted policy, and Phantom also keeps merchant location data for card transactions. Documented cap, so 1.
Plasma One	1 Weak	Collection goes beyond settlement needs (identity documents, biometrics, AML data) and is disclosed in the privacy policy only. 1.
Privacy Pools (0xbow)	1 Weak	The protocol needs only settlement data, and the ASP screens the public deposit address. The website and 0xbow collect more (analytics, device data, marketing), disclosed only in the privacy policy, which does not limit collection to a legal requirement. Scored 1.
Railgun	3 Strong	The flow collects only what settlement needs; there is no sign-up, KYC or form. A broadcaster, if used, sees the transaction it relays and its fee; a POI node sees blinded commitments. Railway states it collects no logs, a claim we did not verify.
Request Network	1 Weak	The bare SDK asks only for settlement fields and makes invoice content optional, which on its own would score 2. The reference invoicing flow requires line items, and invites buyer and seller identity, beyond what settlement needs. Request's hosted services collect names, email, IP, usage data, and bank details. That collection is disclosed only in the privacy policy, and it serves analytics and marketing as well as legal duties. Judgment call: we score 1 and not 2, because the default flows go beyond settlement needs and the only disclosure is the policy.
Rizon Card	1 Weak	KYC and screening data are collected beyond settlement needs and disclosed in the privacy policy only, so 1.
SafePal Card	1 Weak	Full KYC is required and disclosed in Fiat24's policy and SafePal's FAQ; the legal basis (Swiss AML) is stated in the terms but not limited in code or a repo document. Disclosed in policy, so 1.
Solayer Card (Emerald Card / Solayer Pay)	1 Weak	KYC plus occupation and salary goes beyond settlement needs. It is disclosed in the guide, with no stated legal basis. 1.
Tongo (confidential ERC-20 on Starknet)	3 Strong	The protocol collects nothing beyond keys, amounts and addresses, and no required component holds user data. The canonical v2 ledgers were deployed without an auditor (get_tongo_config returned Option::None at block 16117583), so no third party receives decryptable copies of balances. Per the docs, an auditor cannot be added later. Instances deployed with an auditor would score lower.
Tornado Cash (Classic pools)	3 Strong	The protocol collects only what settlement needs: a commitment at deposit, and recipient, relayer and fee at withdrawal. No required component holds account, identity or contact data. An optional relayer sees the recipient and the proof it relays.
Tria	1 Weak	Collection beyond settlement needs (identity documents, biometrics) is disclosed in the privacy policy only. 1.
Tuyo Card	1 Weak	Card KYC is required and its existence is disclosed, but the policy does not list the card KYC fields or a legal basis. Judgment call: disclosed in docs, so 1. It could be 0 because the policy is stale.
Umbra Cash	2 Partial	The protocol takes only a stealth address, amount, token, ephemeral key and ciphertext; there is no account or form. The hosted app's servers and the Umbra API log IP addresses, disclosed in a privacy policy committed to the repo and avoidable by using the SDK. Judgment call: the only extra data is IP logging on optional hosted services, disclosed in a versioned document, so 2 rather than 1.
Wirex One	1 Weak	KYC and profile data go well beyond settlement needs. This is disclosed in the privacy policy, not in code or a versioned repo document, so 1.
Wise	0 Fails	KYC collection is legally required and disclosed with its legal basis. Wise also collects device, behavioural and location data, and shares contact data for advertising, all beyond the legal requirement. Everything is disclosed in the privacy notice. Judgment call: anchor 1 (disclosed in a policy) and anchor 0 (collection beyond the stated legal requirement) both fit; took 0.
WORM (BETH proof-of-burn)	1 Weak	The protocol needs nothing beyond the burn and mint data, and the CLI sends nothing elsewhere. The official one-page send flow, however, hands the WORM-run prover the burn key and receiver, which link the payer's burn to the payee. The prover cannot redirect funds, but it learns the payment. The code shows this, but no policy or UI text discloses it. Judgment call: anchor 2 needs the extra data to be clearly optional, and in this flow it is not. Anchor 0 means undisclosed collection, but this is visible in public code. We take 1, the lower of the two remaining anchors.
XPlace Card	1 Weak	KYC and biometric data are collected beyond settlement needs. Their legal basis is disclosed, but only in a hosted policy, not in code or a versioned repo document. Documented cap, so 1.
Zcash (shielded transfers)	3 Strong	A transfer needs only the signed transaction; a shielded output carries the recipient, amount and an optional memo encrypted to the recipient. No component on the required path holds an account, identity or contact data. The mobile wallet's optional swaps and merchant payments go to third parties with their own data needs. Judgment call: we score the default send flow, which is anchor 3.
zERC20 (zBNB on BNB Chain)	1 Weak	Onchain, the flow needs only addresses and amounts, and burn-address secrets are delivered encrypted through ICP canisters. The required hosted indexer, however, learns which recipient is querying which burn events, and with them the IP address and timing. That is collection beyond settlement needs, disclosed only in docs. Scored 1.