Custodial vs non-custodial stablecoin cards: two completely different systems

Nethsara

SubscribeSign in

Custodial vs non-custodial stablecoin cards: two completely different systems

Nethsara<br>May 15, 2026

Share

Most public writing about "crypto cards" is wrong before it gets to the second paragraph. It treats custodial and non-custodial cards as variations on the same product, separated by some vague spectrum of "how self-sovereign" the user is. That framing hides the part that actually matters. They're two completely different systems. The card in your wallet looks the same. The plumbing behind it has almost nothing in common.<br>Thanks for reading! Subscribe for free to receive new posts and support my work.

Subscribe

I've spent the last year on both sides of this. I built the custodial card stack at Maash. I also carry a Solflare card, which runs on Kulipa's non-custodial rails on Solana. So I get to compare the production reality of one against the on-chain footprint of the other. The two systems answer different questions, take different risks, and have completely different failure modes. Picking the wrong one for your product is the kind of mistake you don't recover from.

The custodial model

A custodial stablecoin card is structurally the same as any prepaid card you’ve ever used. The crypto part is the funding source, not the operational model.<br>Here’s the user flow. The user signs up, completes KYC, and gets a virtual or physical card. To use it, they top up their card balance from their crypto wallet. That top-up is a real on-chain transfer of USDC (or whatever stablecoin) from the user’s wallet to a settlement address controlled by the issuer. Once that transaction confirms, the issuer credits the user’s internal balance, and the card is live.

From that moment on, the card has nothing to do with the blockchain.<br>Picture a user buying a coffee. They tap the card. The card network (Visa or Mastercard) sends an authorization message to the card processor. The processor forwards it to the issuer’s authorization endpoint. The issuer checks the user’s internal balance, fraud rules, velocity limits, KYC status, and any 3DS step-up that applies. If everything passes, the issuer responds with an approve. If anything fails, it responds with a decline. The whole loop happens in well under a second, sometimes under 300 milliseconds, because all of it is a few database reads and writes.

No on-chain transaction happens at the moment of authorization. The user’s USDC is no longer in their custody. It sits in the issuer’s pooled settlement account, often earning yield (more on that later). The issuer settles with the card network in fiat or stablecoin on the network’s own batch schedule, usually daily.<br>This model has a name in traditional payments. It’s a closed-loop prepaid card with a stablecoin funding rail. The “crypto” part begins and ends at the top-up step.

The non-custodial model

A non-custodial stablecoin card never takes possession of the user’s funds. The user’s USDC stays in their own wallet until the moment of purchase. The card is a permission to pull, not a balance to spend.<br>There are two flavors of non-custodial in production today, and they answer the same question very differently.<br>JIT (Just-in-Time)

The user runs an externally owned account, a normal wallet with a private key. During card setup, the user signs an Approve instruction on the SPL Token program (on Solana) or an ERC-20 approve call (on Ethereum and L2s). That instruction grants a delegate address (controlled by the card program) permission to move tokens from the user’s account up to some allowance. On Solana, this is a single transaction the user signs once. After that, the delegate can call Transfer or TransferChecked against the user’s token account without further user involvement.<br>In the Solflare + Kulipa setup, they delegate lots of SPL token funds (USDC) to the Kulipa smart contract. While this approach makes sense from a functionality perspective, it also introduces a security risk that needs to be properly handled on the Kulipa side.

When the card swipes, the issuer’s backend builds a Solana transaction that uses the delegate authority to pull the authorized amount from the user’s wallet into a settlement address. The transaction is bundled and sent with priority (Kulipa uses Jito bundles to guarantee fast inclusion). If the transaction lands within the authorization window, the swipe is approved. If it doesn’t, the swipe declines and the user keeps their money.<br>Note: Patterns may vary depending on the provider. Please do your own research (DYOR) for complete details.

I dug through Solscan on my own Solflare card and you can see the whole machinery. The program ID is CarDojyKgySxsuqkggcJw52RqLsrSzBYAqYrsTZvLz5k. The delegate authority is a program-derived address. The settlement transactions are signed by a Kulipa-controlled hot wallet, not by me. The Jito tip transfers sit right alongside the SPL transfers....