Security · S4
Walkaway test
If the provider disappears tomorrow, do payees keep their funds and the ability to keep settling?
Why it matters
This is the question a treasury actually needs answered. It is derived from custody, direct settlement, intermediary dependence, and self-hosting, so it repeats facts scored elsewhere; it is kept in the Security minimum because it is the single question institutions ask first.
Derived from Who holds funds in transit, Settle without the provider, Reliance on hosted services, Can be self-hosted. It repeats facts scored there and is kept in the Security minimum because it is the question institutions ask first.
Scoring anchors
| If the provider disappears, payees retain funds and can keep settling via the C2 path with a public frontend build. | |
| Funds retained and retrievable by the user through a verified direct path without the provider; settlement stops. | |
| Funds retrievable only through a documented manual contract call. | |
| Funds or access depend on provider liveness. | |
| No admissible evidence submitted yet. Counts as 0 in the pillar. |
Admissible evidence
- Derived from S1, C2, C3, O3 evidence; the chain of reasoning is stated in the finding verified
Common failures
- Scoring above what the S1, C2, C3, and O3 evidence supports. A score of 2 needs funds provably retrievable without the provider even when settlement stops; state each step.
Current ratings
| Provider | Score | Finding |
|---|---|---|
| Aleo (credits.aleo private transfers) | Derived from S1=2 (anchor 3 in substance), C2=2, C3=2 and O3=1. Funds are records or balances under the user's key (S1), and any node accepts a transaction (C2). But spending needs proving parameters that the code fetches only from Provable-run hosts (C3); if Provable disappeared, a user without a cached copy would need to obtain the files elsewhere and check them against the published hashes, a manual step no repo documents. We did not reproduce a self-hosted setup (O3=1). Judgment call: funds are retrievable without Provable only by that undocumented manual step, so we score 1. | |
| AnomaPay | Derived from S1=0, C2=2, C3=1, O3=0. If Anoma disappeared, funds would stay in the forwarder (no one stops the adapter by disappearing), and execute() stays open. But retrieving them needs a self-built prover pipeline from arm-risc0 and the unlicensed resource logic, plus resource discovery without the hosted indexer; this is claimed in docs, not shown by public code. Judgment call: 1. | |
| Avalanche Card | No admissible evidence yet. | |
| Avici Card | No admissible evidence yet. | |
| Aztec (Alpha mainnet private token transfers) | Derived from S1=2, C2=2, C3=3 and O3=1. Funds are notes under the user's keys (S1), any node accepts a transaction (C2), and no company service is required (C3). If Aztec Labs disappeared, users could run a node and exit through the token's portal and the ownerless Outbox. Fee Juice cannot be withdrawn at all, and a bridged token's exit depends on its portal owner. We did not reproduce a self-hosted setup (O3=1). Judgment call: 2. | |
| Bitget Wallet Card | Derived. S1 = 0 (operator can move balances), C2 = 0 (only Fiat24's key settles), C3 = 0 (closed single-vendor backend), O3 unknown. The balance is a deposit claim on Fiat24; turning it back into money needs Fiat24's payout operator, and even token transfers depend on Fiat24-set account status. Funds depend on provider liveness, so 0. | |
| Blanksquare (Shielder) | Derived from S1=1, C2=3, C3=3, O3=1. The official web app and relayer are already offline, and the contract stays unpaused: an account holder can rebuild state from RPC events and withdraw with withdrawManual and the local prover (C2, C3). The owner Safe could still pause or upgrade (S1), so funds are safe from provider disappearance but not from provider action. There is no public frontend build for Base mainnet and no reproduction (O3=1). Judgment call: 2. | |
| COCA Card | No admissible evidence yet. | |
| Coinbase Commerce (Onchain Payment Protocol) | Derived from S1=3, C2=3, C3=1 and O3=1. Payees already hold their funds, which arrive in their own wallet atomically (S1). Settlement can continue in principle: a payee can register as operator and sign intents against the unpaused, non-upgradeable contract (C2). No public frontend or operator service exists to do this (C3, O3), and the public SDK only works against Coinbase's API. That fails the anchor-3 condition of a public frontend build. A paused contract would also stay paused if the owner key were lost (C1). | |
| Curvy | Derived from S1=1, C2=1, C3=0 and O3=1. Funds still at a portal can be recovered by a documented manual contract call. Funds already shielded need a proof built from notes-tree data and circuit keys that Curvy hosts, and they sit in a vault the Safe can upgrade. Settlement into the pool stops without the operator. Scored 1: retrievable only through a documented manual call, and for shielded funds only while the keys remain available. | |
| Daimo Pay | Re-assessed under the updated anchor; the score is unchanged, because anchor 2 needs a verified withdrawal path that works without the provider and none exists for funds in flight. Derived from S1=0, C2=0, C3=0, and O3=0. If Daimo disappeared, payees would keep funds already delivered, but no new payment could settle (C2, C3). A payer whose deposit has not been forwarded can get it back after expiry through refundDepositAddress. That call needs the full DAParams, which the API holds and which are not emitted onchain until Daimo acts on the session. Funds already bridged to a destination-chain fulfillment contract can only be claimed or refunded by an allowlisted relayer, so they depend on Daimo staying live. | |
| Deblock Card | Derived from S1 = 1 (provider-held e-money), C2 = 0 and C3 = 0. Card funds and access depend on Deblock operating; any recovery would go through EMI safeguarding (see context), not through a path the user controls. Crypto in the self-custodial wallet is outside the card rail. | |
| Ethena Pay | S1: funds sit in the user's wallet contract. C2: no direct settlement path (0). C3: closed single-vendor backend (0). O3: no self-host path. If Ethena Pay disappears, the card stops, but a user can enter direct mode and withdraw with their own key after 1 hour, by calling the verified facets manually (no public frontend or documented procedure exists). The path depends on facet mappings the admin Safe can change instantly (S2). Judgment call: a working exit exists only as a manual contract call, so 1, not 2. | |
| ether.fi Cash | Chain of reasoning: by S1, funds at rest stay in the user's Safe. By C2 = 0 and C3 = 0, card settlement stops if ether.fi disappears. By O3 = 1, there is no self-hostable frontend. The contract withdrawal path exists in verified source and works while paused. But it needs a signature from the Turnkey-held owner key, which is reached through ether.fi's app, and I found no documented key export. ADMIN_ROLE can also de-list assets instantly. Judgment call: retrieval without ether.fi is a manual contract call that depends on getting the key out of Turnkey, so 1, not 2. | |
| Exa Card | Chain of reasoning. By S1, funds sit in the user's own account, though in an upgradeable, pausable market. By the evidence above, the user can withdraw through a verified two-step path after 60 s without Exa's keeper, using any ERC-4337 bundler and the public app source. By C2 = 0 and C3 = 0, card settlement stops without Exa. By O3 = 1, self-hosting is unproven. Caveats: a market pause (C1) would block the exit, and the admin can swap the ProposalManager (S2). Funds retained and retrievable, settlement stops, so 2. | |
| Fluidkey | Derived from S1=3, C2=2, C3=0, O3=0. Funds sit in user-owned Safes (S1). If Fluidkey disappears, a user with their login or key backup can rebuild addresses with the kit and move funds through the public Safe contracts, for example with SARA (C2). New addresses, ENS resolution and gas sponsorship stop, because they need the closed backend (C3), and the app cannot be self-hosted (O3). Scored 2: funds retrievable without the provider; settlement stops. Keys created through Privy depend on that login or a backup. | |
| Fuse Card | Chain of reasoning. S1: funds at rest sit in the user's own accounts, outside the spending limit. S2: the program is immutable and holds no provider key. C2 = 0 and C3 = 0: card settlement stops without Bridge and Fuse. O3 = 1: a public MIT Squads v4 client could drive the withdrawal, but self-hosting is unproven. Judgment call: the onchain withdrawal path is verified, but I found no evidence that the Device and 2FA keys can be used outside the closed Fuse app. Funds are retrievable through a documented manual contract call, so 1, not 2. | |
| Gnosis Pay | Re-assessed against the revised anchor 2, which needs a verified user withdrawal path that works without the provider. Chain of reasoning: (1) by S1, funds at rest stay in the user's Safe. (2) By S2, Gnosis Pay holds no key over the account, and the Roles scope (setup events) gives its spender Safe only a capped EURe transfer to the settlement Safe, not setTxNonce or any other Delay or Safe call, so it cannot block a queued withdrawal. (3) The user's own EOAs are the Delay modules. They can queue any Safe transaction directly, and anyone can execute it after the 180 s cooldown, using public, Sourcify-matched code (Delay.sol at 515737f). The public MIT frontend's /withdraw route does the same without any Gnosis Pay API call. (4) By C2 = 0 and C3 = 0, card settlement stops if Gnosis Pay disappears. (5) By O3 = 1, self-hosting the frontend is unproven, but the direct contract path does not need it. Funds already pulled into the settlement Safe for in-flight card payments stay with Gnosis Pay. While the delegate is live it can pull up to the remaining daily allowance during the cooldown. "Funds retained and retrievable through a verified direct path, settlement stops" = 2. The earlier judgment call about reading S4 as a strict minimum of S1, C2 and C3 is no longer needed under the revised anchor. The closure notice (cards end 20 Dec 2026, withdrawals kept) is this scenario in practice. | |
| HesabPay | Derived. S1 = 1 (provider custody), C2 = 0 (no direct settlement), C3 = 0 (closed single-vendor services), O3 unknown (no public code to self-host). If HesabPay stopped operating, both funds and the ability to settle would depend on HesabPay and its partner banks. | |
| Hinkal | Derived from S1=1, C2=2, C3=1 and O3=0. The contract would accept a self-submitted withdrawal (C2), and funds cannot be pulled out except through a valid proof. But a proof needs proving keys that only Hinkal serves (C3). The timelock can still change the helper and verifiers (S1), and nothing to self-host has been published (O3). A user who has not cached the zkeys depends on Hinkal's server staying online to withdraw. Scored 0. | |
| Holyheld Card | Derived: S1 = 0 (funds held by Holyheld, redirectable), C2 = 0 (no direct path), C3 = 0 (closed single-vendor API), O3 = 0 (nothing to self-host). A card balance can be spent or withdrawn only through Holyheld and its partner. Tokens never topped up stay in the user's own wallet, but that is outside the rail. | |
| Houdini Swap | Derived. S1 = 1 (partner custody in flight), C2 = 0 (no path without Houdini's API), C3 = 0 (closed single-vendor API), O3 unknown (nothing to self-host). If Houdini disappears, new payments stop. A deposit in flight can be recovered only through the exchange partner's support and recovery process. No verified path exists, so funds and access depend on provider and partner liveness. | |
| Hyperbeat Card | S1 documented only, C2 = 0, C3 = 0, O3 = 0. Per the docs, withdrawing the settlement token or collateral needs the Operator, so funds depend on Hyperbeat's liveness. 0. | |
| Jupiter Card | Derived: custody is with partners (S1 = 1), there is no direct settlement path (C2 = 0), every service is closed and single-vendor (C3 = 0), and nothing can be self-hosted. The only documented exit is a partner-run, region-dependent bank withdrawal, so funds depend on the provider and its partners being live. 0. | |
| M-Pesa | Derived. S1 = 1 (provider custody), C2 = 0 (no direct settlement), C3 = 0 (closed single-vendor API), O3 unknown (nothing to self-host). Both funds and the ability to settle depend on Safaricom's liveness. | |
| MetaMask Card | Chain of reasoning. By S1, funds at rest stay in the cardholder's own EOA and Baanx holds no key over it, so the holder can move funds or revoke the allowance through the token contract without Baanx. By C2 = 0 and C3 = 0, card settlement stops if Baanx disappears. By O3 = 1, no self-host path is proven. Funds already pulled to the beneficiary Safe stay with Baanx. A standing unbounded allowance also stays live until the user revokes it, so a compromised operator key could drain it (see S1 and S3). Funds retained and retrievable, settlement stops, so 2. | |
| Opera MiniPay | Derived. S1 = 1 (self-custody per terms, documented cap), C2 = 1 (direct ERC-20 transfer possible with the user's key, documented only), C3 = 0 (closed single-vendor app and backend), O3 unknown (nothing public to self-host). If Blueboard disappears, a user with the recovery phrase can move funds through another Celo wallet. This is documented, not verified, and the MiniPay app path itself stops. | |
| Monero | Derived from S1=2 (anchor 3 in substance), C2=2 (direct in substance), C3=3 and O3=1. Funds are outputs controlled by the user's keys (S1), any node accepts a payment (C2), and no hosted service is required (C3). There is no provider whose disappearance would stop the rail; if the project's maintainers stopped, the released code would keep running. We did not reproduce a self-hosted setup (O3=1). Judgment call: 2, not 3, for that reason. | |
| Nullmask | Derived from S1=0, C2=0, C3=0, O3=0: if the operator disappeared, shielded balances could not be moved with any public tooling; only pending (unscreened) deposits can be taken back directly. Scored 0. | |
| Oobit Card | No admissible evidence yet. | |
| Payy Card | Chain of reasoning. S1 = 0: funds sit in an upgradeable escrow controlled by Payy. C2 = 0: only Payy's prover can process any transaction, withdrawals included. C3 = 0: the card needs closed services. O3 = 1: self-hosting is unproven, and a self-hosted node could not settle anyway. If Payy's prover stops, no withdrawal can execute. Funds depend on provider liveness, so 0. | |
| Phantom Cash | No admissible evidence yet. | |
| Plasma One | S1: collateral is Rain-controlled. C2: no direct settlement (0). C3: closed single-vendor (0). O3: no self-host path. Funds already in collateral cannot leave without Rain's signature, so they depend on Rain's liveness; balances left in the user's wallet stay under the user's Privy-managed key, but that wallet is not public code. 0. | |
| Privacy Pools (0xbow) | Derived from S1=1, C2=1, C3=0, O3=1. If 0xbow disappears, the latest root stays in place: deposits already in it can still be withdrawn privately, and every depositor can ragequit directly from the immutable pool, with no 0xbow service. New deposits could no longer be approved, so private settlement stops. A payee holding a note for an unapproved deposit cannot recover it; only the depositor can. Scored 2: funds retrievable through a verified direct path; settlement stops. | |
| Railgun | Derived from S1=2, C2=3, C3=3, O3=1. Funds are held by keys the user controls, behind an upgrade path that needs a 7-day governance process (S1). A user can unshield and keep sending privately by calling the contract directly with the public SDK and an RPC (C2, C3). A public frontend exists (Railway), but no build was reproduced (O3=1). Judgment call: 2, not 3, for that reason. | |
| Request Network | This cell is derived from S1=1, C2=3, C3=2, and O3=1. Payees never leave funds with Request: payments land in their own wallets (S1), so nothing needs withdrawing if Request disappears. Settlement can continue by calling the immutable ERC20FeeProxy directly (C2). Request storage and detection can move to a self-hosted node and subgraph (C3), and a public frontend build exists. We did not reproduce a self-hosted deployment (O3=1), so the claim that settling continues through a public frontend is shown in code but not in a run. Judgment call: we score 2 and not 3 for that reason. S1's conversion-proxy risk only arises while the Safe is active. | |
| Rizon Card | No admissible evidence yet. | |
| SafePal Card | Derived. S1 = 0 (operator can move balances), C2 = 0 (only Fiat24's key settles), C3 = 0 (closed single-vendor backend), O3 unknown. The balance is a deposit claim on Fiat24; turning it back into money needs Fiat24's payout operator, and even token transfers depend on Fiat24-set account status. Funds depend on provider liveness, so 0. | |
| Solayer Card (Emerald Card / Solayer Pay) | Derived: funds are provider-held (S1 = 1), there is no direct settlement path (C2 = 0), every service is closed and single-vendor (C3 = 0), and nothing can be self-hosted. Withdrawal is a request to Solayer. Funds depend on Solayer being live. 0. | |
| Tongo (confidential ERC-20 on Starknet) | Derived from S1=2, C2=2, C3=3 and O3=1. If Fat Solutions disappears, the non-upgradeable Vault and ledgers keep working. The key holder can withdraw or ragequit, and can keep transferring, with the public SDK and any RPC. S1 and C2 are capped at 2 only by the onchain evidence format, and no public frontend build exists. Scored 2: funds are retrievable through a verified direct path. | |
| Tornado Cash (Classic pools) | Derived from S1=3, C2=3, C3=3 and O3=1. Funds sit in immutable pools that no one can redirect (S1). A note holder can withdraw by calling the pool directly with the public client and proving key (C2), and no relayer or indexer is required (C3). Settlement can continue the same way. A public frontend build exists in the archived classic UI, but we did not reproduce it (O3=1). Judgment call: 2, not 3, for that reason. | |
| Tria | No admissible evidence yet. | |
| Tuyo Card | Chain of reasoning. S1 is unknown: the collateral contract was not identified. C2 = 0 and C3 = 0: the card stops without Tuyo and its provider. O3 is unknown: there is no public frontend. Funds in the user's Kernel account are retrievable through a documented manual contract call with the user's own signer, and the Terms say the same. Funds already moved to card collateral may follow the provider's release rules. Documented manual call, so 1. | |
| Umbra Cash | Derived from S1=3, C2=3, C3=3, O3=1. Payees keep their funds without ScopeLift: ETH is already in the stealth address, and tokens can be withdrawn by calling the contract with keys derived client-side. Sending can continue via the SDK and an RPC, provided the owner EOA does not raise the toll (C1). A public frontend exists but was not reproduced (O3=1). Judgment call: 2. | |
| Wirex One | Derived: S1 = 0 (the oracle and admin can move funds), C2 = 0, C3 = 0, O3 = 0. The contracts let a wallet owner withdraw through request-and-execute without Wirex's oracle, but the signing key is a Privy embedded wallet reached through the Wirex One app, and I could not verify an export path. Admin EOAs can also reclassify operations or upgrade the policy. Judgment call: access depends on the provider, so 0, not 1. | |
| Wise | Derived. S1 = 1 (provider custody), C2 = 0 (no direct settlement), C3 = 0 (closed single-vendor API), O3 unknown (nothing to self-host). Both funds and the ability to settle depend on Wise. Regulatory safeguarding in insolvency is noted under context and is not a technical exit. | |
| WORM (BETH proof-of-burn) | Derived from S1=3, C2=3, C3=3 and O3=1. No one can redirect funds (S1). A payee or payer holding the burn key can mint with the public CLI and proving parameters (C2). No hosted service is required (C3). A public frontend build exists, but we did not reproduce it (O3=1). Judgment call: 2, not 3. Two caveats: the CLI's hardcoded dRPC endpoint would need a code edit if dRPC disappeared, and BETH's value depends on market liquidity. | |
| XPlace Card | No admissible evidence yet. | |
| Zcash (shielded transfers) | Derived from S1=2 (anchor 3 in substance), C2=2 (direct in substance), C3=3 and O3=1. Funds are notes controlled by the user's keys (S1). Any node or light-wallet server can accept a payment (C2), and no hosted service is required (C3). If the reference wallet's company or the default servers disappeared, users could restore their seed in another open wallet or run Zebra plus Zallet. We did not reproduce a self-hosted setup (O3=1). Judgment call: 2, not 3, for that reason. | |
| zERC20 (zBNB on BNB Chain) | Derived from S1=1, C2=0, C3=0 and O3=0. If the provider disappears, no new roots are proved. Payments sent to burn addresses after the last proved root cannot be redeemed, and earlier unredeemed ones need indexer data that only the provider serves. Holders of plain zBNB can still unwrap through the LiquidityManager. Scored 0: payees' access depends on provider liveness. |