Security · S1

Custody of funds in flight

Who holds funds between payer and payee, and can the provider redirect them?

Why it matters

Custody in flight is where counterparty risk lives. A direct transfer has none; a provider wallet has all of it.

A score of 3 needs onchain evidence about the deployed contracts, not only source code at a commit.

Scoring anchors

3 Strong	Direct payer-to-payee transfer, or payee-controlled non-upgradeable escrow.
2 Partial	Escrow contract with a provider role bounded by a timelock and a documented exit.
1 Weak	Provider-held wallet or upgradeable escrow, disclosed.
0 Fails	Provider-held, undisclosed, or the provider can redirect funds.
No evidence	No admissible evidence submitted yet. Counts as 0 in the pillar.

Admissible evidence

Fund flow in verified source at a pinned commit verified
Balances and roles read onchain verified

Common failures

Bridged or swapped flows where an intermediate contract briefly holds funds and has a sweep function.

Current ratings

Provider	Score	Finding
Aleo (credits.aleo private transfers)	2 Partial	Value moves directly from the payer's record to a record the payee owns. No one holds funds in flight. Judgment call: anchor 3 in substance, but 3 needs onchain evidence the schema cannot carry for Aleo, so we take 2.
AnomaPay	0 Fails	Deposited tokens sit in the non-upgradeable forwarder and move out only through proven adapter transactions, unless the adapter is stopped. The same five signers can stop the adapter (3-of-5) and, as emergency committee (3-of-5), appoint a caller who can send the forwarder's tokens anywhere, with no timelock. The docs say funds "can only be moved with a valid proof", which the code does not bear out. Scored 0: the provider can redirect funds.
Avalanche Card	No evidence	No admissible evidence yet.
Avici Card	No evidence	No admissible evidence yet.
Aztec (Alpha mainnet private token transfers)	2 Partial	Funds move directly between users' notes; no one holds them in flight. The L1 backing of a bridged token sits in that token's portal, controlled by its owner, and the rollup's correctness rests on circuits the project itself calls under-constrained. Judgment call: direct transfer is anchor 3 in substance, but 3 needs onchain evidence this row cannot carry, and the soundness caveat argues against the top score; we take 2.
Bitget Wallet Card	0 Fails	The card balance is a Fiat24 deposit represented by tokens in the user's address, not an asset the user controls: the issuer's operator EOA can move any balance, and card pulls land in Fiat24-held EOAs. "Self-custody" here means only that the wallet key signs; the provider can redirect funds, so 0.
Blanksquare (Shielder)	1 Weak	In the current code only a valid proof moves funds out, to the address bound in it. The escrow is upgradeable by a 2-of-5 Safe with no timelock, so the owner could deploy code that redirects funds. Upgradeability is visible in verified source. Scored 1: upgradeable escrow, disclosed.
COCA Card	No evidence	No admissible evidence yet.
Coinbase Commerce (Onchain Payment Protocol)	3 Strong	A completed payment moves from payer to merchant inside one atomic transaction, so funds are never held across blocks. The Commerce Terms state that Coinbase does not store the crypto merchants receive (see S4). Once a merchant has been paid, the provider cannot redirect the money. The recipient is fixed in the operator-signed intent, which the payer's wallet shows before signing. The contract does hold residual balances, about 6,250 USDC across the two Base contracts. These are most likely tokens sent to the contract directly by mistake, and the owner EOA can sweep them through a sweeper it appoints. Judgment call: we score 3, because the sweep reaches only stray balances and never funds in an in-progress payment.
Curvy	1 Weak	Funds in transit sit in an upgradeable vault. Its authority (Safe 4-of-6, no timelock) can upgrade it or rewire which aggregator may withdraw, either of which could redirect funds. Before shielding, funds wait at the payee's portal, recoverable only by the portal's recovery key. Upgradeability is visible in the public source and README. Judgment call: anchor 1 (upgradeable escrow, disclosed) rather than 0. The same power could redirect funds, but it is disclosed in code, not hidden.
Daimo Pay	0 Fails	A deposit sits in a per-session contract that cannot be upgraded. It can only be released to the fixed payee, or refunded to the fixed refund address. Even so, the provider can take funds in flight. The payee's minimum is computed from prices that Daimo's own key signs. The relayer runs arbitrary calls on the funds and keeps any surplus. A relayer working with the signer can push the minimum close to zero and take the difference, and an honest relayer can still keep up to the slippage bound. Funds bridged cross-chain sit in fulfillment contracts that only relayers can release (see S4).
Deblock Card	1 Weak	The card spends a balance that Deblock holds as e-money. That is a disclosed provider-held balance, so 1. The self-custodial crypto wallet is a separate product and not in the card path.
Ethena Pay	0 Fails	Balances sit in the user's own wallet contract, but the Ethena Pay executor key can move up to 10,000 USDe and 10,000 USDC per wallet per day to an arbitrary address without the user's signature; the relayer contract's recipient allowlist does not bind direct calls to the wallet. At spend, funds pass to a Rain-controlled collateral pool. This contradicts the FAQ's "no access" statement. The provider can redirect funds (bounded per day), so 0.
ether.fi Cash	1 Weak	At rest, funds sit in the user's beacon-proxy Safe. When a card payment is made they move to an ether.fi-controlled, upgradeable settlement dispatcher, which the operating timelock can drain to any address. This is a provider-held escrow disclosed in code, so 1. Judgment call: the dispatcher's redirect power reads like the 0 anchor, but the funds are already the card payment owed to the issuer; scored 1 for consistency with Gnosis Pay's settlement Safe. By default, ether.fi plus an ether.fi-chosen third party can also take over a Safe through recovery after 3 days, unless the owner cancels.
Exa Card	0 Fails	At rest, funds sit in the user's own account as exaUSDC shares in an upgradeable lending market. Exa's issuer key plus its keeper can debit any amount from any account to the collector without a user signature, and the admin Safe can repoint the collector without a timelock. Card debits land in Rain's upgradeable collateral contract (beacon owned by a 2-of-5 Safe). The provider can redirect funds, which meets anchor 0.
Fluidkey	3 Strong	Payments go directly into a Safe the payee alone controls; Fluidkey cannot redirect them. With auto-earn on, Fluidkey's relayers move received funds into preconfigured Morpho, Aave or InfiniFi vaults without a per-transaction signature, so custody shifts to those vaults; the shares stay with the Safe. Judgment call: 3, because the payment itself is a direct transfer and auto-earn is a disclosed, user-chosen profile.
Fuse Card	0 Fails	At rest, funds stay in the user's Card Account, whose only member is the user's Main Account. When a purchase happens, Bridge pulls USDC into its own wallet and settles with the merchant off-chain, so funds in flight are provider-held. Bridge's key can also send up to the daily limit to any address, because the destination is unrestricted. Judgment call: that is a bounded ability to redirect funds, so 0. With a receiver-locked limit this would be 1.
Gnosis Pay	1 Weak	At rest, funds sit in the user's own Safe and Gnosis Pay cannot redirect them. The Roles setup events (now read onchain, not only from SDK code) show that the only role member is the spender Safe. Its only permission is EURe.transfer to settlement Safe 0x4822521E..., within the daily allowance, with no delegatecall. Only the user's Safe can change that allowance, through the Bouncer. When a card payment happens, funds move into the Gnosis Pay-held 2-of-10 settlement Safe and reach the merchant offchain through Monavate and Visa. A provider-held wallet disclosed in code scores 1. Module check (red team R7): one delegate EOA can call spend() through the spender Safe's module without the 2-of-3 threshold. Nothing onchain ties a pull to a card authorisation, so a single compromised or misused delegate key could move up to each account's remaining daily allowance into the settlement Safe. Judgment call: the destination is fixed to the disclosed settlement Safe and the amount is capped, so I read this as provider custody in flight (1), not as the provider being able to redirect funds (0).
HesabPay	1 Weak	HesabPay holds funds in flight and at rest, and the terms disclose this. The terms limit HesabPay's use of those funds to cases with user consent; no onchain artifact confirms this.
Hinkal	1 Weak	The pool is a non-upgradeable contract with no sweep function. Still, the timelock (Safe 2-of-3, 6-hour delay) can replace the helper that computes public inputs and the verifiers that check proofs, and either could redirect pooled funds. The docs give no exit procedure tied to the delay. Judgment call: in effect this is an escrow whose logic the provider can change behind a short timelock, which matches anchor 1 better than 2.
Holyheld Card	0 Fails	A top-up sells the user's tokens to Holyheld: they go straight to a Holyheld EOA, and the card balance is fiat at the issuing partner. A single admin EOA can change the settle address. The provider holds the funds and can redirect them, so 0. Judgment call: the sale is disclosed, which alone would fit 1, but the redirect power sets 0.
Houdini Swap	1 Weak	Houdini says it does not hold funds. In flight they are held by the exchange partners that Houdini's engine selects, at deposit addresses those partners control, for 3-50 minutes per the docs. This intermediary custody is disclosed. Whether Houdini or a partner could redirect the payout is not inspectable, because the engine and partners are closed. Judgment call: scored as disclosed third-party custody chosen by the provider (anchor 1).
Hyperbeat Card	1 Weak	Per the docs, funds sit in an upgradeable smart account the user owns, with the Operator able to settle up to a spending limit and to gate settlement-token and collateral withdrawals. Upgradeable escrow-like account, disclosed: 1 (documented cap). The contracts are unverified, so none of this can be checked.
Jupiter Card	1 Weak	Between deposit and merchant, funds are held by Jupiter's partners, which is disclosed. The Rain "onchain collateral" statement could not be checked, because no collateral address or program id is published. Provider-held, disclosed, so 1.
M-Pesa	1 Weak	Payer and payee funds sit in M-Pesa accounts on Safaricom's platform, so the provider holds custody, and the API docs disclose this. Neither the trust arrangement behind the e-money nor any limit on redirecting funds could be read (the terms returned 403).
MetaMask Card	0 Fails	At rest, tokens stay in the cardholder's own wallet. Any of 33 Baanx operator EOAs can pull up to the full approved allowance from any approving wallet at any time, without a cardholder signature. The owner Safe can change where pulled funds go. Pulled funds then sit in a Baanx-held Safe and settle offchain. The provider can redirect funds within the allowance, which meets anchor 0.
Opera MiniPay	1 Weak	By the terms, MiniPay is self-custodial and payments go directly from payer to payee as token transfers. That matches anchor 3, but it rests on documents only: key generation and storage in the closed app cannot be checked. The documented cap of 1 applies.
Monero	2 Partial	Value moves directly from the payer's outputs to the payee's one-time outputs in one transaction; keys stay in the user's wallet. No one holds funds in flight. Judgment call: anchor 3 in substance, but 3 needs onchain evidence about a deployed contract, which this chain has none of, so we take 2.
Nullmask	0 Fails	Funds sit in an upgradeable pool whose upgrade authority rests on an EOA (S2), and the operator says an upgrade can change who can move assets. Scored 0: the provider can redirect funds.
Oobit Card	1 Weak	Funds in flight, and any in-app balance, are held by Oobit. This is disclosed. Provider-held wallet, disclosed, so 1.
Payy Card	0 Fails	User funds are notes inside a rollup whose escrow is an upgradeable proxy. The Payy owner Safe can overwrite the state root or swap the verifier, which means it can redirect funds. A card debit also hands a note to Payy's backend, which then funds Rain. The provider can redirect funds, so 0.
Phantom Cash	Under review	The balance is held as CASH in the user's Cash account, then moved to a Bridge contract when the card is used. Bridge is both CASH issuer and card program manager, and the CASH mint's permanent delegate lets it move any holder's CASH. Phantom's FAQ says no partner can. Judgment call: although the criteria put token-issuer powers under C5, here the issuer is also the card program manager and CASH is the only asset a Cash account holds, so "the provider can redirect funds" applies. 0.
Plasma One	Under review	Funds in collateral are released only by Rain's Coordinator, and users cannot withdraw without a Rain signature. The observed account grants its collateral an unlimited USDT0 allowance that Rain's pull operator uses, and a single Rain EOA can swap the collateral logic through the beacon. Rain can redirect funds, so 0. Judgment call: the allowance sample is not confirmed as a Plasma One account.
Privacy Pools (0xbow)	1 Weak	Funds sit in non-upgradeable pools that no role can sweep, so 0xbow cannot redirect them. But release to anyone other than the depositor depends on the ASP postman (an EOA, no timelock), and relayed withdrawals and ERC20 deposits pass through the upgradeable Entrypoint. Judgment call: anchor 2 needs the provider role over release to sit behind a timelock, which it does not, so 1.
Railgun	2 Partial	Funds sit in one upgradeable contract, controlled by the note owner's keys; nobody can move them under the current code. An upgrade could, but only after a public RAIL vote and at least 7 days, while users can unshield at any time. Judgment call: we read this as "escrow with a provider role bounded by a timelock and a documented exit" (2), not "upgradeable escrow" without a delay (1).
Request Network	1 Weak	For plain ERC-20 and native payments, funds move in one call straight from payer to payee, which on its own would score 3. Conversion payments run through Erc20ConversionProxy. Its owner, Request's Safe, can switch the delegatecall target with no delay. New code could redirect future conversion payments, or pull tokens from any wallet holding an open allowance to the proxy (see S3). The power is visible in verified source, and the Safe is named in the repo. Judgment call: we score 1 and not 0. We treat this as the "upgradeable, disclosed" case, because funds are never held between calls and the redirect needs a 3-of-7 Safe action.
Rizon Card	No evidence	No admissible evidence yet.
SafePal Card	0 Fails	The card balance is a Fiat24 deposit represented by tokens in the user's address, not an asset the user controls: the issuer's operator EOA can move any balance, and card pulls land in Fiat24-held EOAs. "Self-custody" here means only that the wallet key signs; the provider can redirect funds, so 0.
Solayer Card (Emerald Card / Solayer Pay)	1 Weak	Solayer's own Security page describes provider-held hot and cold wallets. The Card Terms template's user-custody smart-contract claim names no contract and contradicts that page. Judgment call: taking the lower reading, provider-held and disclosed, so 1.
Tongo (confidential ERC-20 on Starknet)	2 Partial	Funds sit in a non-upgradeable Vault, released only against the key holder's proof. The provider cannot redirect them. Judgment call: the substance fits 3, but 3 needs onchain evidence that the schema cannot express for Starknet, so 2. The class hashes we read match the docs. Native USDC inherits Circle's freeze power over the Vault address (C5).
Tornado Cash (Classic pools)	3 Strong	The pools are non-upgradeable escrows that release funds only to whoever holds the note's secret, who chooses the recipient in the proof. No operator, governance or relayer can redirect funds. A relayer cannot change the recipient or fee because both are bound into the proof. Whoever holds the note controls the funds, so a payer who keeps a copy of a note handed to a payee can still withdraw first.
Tria	1 Weak	Card spending is secured by collateral the issuer can liquidate, disclosed in the card terms. Where the collateral sits and who controls it onchain is not published. Judgment call: disclosed issuer-controlled collateral fits anchor 1 at the documented cap.
Tuyo Card	No evidence	No admissible evidence yet.
Umbra Cash	3 Strong	ETH payments are direct transfers to an address only the payee controls; token payments sit in a non-upgradeable contract that releases them only on the stealth key's instruction. No role can redirect funds.
Wirex One	0 Fails	Between the user's wallet and the merchant, funds move into Wirex's FundsBuffer, and the oracle can send them to any destination the admin EOA sets. The Terms call the wallet self-custodial and say Wirex cannot move user assets, while the installed executor lets Wirex's oracle move them. The provider can redirect funds, so 0.
Wise	1 Weak	Wise holds customer funds, as the terms disclose. Safeguarding is recorded under context and does not change the custody score.
WORM (BETH proof-of-burn)	3 Strong	Between burn and mint, no one holds the value: the ETH is gone, and the right to mint is fixed to the payee by the burn-address commitment. A prover or broadcaster can only collect the fees the payer set. Whoever holds the burn key decides when to mint, but cannot change the recipient. The payee ends up with BETH, not ETH (see C2 and C5).
XPlace Card	1 Weak	Collateral sits in Kamino lending reserves, an upgradeable program, and the user holds the obligation; this is disclosed. Card spending is funded and settled by Rain offchain, and how USDC reaches Rain could not be observed. Upgradeable escrow, disclosed, so 1.
Zcash (shielded transfers)	2 Partial	Value moves directly from notes the payer controls to notes the payee controls, in one transaction; wallets hold keys on the user's device. No one holds funds in flight. Judgment call: this is anchor 3 in substance, but 3 needs onchain evidence about a deployed contract, which this chain has none of, so we take 2.
zERC20 (zBNB on BNB Chain)	1 Weak	In flight, value sits as a zBNB balance at a keyless burn address until the recipient teleports an equal amount. No provider wallet holds it, but the token and Verifier are upgradeable by 3-of-4 Safes with no timelock. The owner can also swap the Verifier or minter, which could redirect or invalidate pending balances. The BNB backing sits in an upgradeable LiquidityManager administered by the same Safe. Disclosed in docs. Scored 1: upgradeable escrow, disclosed.