Censorship Resistance · C3
Hosted intermediary dependence
Does the payment flow require a relayer, paymaster, bundler, or API that only the provider runs?
Why it matters
Every required hosted service is a place where access can be withdrawn. Self-hostable code plus a default fallback turns a vendor outage or refusal into an inconvenience rather than a stoppage.
Scoring anchors
| No required relayer, paymaster, bundler, or API; or each has a documented self-host path with code in the repo and a fallback provider. | |
| Required intermediaries exist and their self-host code is public, but no fallback is configured by default. | |
| Intermediaries required, only documented, no public code. | |
| Required, closed, single-vendor. | |
| No admissible evidence submitted yet. Counts as 0 in the pillar. |
Admissible evidence
- SDK source at a pinned commit showing hardcoded endpoints verified
- Repository containing the intermediary's code verified
- Config files showing configurable endpoints verified
Common failures
- Relayer code is public but the SDK hardcodes the vendor URL with no override.
Current ratings
| Provider | Score | Finding |
|---|---|---|
| Aleo (credits.aleo private transfers) | No relayer or paymaster is needed, and any snarkOS node can take the transaction. Two things are hosted by Provable by default: the API endpoint, which the user can replace with their own node, and the proving parameters, which every client downloads from Provable's two URLs on first use. The parameter files are checksummed in public code, so a mirror is possible, but none is configured. Scored 2: required intermediaries with public code, no independent fallback by default. | |
| AnomaPay | The transaction service, prover and indexer are required in the documented flow and are run by Anoma; none of their code is among the anoma GitHub org's public repos. The docs say users can run this infrastructure themselves, but no code or fallback is published. Scored 1: required, documented, no public code. | |
| Avalanche Card | Every step of a card payment (app, collateral accounting, authorisation, issuing, settlement) runs on closed Rain-group services with no public code and no fallback. | |
| Avici Card | The card flow depends on Avici's closed backend (escrow creation, spending-power API, attestations, liquidation), Sumsub, Third National and Visa. None of these is public or has a fallback. | |
| Aztec (Alpha mainnet private token transfers) | No relayer, paymaster or company API is required. Users can run their own node from public code, sequencing and proving are open to stakers and provers, and the escape hatch is a fallback if the committee censors. Fees need Fee Juice bridged from L1, which is a protocol asset rather than a service. Aztec Labs' hosted RPC, network-config and snapshot hosts are conveniences with overrides. | |
| Bitget Wallet Card | Every card payment needs Fiat24's closed authorization service and key, Marqeta processing and Mastercard. None is public, and there is no fallback operator. Closed and single-vendor, so 0. | |
| Blanksquare (Shielder) | Settlement needs only the Shielder, a client-side prover and an RPC. The relayer is optional (withdrawManual), and its code is public. The official hosted relayer did not resolve in DNS on 2026-10-09, which leaves the direct path as the working one. Judgment call: as with Tornado Cash, withdrawing without a relayer needs gas in the withdrawing account and weakens privacy (P3); the cell measures settlement dependence, so 3. | |
| COCA Card | The card flow depends on COCA's closed backend, Privy, an unnamed card program provider and issuer, and Visa. None is public or has a fallback. Closed and single-vendor, so 0. | |
| Coinbase Commerce (Onchain Payment Protocol) | A Commerce payment needs three things only Coinbase runs and has not published: the Charge API, the operator key that signs each TransferIntent, and the merchant account. The public SDK can point at another RPC URL, but only Coinbase serves the cdp_ charge methods. On 2026-10-07 api.commerce.coinbase.com returned HTTP 503 and commerce.coinbase.com returned 502 to curl. Judgment call: we score 1 and not 0, because anchor 0 says single-vendor, and the protocol documents that anyone can register as an operator. No operator code exists to self-host, so it cannot be 2. | |
| Curvy | Several closed services that only Curvy runs are required. Shielding needs the Portal Broadcaster operator. The SDK needs the API for the network registry and protocol parameters, auth and notes sync. Proofs need circuit keys from Curvy's host. The SDK lets an integrator point these URLs elsewhere and submit planner transactions from its own wallet. But no self-host code is published, and the operator role is onchain and cannot be replaced by config. Scored 0. | |
| Daimo Pay | Each payment depends on three services that only Daimo runs: the Daimo API, which creates sessions and deposit-address parameters; the relayer, which is allowlisted by the owner EOA; and the price signer. No repository in the daimo-eth org contains code for the API, the relayer service, or the price signer. Self-hosting would not help even if that code were published, because a third-party relayer must first be added to the allowlist by Daimo. The SDK lets an integrator change the API URL, but no alternative backend exists to point it at. | |
| Deblock Card | Every card payment depends on Deblock's closed ledger and issuing systems and on Visa. Closed, single-vendor. | |
| Ethena Pay | A card payment needs Ethena Pay's closed backend (authorisation, executor co-signer, relayer), Rain, Third National and Visa. No component of that path is public or has a fallback. Ethena Pay publishes no repository at all. | |
| ether.fi Cash | Each card payment needs ether.fi's closed authorisation backend and wallet keys, its settlement bridger, the Turnkey enclave that holds the user's key, the Rain or Reap card programme, the issuer Third National, and Visa. None of these is public, and none has a fallback. The payment path is closed and single-vendor. | |
| Exa Card | Exa publishes its own backend, which is unusual for a card. A card payment still requires Rain's closed issuing platform, Third National and Visa, plus Exa's own keeper and issuer keys. The deployed IssuerChecker accepts only Exa's issuer key, so a self-hosted server could not settle against the deployed contracts. The required issuer path is closed and single-vendor, so 0. | |
| Fluidkey | In the product flow a payer gets a fresh address from Fluidkey's offchain ENS resolver or payment page, both run only by Fluidkey with no public code. The gas relayer is also Fluidkey's. Scored 0: required, closed, single-vendor. The kit lets a payee derive addresses themselves, which keeps funds recoverable (S4). | |
| Fuse Card | A card payment needs Bridge (KYC, authorisation, the spending-limit signer), Lead Bank, Visa and the closed Fuse app. All are closed and single-vendor. | |
| Gnosis Pay | The card flow requires Gnosis Pay's closed backend (authorisation, spend delegate, relayer) plus the issuer Monavate and Visa. None of it is public or has a fallback. Single-vendor and closed for the payment path. | |
| HesabPay | Every payment flow requires HesabPay's hosted services. No intermediary code is public (see notes for the search), so the dependency is closed and single-vendor. | |
| Hinkal | Settlement does not need Hinkal's relayer: the contract allows self-submission, and the SDK has a relayer-off mode. The Merkle path can be rebuilt from RPC events instead of the snapshot server. Every proof, however, needs the circuit wasm and zkey files that the SDK fetches from a hardcoded Hinkal URL, and they are published nowhere else. Remote proving through Hinkal's enclave is the SDK default. The enclave source is published, without a licence. The relayer and the snapshot and data servers are closed. Scored 1: a required provider-hosted artifact, with no public copy and no configurable fallback. | |
| Holyheld Card | Every top-up needs the Holyheld API (configuration, quotes, receiver code, backend signature), and the card itself needs the issuer and network. None of it is public, there is no self-host path and no fallback. Closed, single-vendor. | |
| Houdini Swap | The Houdini API and routing engine are required, closed and run only by Houdini. The exchange partners are also closed third-party services. There is no self-host path and no fallback operator. | |
| Hyperbeat Card | The card path depends on Hyperbeat's closed Operator and backend, an unnamed card issuer and Visa. None is public and there is no fallback. | |
| Jupiter Card | Every card payment needs Jupiter's closed Spend backend plus Rain or DCS and Visa. None is public and there is no fallback. Closed and single-vendor per user (each user gets one issuer, assigned by country). | |
| M-Pesa | Every integration depends on Safaricom's hosted API and on Safaricom provisioning shortcodes and credentials. No intermediary code is public and no fallback exists, so the dependency is closed and single-vendor. | |
| MetaMask Card | Every card payment needs Baanx's closed authorisation backend and its operator keys, plus Monavate and Mastercard. None of these is public and none has a fallback, so the card path is closed and single-vendor. | |
| Opera MiniPay | Using MiniPay requires an account with Blueboard's closed backend, reached only through Blueboard's closed app. No intermediary code is public and no alternative operator exists. The RPC endpoint the app uses was not identified. Judgment call: anchor 1 (documented, no public code) and anchor 0 (closed, single-vendor) both fit; took 0. | |
| Monero | No relayer, paymaster or API is required. A user can run monerod and a wallet locally; light users can point the wallet at any remote node, and the GUI's simple mode picks one from public nodes advertised on the P2P network rather than from a vendor list. All node code is public. | |
| Nullmask | The RPC proxy, relayer and guard are required, closed and run by one operator. Scored 0. | |
| Oobit Card | All flows depend on Oobit-run services, Rain, the issuer and Visa. None is public. Closed and single-vendor. | |
| Payy Card | A card payment needs Payy's closed backend and app, Rain, an unnamed U.S. issuer and Visa. None of these is public or has a fallback. The rollup node and prover code is public, but the deployed contract accepts blocks only from Payy's prover, so there is no fallback there either. | |
| Phantom Cash | The card depends on Phantom's closed app and on Stripe, Bridge, Lead Bank and Galileo. None is public and none has a fallback. 0. | |
| Plasma One | A card payment needs Plasma One's closed app and backend, Rain's signers and Visa. None is public and there is no fallback. Plasma publishes no Plasma One repository. | |
| Privacy Pools (0xbow) | Relayers are optional and their code is public, and the ASP tree data is on IPFS under the CID posted onchain. The ASP approval itself is a required, closed, single-vendor service: only 0xbow's postman can add a deposit to the root that withdrawals must prove against. Scored 0. | |
| Railgun | Settlement needs only the contracts, the SDK, the proving artifacts and an RPC. Broadcasters, the hosted Subsquid indexer and the POI aggregator are optional, and each has public code. Judgment call: self-signing without a broadcaster exposes the gas-paying address; that is a privacy cost (P3), not a settlement dependency, so 3. | |
| Request Network | On the open path, the only required intermediary is a Request Node, which stores the request and needs IPFS and a Gnosis RPC. Its code, a README setup guide, Docker images, and a Helm chart are all public. The SDK configures no fallback node; the reference template falls back to Request's hosted Gnosis gateway. No relayer, paymaster, or bundler is needed. Request Network's current docs describe only its hosted API, which is closed and single-vendor and would score 0. Judgment call: we score the open protocol path, because a payment completes without the API. We score 2 and not 3, because the SDK itself sets no fallback. Storing a request on Gnosis also needs the open hash submitter to stay whitelisted by Request's Safe (see C1). | |
| Rizon Card | Every card payment depends on Rain's closed platform, Privy and the issuer. No code is public and there is no fallback. Closed, single-vendor. | |
| SafePal Card | Every card payment needs Fiat24's closed authorization service and key, Marqeta processing and Mastercard. None is public, and there is no fallback operator. Closed and single-vendor, so 0. | |
| Solayer Card (Emerald Card / Solayer Pay) | Every payment depends on Solayer's closed wallet layer and backend, the issuer and Visa. None is public; no fallback. 0. | |
| Tongo (confidential ERC-20 on Starknet) | No relayer, paymaster, indexer or API is required. Proofs are made client-side, state comes from the RPC, and the user can pay gas from their own Starknet account. The optional Relayer path depends on AVNU's paymaster and on the Relayer owner's whitelists. | |
| Tornado Cash (Classic pools) | Settlement needs only the pools, a proof client and an Ethereum RPC. A relayer is optional: it exists so a withdrawer can pay gas from the withdrawn amount instead of from a funded account, which matters for privacy but not for settlement. The indexer is optional too, as the UI falls back to RPC event reads. Judgment call: we score 3 although withdrawing to a fresh address without a relayer needs gas from elsewhere, which can reduce privacy (see P3); the cell measures whether settlement depends on a hosted intermediary, and it does not. | |
| Tria | Required intermediaries (Tria backend, issuer, Visa) are closed and single-vendor. 0. | |
| Tuyo Card | The card requires Tuyo's closed app and backend, an unnamed card provider and issuer, and Visa. All are closed and single-vendor. | |
| Umbra Cash | Settlement needs only the contracts, the SDK and an RPC. The closed Umbra API relayer is optional: the stealth address can withdraw itself, or any account can submit its signed withdrawal. The indexer is optional too. Judgment call: withdrawing tokens without the relayer needs gas from elsewhere, which affects privacy, not settlement, so 3. | |
| Wirex One | Card debits need Wirex's API and oracle key, wallet signing goes through Privy, and user operations are sponsored by a Wirex paymaster. None of it is public or has a fallback. Closed, single-vendor. | |
| Wise | Every integration depends on Wise's hosted API, with credentials and access provisioned by Wise. None of the intermediary code is public and there is no fallback operator, so the dependency is closed and single-vendor. | |
| WORM (BETH proof-of-burn) | No hosted service is required. The CLI proves locally from public parameters and can broadcast from any key. Prover and broadcaster code is public (worm-miner server). Fees for a third-party prover or broadcaster are fixed in the burn commitment, so the market is open to anyone. The official one-page send flow does default to the WORM-run prover. Judgment call: 3, because the protocol path does not need it and the self-host code is in the repo; the frontend default is counted under P2 and P4. | |
| XPlace Card | Every card payment depends on XPlace's closed app and backend and on Rain. None is public or has a fallback. Closed and single-vendor. | |
| Zcash (shielded transfers) | No hosted service is required. A full-node user (Zebra plus Zallet) needs only peers. A light-wallet user needs a lightwalletd-compatible server; the code is public and self-hostable, and the reference wallet ships several independent default servers, picks one automatically, broadcasts each transaction to more than one, and accepts a custom server. | |
| zERC20 (zBNB on BNB Chain) | Two provider services sit in the required path. The root prover is single-vendor by contract design: only allowlisted addresses can prove roots. The hosted indexer supplies the Merkle proofs recipients need. The docs invite users to run their own indexer, but the official repository is not public. A snapshot of the monorepo, BUSL-1.1, exists under a personal GitHub account; it is not linked from the org, and running a prover from it would not help, because the contract allowlist still applies. The relay node and ICP canisters are optional. Scored 0: required, closed and single-vendor. |