Censorship Resistance · C4
Settlement-layer neutrality and disclosed edge filtering
Is the settlement layer free of address or geographic filtering, and is any filtering at the edge disclosed and avoidable?
Why it matters
Regulated providers often must screen sanctions lists, and an institution should expect them to. What matters is where the screening sits: filtering at the edge, disclosed, with a neutral settlement layer underneath, leaves the rail usable by anyone the law allows. Filtering hidden in the settlement contracts, or undisclosed anywhere, does not.
A score of 3 needs evidence naming the distributed package (name, version and integrity hash) or a network trace, not only source code in a repository.
The top score rewards the absence of a problem. It is only available when every required component in the request path is public, or a network trace covers the closed parts.
Scoring anchors
| Settlement contracts contain no address or geographic filtering, and any filtering in the SDK, frontend, or backend is disclosed in code or a versioned repo document, names its list source, and is bypassed by the direct settlement path (C2 at least 2). Requires every required component in the request path to be public, or a trace. | |
| Settlement contracts are neutral and edge filtering is disclosed, but it cannot be bypassed (C2 below 2). | |
| Edge filtering is disclosed in docs only, or the neutrality of the settlement layer cannot be shown from code. | |
| Undisclosed filtering anywhere, or filtering in the settlement contracts without disclosure (also lowers C1). | |
| No admissible evidence submitted yet. Counts as 0 in the pillar. |
Admissible evidence
- Search of SDK and frontend at a pinned commit for sanctions lists, IP geolocation calls, country gates verified
- Network trace from a running instance documented (trace)
Common failures
- Screening happens in a closed backend the SDK calls, so the code search finds nothing (score unknown, not 3).
Current ratings
| Provider | Score | Finding |
|---|---|---|
| Aleo (credits.aleo private transfers) | Settlement is neutral today: the consensus restrictions list is empty and credits.aleo has no address checks. Its existence is disclosed in code, and it would apply at the settlement layer, where no direct path could bypass it (scored under C1). We found no edge filtering in the node, CLI or SDK. The hosted Provable API and the closed consumer wallets may filter, and we could not inspect them. Judgment call: 2, not 3, because 3 needs a distributed-package or trace record and because the settlement layer carries a filtering mechanism, even if empty. | |
| AnomaPay | The settlement contracts are neutral. Filtering, if any, sits in the closed proving service: the docs say its operator "implements consistent checks" for KYC and AML, while the terms say the Foundation does not monitor transactions. No list source is named and no code is public, and the direct path is not practically available (C2). Scored 1: disclosed in documents only, and the two documents disagree. | |
| Avalanche Card | Sanctions screening is disclosed in the card agreement and privacy policy. The settlement layer cannot be inspected, so its neutrality cannot be shown. Disclosed in docs only, so 1. | |
| Avici Card | Screening is disclosed in the terms but runs in closed services. The settlement contract is undisclosed, so its neutrality cannot be shown. Docs only, so 1. | |
| Aztec (Alpha mainnet private token transfers) | Settlement is neutral: the rollup and the reference token have no address or country checks, and private senders and recipients are not visible to sequencers. The setup-phase allowlist restricts which public functions may run before fees are paid, which shapes fee payment but does not target users. Aztec Labs' hosted RPC sits behind a Cloud Armor policy (spartan/environments/mainnet.env) whose rules are not public. Judgment call: 2, not 3, because 3 needs a distributed-package or trace record and because the hosted RPC's filtering is undisclosed (users can avoid it by running a node). | |
| Bitget Wallet Card | Address filtering sits inside the settlement layer itself: the cash tokens check an onchain sanctions oracle and the account's KYC status on every transfer, including the card pull. Judgment call: the check is visible in Sourcify-verified source, but no Fiat24 or Bitget document discloses contract-level screening or its list source, so this takes the lower anchor, 0, rather than 1. | |
| Blanksquare (Shielder) | The settlement contract is neutral. Edge filtering is set out in the terms (country list, sanctioned persons, PEPs, a reserved right to geo-block), not in code or a versioned repo document, and the official apps that would enforce it are closed and now offline, so we could not see what they did. The direct contract path bypasses any app-level filter. The docs also describe an anonymity revoker and a "Shielder Guard" (description marked work in progress). Scored 1: edge filtering disclosed in documents only. | |
| COCA Card | Geographic and sanctions restrictions are disclosed in the terms and docs. The settlement layer is undisclosed, so its neutrality cannot be shown. Docs only, so 1. | |
| Coinbase Commerce (Onchain Payment Protocol) | The settlement contract has no address or geographic filter. Filtering sits at the edge: Coinbase, as operator, can refuse to sign an intent. The README says this power exists, and the Terms name the sanctions lists Coinbase applies to merchants. A payee who acts as its own operator bypasses it (C2). The cell misses 3 for two reasons. The disclosure in the repo does not name a list source; only the Terms do. And the API and signer that apply the filter are closed, so we cannot see what they screen in practice, including payer screening. No trace was run. | |
| Curvy | Edge screening (Global Ledger, run by the Curvy-operated broadcaster) is disclosed in a versioned docs repo, and the contracts contain no address or country list. The screening cannot be bypassed: entry to the pool is operator-gated onchain, and the direct entry is disabled. A screened-out payee can only recover funds publicly through the portal recovery path. The list source is named, but the scoring rules live in a closed backend. Judgment call: the settlement layer is not neutral, because entry depends on a screened operator, so we score 1 rather than 2. | |
| Daimo Pay | Re-assessed under the updated anchor (neutral settlement plus disclosed, bypassable edge filtering). The SDK contains no address or geographic filtering. The closed API decides which payment methods a user sees by country, and the docs disclose this. The terms reserve a blanket right to deny access, including by IP, without naming any list. The settlement contracts hold no list, but only Daimo's allowlisted relayers can forward a deposit, so whether settlement is neutral cannot be shown from code, and there is no direct path to bypass edge filtering (C2 = 0). Both of those facts match anchor 1. Judgment call: we score 1 and not 0 because the only filtering we can see is disclosed in docs and terms, and we have no evidence of undisclosed screening; we could not rule it out either, because the API and relayer are closed. A trace or provider statement showing screening not covered by those documents would lower this to 0. A 3 is not reachable while required components are closed and no trace exists. | |
| Deblock Card | No admissible evidence yet. | |
| Ethena Pay | Sanctions and jurisdiction screening exists and is disclosed in the Terms; it runs in Ethena Pay's closed backend and at Sumsub, so the neutrality of the settlement layer cannot be shown from code. The relayer contract's recipient allowlist restricts where card spends can go, not who can pay. Screening cannot be bypassed because there is no direct settlement path (C2 = 0). Disclosed in docs only, so 1. | |
| ether.fi Cash | The settlement contracts contain no address or geographic filtering. Sanctions and country screening is disclosed in the Terms and cardholder agreements, and it runs in the closed KYC/backend and at the issuer. It cannot be bypassed, since C2 = 0, and it is not disclosed in code or a versioned repo document. Edge filtering disclosed in docs only = 1. | |
| Exa Card | The Optimism settlement contracts (ExaPlugin and the standard exaUSDC market) have no address or country filter; the Firewall allowlist exists only on Base. Edge screening is disclosed in the terms, but it runs inside closed vendors with no named list source in code, and it cannot be bypassed because C2 = 0. Disclosed in docs only, so 1. | |
| Fluidkey | The settlement layer (token transfers into Safes) has no filtering. Screening exists in Fluidkey's closed backend and is disclosed only in the privacy policy and terms; we cannot see where it applies or whether address issuance is refused. Scored 1: edge filtering disclosed in docs only. | |
| Fuse Card | The settlement program is neutral. Geographic eligibility is disclosed as a country list in the docs, and screening runs in Bridge's closed KYC. With C2 at 0 there is no way around it. Disclosed in docs only, so 1. | |
| Gnosis Pay | Re-assessed against the revised anchor. The settlement contracts are neutral: Spender.spend() and the Roles scope contain no address list or geographic check. Edge filtering exists. The Terms exclude people on UN, EU, US or UK sanctions lists and residents of sanctioned countries, and forbid VPNs used to get around this; screening runs in Sumsub and the closed backend. That disclosure is in the hosted Terms only. Neither the frontend code nor the versioned docs repo describes the screening or names its list source. The card path has no direct route (C2 = 0), so the filtering cannot be bypassed. Anchor 1 ("edge filtering is disclosed in docs only") fits. A 2 would need disclosure in code or a repo document, and a 3 would also need a bypass and public required components. Note: which spends are executed is decided offchain by the delegate key (see C1), so the contracts are neutral but the settlement step as a whole is not. | |
| HesabPay | HesabPay discloses, in its terms and privacy policy only, that it monitors transactions for AML and fraud, applies jurisdiction-based limits, and terminates accounts on court or government order. It names no screening list. There is no separate settlement layer: filtering and settlement both happen in HesabPay's closed ledger, so the neutrality of settlement cannot be shown from code, and no direct path bypasses the filtering (C2 = 0). Judgment call: anchor 1 ("edge filtering disclosed in docs only, or the neutrality of the settlement layer cannot be shown from code") rather than 0, because the filtering read is disclosed and nothing read shows undisclosed filtering; the ledger is closed, so undisclosed filtering cannot be ruled out either, and a trace or internal document showing it would lower this to 0. Documented tier caps the cell at 1. | |
| Hinkal | The deployed contracts carry no address or country filter. Screening (Chainalysis) is disclosed in the docs, terms and privacy policy, and the direct contract path (C2) should bypass it. The docs describe enforcement that the contracts do not show: proofs checked against live Chainalysis state, and flagged funds limited to public withdrawal. That enforcement can only sit in Hinkal's closed backend or relayer. The SDK names a /check-risk route and a compliance-server path, but neither the screening logic nor its effect on self-submitted proofs is visible in code. Scored 1: the filtering is disclosed in docs only, and where it is enforced cannot be shown from code. | |
| Holyheld Card | Sanctions, PEP and wallet screening are disclosed in the privacy policy and run in Holyheld's closed backend and its vendors. Whether the settlement contract itself filters cannot be shown, because its implementation is unverified, and the screening cannot be bypassed (C2 = 0). Disclosed in docs only, so 1. | |
| Houdini Swap | Filtering sits in the settlement path itself. The exchange partners that hold and convert the deposit screen every deposit and can require KYC, and the ToS leaves the results to their sole discretion. Houdini adds IP geolocation, Tor blocking and wallet screening at its own edge. The categories are disclosed but the criteria and list sources are not: "sanctioned countries" are not named, and partner rules are unpublished. Nothing can be bypassed, because C2 = 0. Judgment call: 0 (filtering partly undisclosed and in the settlement path) rather than 1 (disclosed in docs only). | |
| Hyperbeat Card | Sanctions and jurisdiction screening is disclosed in the Terms only; the contracts are unverified, so settlement-layer neutrality cannot be shown. 1. | |
| Jupiter Card | Geographic and KYC gating is disclosed in the docs; where and how it runs (Jupiter backend, SumSub, issuer) is not inspectable, and it cannot be bypassed because there is no direct path (C2 = 0). Disclosed in docs only, so 1. | |
| M-Pesa | Re-assessed under the updated anchors on 2026-10-07; still unknown. The NPS Regulations require transaction screening (reg 31, see context), but no Safaricom document read discloses what M-Pesa filters: a search of all 31 Daraja API docs (populateApi) for sanction, AML, blacklist, watchlist and KYC found only KYC fields for organisation operators and a C2B error code "Invalid KYC Details", and the customer terms and privacy statement returned 403. Settlement runs in Safaricom's closed ledger, so neither disclosure nor its absence could be shown. | |
| MetaMask Card | FoxConnect itself has no address or country filter. Sanctions and country screening exist and are disclosed in the terms, but they run in the closed Baanx backend and cannot be bypassed, because there is no direct settlement path (C2 = 0). Disclosed in docs only, so 1. | |
| Opera MiniPay | Geographic and sanctions gating at the app edge is disclosed in the terms. The terms do not name the list source or the country list. Whether the closed app or backend filters addresses or transactions cannot be checked from code. The settlement layer (Celo plus the stablecoin contracts) is outside MiniPay and was not examined here. | |
| Monero | The settlement layer is neutral: consensus has no address or country rules, and recipients are unlinkable one-time addresses. We found no screening in the node, the CLI or the GUI. A remote node can refuse to relay, but the wallet can switch node or use its own. Judgment call: the substance fits 3, but 3 needs a distributed-package or trace record for the client, which we do not have, so we take 2. | |
| Nullmask | Filtering sits in the settlement path itself (guard approval of each deposit, screening of withdrawal recipients) and is disclosed in docs and terms, but the contract source is unpublished and the analytics vendor is unnamed. It cannot be bypassed. Judgment call: 1 (disclosed in documents only) rather than 0, since the filtering is disclosed. | |
| Oobit Card | Sanctions and geography screening, plus blockchain-analytics monitoring, is disclosed in the terms and on the product pages, but not in code. The settlement layer cannot be inspected. Disclosed in docs only, so 1. | |
| Payy Card | The settlement contract has no address or country filter. Sanctions and region screening exists: it is disclosed in the privacy policy and Terms and visible as KYC rejection reasons in public code, but it runs in closed services, and with C2 at 0 there is no way around it. Judgment call: the screening logic and its list sources are not public, so I took 1 (the Gnosis Pay precedent) rather than 2. | |
| Phantom Cash | Sanctions and geographic gating is disclosed in policy and help pages. It runs in closed services and cannot be bypassed (C2 = 0). 1. | |
| Plasma One | Geographic and sanctions restrictions are disclosed in the Terms and enforced in the closed backend, Rain and Sumsub, so the neutrality of the settlement layer cannot be shown from code and the screening cannot be bypassed (C2 = 0). Disclosed in docs only, so 1. | |
| Privacy Pools (0xbow) | Filtering sits in the settlement contracts by design: the pool accepts a private withdrawal only for deposits the ASP has approved. It is disclosed in the versioned terms and ASP docs, but the screening criteria and data vendors are not named, and the private path cannot bypass it; only ragequit (to the depositor) does. Judgment call: anchor 0 is for filtering in the contracts without disclosure, and this is disclosed, so 1. | |
| Railgun | The settlement contracts are neutral toward addresses and countries. Edge filtering is in public code with named list sources (an OFAC list in the SDK; Chainalysis's OFAC list for Railway's POI), and the direct contract path bypasses both (C2 = 3). npm @railgun-community/wallet 10.9.0 has gitHead 5c9d04c8, the pinned commit. All required components are public. Noted: the SDK check lower-cases the address but the list holds checksummed addresses, so at this commit it never matches; the filter is disclosed but ineffective. | |
| Request Network | The settlement contracts do no address or geographic filtering, and neither do the public SDK, Request Node, and reference frontends. The one filter we found is opt-in KYT screening on Request's hosted Secure Payment page. It is disclosed in the versioned docs repo, its list providers are named, and a payer can bypass it with the direct contract call scored in C2. All required components on the open path are public. Request's hosted API and gateways are closed or of unknown build. We cannot rule out screening inside them, but neither is required to pay. No network trace was run. | |
| Rizon Card | Sanctions and geographic screening is disclosed in the Terms, with the list sources named. Whether the settlement contracts filter cannot be checked, because no contract is identified. Disclosed in docs only, so 1. | |
| SafePal Card | Address filtering sits inside the settlement layer itself: the cash tokens check an onchain sanctions oracle and the account's KYC status on every transfer, including the card pull. Judgment call: the check is visible in Sourcify-verified source, but no Fiat24 or SafePal document discloses contract-level screening or its list source, so this takes the lower anchor, 0, rather than 1. | |
| Solayer Card (Emerald Card / Solayer Pay) | Geographic and sanctions filtering is disclosed in docs (also versioned in the public solayer_docs repo) and enforced in closed services. It cannot be bypassed (C2 = 0). 1. | |
| Tongo (confidential ERC-20 on Starknet) | The contracts and SDK contain no filtering. The demo frontend is closed and was not inspected. The Relayer's whitelists cover ledgers, assets and forwarders, not users. Judgment call: 3 needs a package or trace, and the Starknet sequencer is a further point of filtering outside this code, so 2. | |
| Tornado Cash (Classic pools) | The pools are neutral: no address or country filtering. The archived classic UI screens the connecting wallet against the Chainalysis sanctions oracle and sends listed addresses away. The check is visible in public code, the list source is identified by its oracle address, and the direct pool path bypasses it. tornado-core's cli.js has no screening. Judgment call: this fits anchor 3 in substance, but 3 needs a distributed package or trace for the client, and we also did not inspect the build currently served at tornadocash.eth, so we take 2. | |
| Tria | Sanctions screening is disclosed in the Terms only; no code or contracts show where it runs, and it cannot be bypassed. 1. | |
| Tuyo Card | Geographic and sanctions filtering is disclosed in docs. The card settlement contracts could not be inspected, so the neutrality of the settlement layer cannot be shown. 1. | |
| Umbra Cash | The contracts are neutral. The SDK screens addresses against public lists and the Chainalysis oracle, visibly in code, and the direct contract path bypasses it (C2 = 3). Judgment call: this meets anchor 3 in substance, but the repo's umbra-js 0.3.0 is not on npm (latest is 0.2.2), so there is no package to pin and we ran no trace; 2. | |
| Wirex One | The contracts let the admin decide which user operations are allowed, and the Terms disclose address blocking for sanctions or risk policy, without naming a list. The filtering is disclosed in the Terms, and the settlement layer is not shown to be neutral, so 1. | |
| Wise | Wise screens at its own ledger, which is also the settlement layer. Sanctions restrictions are disclosed in the Acceptable Use Policy without a named list source. Wise states that it does not fully disclose how its automated fraud controls, which can reject transactions, work. Judgment call: that admission of partly undisclosed filtering is taken as anchor 0 rather than 1. | |
| WORM (BETH proof-of-burn) | The settlement contracts and the official clients contain no address or country filtering, and the direct path needs no provider service. Whether the hosted prover filters requests could not be seen. Judgment call: the substance fits 3, but 3 needs a distributed package or a trace, so 2. | |
| XPlace Card | Sanctions and geographic screening is disclosed in the Terms and runs in XPlace's closed services, not in public code. The card path cannot bypass it (C2 = 0). Disclosed in docs only, so 1. | |
| Zcash (shielded transfers) | The settlement layer is neutral: consensus has no address or country rules, and shielded parties are not visible. We found no screening in the node, the beta full-node wallet, lightwalletd, or the reference mobile wallet. A light-wallet server operator could refuse to relay a transaction, but the wallet can switch server or the user can run a node. Optional swaps run through NEAR intents operators whose screening we did not inspect. Judgment call: the substance fits 3, but 3 needs a distributed-package or trace record for the client, which we do not have, so we take 2. | |
| zERC20 (zBNB on BNB Chain) | Filtering is built into the settlement contracts. The token checks every sender and recipient against an owner-maintained Blocklist, so no direct path avoids it. The filter is disclosed in the docs, and the list source is named as OFAC, but its contents are set by the owner Safe. The terms describe these parameters as operating "without human intervention or discretion by the Operator", which the owner-only blockAddress function contradicts. Judgment call: anchors 2 and 3 require a neutral settlement layer. The filtering is disclosed, so not 0. We take 1. |