Censorship Resistance · C2
Direct settlement path
Can a payer or payee complete settlement by calling the public contracts directly, without the provider's API, signer, or relayer?
Why it matters
If settlement only works through the provider's servers, the provider can refuse service to anyone and an outage stops your cash flow. A documented direct path means the contracts, not the company, are the rail.
A score of 3 needs onchain evidence about the deployed contracts, not only source code at a commit.
Scoring anchors
| A payer or payee can complete settlement by calling the public contract directly, with the ABI and addresses documented. | |
| Possible but undocumented; reconstructable from verified source. | |
| Partial (for example settle but not refund or withdraw), or documented only. | |
| Settlement requires the provider's API, signer, or relayer. | |
| No admissible evidence submitted yet. Counts as 0 in the pillar. |
Admissible evidence
- Contract entrypoints and modifiers at a pinned commit verified
- A reproduced direct call with written steps documented (trace)
Common failures
- Entry point is public but checks a provider signature, so it is not really direct.
- Refund path is owner-only.
Current ratings
| Provider | Score | Finding |
|---|---|---|
| Aleo (credits.aleo private transfers) | A payer can build and prove a transfer locally and submit it to any Aleo node, with no Provable service in the path, using the public CLI or SDK. Judgment call: anchor 3 needs onchain evidence about the deployed program, which the dashboard cannot record for Aleo addresses and programs (the schema's address formats do not fit), so we take 2; the deployed credits.aleo matches source (see O1). | |
| AnomaPay | Anyone can submit a valid transaction to the adapter, so settlement without Anoma is possible in principle, and the docs say users may run the off-chain infrastructure themselves. But the documented client flow submits every mint, transfer and burn to the hosted proving backend, and no public client builds and proves a transaction end to end. Judgment call: 2, possible but undocumented, reconstructable from verified source. | |
| Avalanche Card | Card settlement runs through Rain Liquidity, the issuer and Visa. No published contract or ABI lets a payer or payee settle directly. | |
| Avici Card | By Avici's own description, settlement needs Avici's spend attestation and its periodic liquidation, plus the issuer and Visa. No contract or ABI is published for a direct path. The provider's admission holds this at 0. | |
| Aztec (Alpha mainnet private token transfers) | A payer proves a private transfer in their own PXE and sends it to any Aztec node, which gossips it to the sequencers; no company API or signature is needed. Judgment call: anchor 3 needs onchain evidence about deployed contracts that this row's chain id cannot carry, and the token contract being paid is third-party, so we take 2. | |
| Bitget Wallet Card | Card settlement is a pull executed only by Fiat24's authorizer key after the card network authorizes the payment. Neither the cardholder nor the merchant can settle a card payment by calling the contract. Plain token transfers between Fiat24 accounts are a separate P2P feature, not card settlement. | |
| Blanksquare (Shielder) | A payer deposits and later withdraws to any payee address by calling the Shielder directly; no relayer, signer or API is needed, and the SDK ships a direct-withdraw method. The address is published in the docs and the source is public and verified. Payment model: there is no shielded transfer to another account in this contract version, so a payment is a withdraw to the payee's address. We sent no transaction. The owner Safe can still pause the contract (C1). | |
| COCA Card | Card settlement runs through COCA's and a third-party provider's card system; no direct contract path is published. Docs and terms only, so 0. | |
| Coinbase Commerce (Onchain Payment Protocol) | A payee can settle without Coinbase. It registers its own address as an operator, signs a TransferIntent for each payer, and the payer calls a documented method on the deployed contract. The README documents the ABI-level methods, the addresses and the permissionless operator role, and the deployed code matches the repo exactly. Refunds have no onchain path because payments are atomic; nothing is held to refund. The direct path still depends on the owner not pausing the contract (C1). Judgment call: we read "payer or payee completes settlement" as satisfied when the payee acts as its own operator, because the operator signature then comes from a party to the payment and not from the provider. | |
| Curvy | A payer completes a payment with a plain transfer to the payee's portal address. Moving those funds into the shielded pool needs Curvy's operator (C1), because direct shielding is disabled. The payee can withdraw from the pool, or recover funds stuck at a portal, by calling the contracts directly. Withdrawing also needs notes-tree data and circuit keys that Curvy hosts (C3). Scored 1: settlement into the private pool depends on the provider, while recovery and withdrawal are direct. | |
| Daimo Pay | A payer pays with a plain ERC-20 transfer to a deposit address, which needs no provider. Delivery from that address to the payee does need the provider. Every forwarding entrypoint is relayer-only and also needs a price signed by Daimo's key within the last 300 seconds. Neither party can finish settlement by calling the contracts directly. The direct path that does exist is a refund to the payer's refundAddress once the deposit address expires. Settlement to the payee has no direct path. | |
| Deblock Card | The card is a Visa debit card on Deblock's own e-money ledger, with Deblock as issuer. Settlement happens only inside Deblock and Visa, so there is no direct path. | |
| Ethena Pay | Merchants are paid by Visa and the issuer offchain. The only onchain settlement step, moving USDe from the cardholder's wallet to the Rain collateral, requires an Ethena Pay executor signature and is relayed by Ethena Pay. Neither payer nor payee can settle a card payment by calling the contracts directly. The direct-mode withdrawal is an exit, not settlement. | |
| ether.fi Cash | Merchants are paid by Visa and the issuer offchain. Both onchain steps are role-gated: spend() needs an ether.fi wallet key, and settle()/bridge() need the bridger role. Neither payer nor payee can settle a card payment by calling the contracts. The user's own withdrawal path is exit, not settlement (see S4). | |
| Exa Card | Merchants are paid by Visa, Third National and Rain offchain. The only onchain step is a debit or borrow that needs both Exa's issuer signature and Exa's keeper. Neither payer nor payee can settle a card payment by calling the contracts. | |
| Fluidkey | Once a payer has a stealth address, settlement is a plain token transfer, and the payee can deploy the Safe and move funds with the kit and Safe's public factory, without Fluidkey. But new addresses are issued by Fluidkey's backend, and the documented direct path is recovery only. Judgment call: 2, possible and reconstructable from public code, but not documented as a settlement path. | |
| Fuse Card | Merchants are paid by Visa and Lead Bank off-chain. The only onchain step is Bridge pulling USDC with its own key. Neither payer nor payee can complete a card payment by calling the program. | |
| Gnosis Pay | A merchant (payee) is paid through Visa and the issuer offchain; onchain, the only settlement step is a spend() that requires a Gnosis Pay delegate signature and is relayed by a Gnosis Pay relayer. Neither payer nor payee can complete a card payment by calling the contracts directly. The user's own withdrawal path is direct (see S4), but that is exit, not settlement. | |
| HesabPay | Settlement is a book entry on HesabPay's custodial ledger. The terms describe no path for a payer or payee to settle without HesabPay's app, USSD service, or API. | |
| Hinkal | A payer can deposit, and a holder can transfer or withdraw, by calling the public Hinkal contract directly with relay = 0, without Hinkal's relayer or a provider signature. The address is documented, and the ABI comes from the verified source. Building the proof needs the circuit wasm and zkey files. The SDK downloads these from Hinkal's own server (wallet-prodv12.hinkal.io/verifiers-v4/); they are in no repository, and only the circuit source is published. Judgment call: the direct contract path meets anchor 3 in substance. We take 2 because a direct call needs proving artifacts that only Hinkal hosts. No transaction was run. | |
| Holyheld Card | Card payments to merchants settle offchain through the card issuer and network. The only onchain step, the top-up into the card balance, requires a Holyheld backend signature (the signature check is switched on) and a receiver code issued by the Holyheld API. Nobody can settle a card payment by calling the contract directly. | |
| Houdini Swap | Every private or standard swap starts with an order that Houdini's hosted API creates. The API returns the partner deposit address, and Houdini's engine runs both legs. A payer cannot complete a Houdini swap without Houdini's servers. Going to an exchange partner directly is a different product. | |
| Hyperbeat Card | Card settlement requires Hyperbeat's Operator; there is no documented direct path for payer or payee. | |
| Jupiter Card | Merchants are paid by the issuer over Visa. No contract path for payer or payee is documented or published. | |
| M-Pesa | Settlement happens only inside Safaricom's M-Pesa platform, reached through Safaricom's authenticated API or its own channels (SIM toolkit, USSD, app). No direct settlement path exists. | |
| MetaMask Card | The merchant is paid by Mastercard and Monavate offchain. The only onchain step is a pull from the cardholder's wallet that only Baanx's operator keys can execute. Neither payer nor payee can complete a card payment by calling the contract directly. | |
| Opera MiniPay | A MiniPay payment is an ERC-20 transfer on Celo signed with a key the user holds, so a user holding the recovery phrase can settle by calling the token contract directly from any Celo wallet. This is shown by terms and docs only. No trace of exporting a MiniPay key and settling elsewhere was run, so the documented cap of 1 applies. | |
| Monero | A payer signs a transaction in their own wallet and submits it to any Monero node; the payee detects it by scanning with their view key. No company, API or signer is in the path. Judgment call: this is direct settlement in substance, but anchor 3 is defined by calls to public contracts and needs onchain evidence about a deployed contract, which this chain has none of, so we take 2. | |
| Nullmask | By the operator's own terms, every transfer and withdrawal is proved by its servers and submitted by its relayer, and no tooling to do otherwise is provided. The contract source is unpublished, so a direct path cannot be reconstructed. Scored 0 on the provider's admission; only a pending deposit can be taken back directly. | |
| Oobit Card | Every payment settles into Oobit's own settlement layer and reaches the merchant through Visa and the issuer. Nothing describes a path that bypasses Oobit. | |
| Payy Card | Merchants are paid by Visa and the issuer off-chain. On the rollup, a card debit is a note handed to Payy's closed backend, and only Payy's prover can put any transaction into a block on Ethereum. Neither payer nor payee can complete a card payment by calling the contracts directly. | |
| Phantom Cash | Card payments are pulled by Bridge and settled over Visa by Lead Bank. No direct payer or payee contract path is documented or published. | |
| Plasma One | Merchants are paid by Rain through Visa offchain. Onchain, moving funds into collateral and paying out of it both require Rain-held keys (pull operator, executor or publisher). No payer or payee can settle directly. | |
| Privacy Pools (0xbow) | A payer deposits and a note holder withdraws by calling public contracts, with no 0xbow API or relayer; addresses and ABIs are in the repo and SDK. But a private withdrawal to a payee succeeds only if 0xbow's ASP has already put the deposit's label in the latest root. Without that, the only direct path is ragequit back to the depositor. Judgment call: 1 (partial). The refund path is fully direct, and the payout path is a direct call that depends on a prior provider approval, which C2 treats like a provider signature. | |
| Railgun | A payer can shield, send privately to a payee's 0zk address and the payee can unshield by calling the proxy directly and self-signing; no broadcaster, API or provider signature is involved. Addresses and ABIs are published in the deployments repo. We did not run a transaction. | |
| Request Network | A payer can settle without Request Network. They compute the paymentReference from the request and call ERC20FeeProxy or EthereumFeeProxy directly. The ABI and Base address are in the repo and the npm package, and the docs describe the call. No provider signature, relayer, or API is involved, and the contract moves funds straight from payer to payee. We did not run a test payment of our own. A live transaction on Base shows a third-party contract calling the proxy directly. | |
| Rizon Card | Card payments settle through Rain, the issuer Third National and Visa. Users cannot settle a card payment themselves. | |
| SafePal Card | Card settlement is a pull executed only by Fiat24's authorizer key after the card network authorizes the payment. Neither the cardholder nor the merchant can settle a card payment by calling the contract. Plain token transfers between Fiat24 accounts are a separate P2P feature, not card settlement. | |
| Solayer Card (Emerald Card / Solayer Pay) | The issuer pays the merchant over Visa and Solayer recovers the amount. There is no direct payer or payee contract path. | |
| Tongo (confidential ERC-20 on Starknet) | A payer funds a Tongo account and transfers to the payee's public key, and the payee rolls over and withdraws. Every step is a direct contract call with a proof built client-side by the public SDK. A Starknet account pays the gas, and no provider signature or relayer is involved. The Relayer is an optional alternative for users without a Starknet account. Addresses and ABIs are documented. Judgment call: the substance fits 3, but 3 needs onchain evidence that the schema cannot express for Starknet, so 2. | |
| Tornado Cash (Classic pools) | A payer can deposit and a payee holding the note can withdraw by calling the pool contracts directly, with no relayer, router, API or signature from anyone else. Addresses and ABI are committed in the public UI repo, and the reference client calls the pool directly. We did not run a transaction. The payment is completed by handing the note to the payee off-chain; the protocol has no on-chain payee field at deposit time. | |
| Tria | Card payments are authorised and settled by the issuer and its partners; no direct contract path is documented or published. 0. | |
| Tuyo Card | Merchants are paid by the issuer over Visa. Nothing documents a way to complete a card payment by calling contracts directly. | |
| Umbra Cash | A payer sends by calling the contract directly; ETH goes straight to the stealth address, tokens wait in the contract until the stealth key withdraws them, directly or through anyone it signs for. The address and ABI are in the public SDK. We did not run a transaction. | |
| Wirex One | Card payments settle through the issuer and card network offchain. The onchain debit can only be run by Wirex's oracle EOA. A user can withdraw their own tokens directly (see S4), but that is exit, not settlement. | |
| Wise | Transfers settle only on Wise's own ledger, reached through Wise's authenticated API or its app and website. No direct settlement path outside Wise exists. | |
| WORM (BETH proof-of-burn) | A payer can send ETH to a burn address that commits to the payee, and anyone can then call mintCoin with a locally generated proof. The payee receives BETH, or ETH through the optional swap hook. No signature, relayer or API from the provider is needed. Addresses are in the README and the CLI, and the ABI is committed in worm-miner. The proof must use a block hash from the last 256 blocks, which any client can choose at mint time. We did not run a transaction. Note that the payee receives BETH, a token whose ETH value depends on market liquidity; the burned ETH itself cannot be recovered. | |
| XPlace Card | A merchant is paid over Visa by Rain. Neither payer nor payee can complete a card payment by calling a contract. Kamino calls (deposit, borrow, repay) are direct, but they fund the card; they do not settle it. | |
| Zcash (shielded transfers) | A payer builds and signs a transaction in their own wallet and can submit it to any Zcash node, their own or anyone's, or to any light-wallet server; the payee receives it by scanning the chain with their viewing key. No company sits in the path. Settlement is the consensus protocol itself, specified in the ZIPs and protocol specification. Judgment call: this is the strongest form of direct settlement, but anchor 3 is defined by direct calls to public contracts and needs onchain evidence about a deployed contract, which this chain has none of, so we take 2. | |
| zERC20 (zBNB on BNB Chain) | The payer's half is direct: the sender transfers zBNB to a burn address with any wallet. The payee's half is not. teleport and singleTeleport are open to anyone with a valid proof, but they verify against transfer roots, and only addresses the Verifier owner has allowlisted can post those roots. A payment that has not been included in a proved root cannot be redeemed until the provider's prover posts it. Judgment call: we score the private flow, so 0, because settlement depends on the provider's prover. A plain public zBNB transfer settles directly, but it is not private. |