[DIS] CKB Anywhere Card — Tap to Pay via Apple & Google Wallet, Self-Custodial

[BuildUnion]

On success metrics: That’s fair feedback. While we don’t want to commit to arbitrary numbers before launch, we can offer indicative milestones for the community to track over time.

As a preliminary estimate, we’d expect low hundreds of active users within the first couple of months post-launch, given CKB’s current holder base and that this is a first release rather than a mass-market push.

We’d track progress through active users, transaction volume, transaction retention, and since the framework is wallet-agnostic wallet integrations. For the infrastructure side, seeing 2–3 additional Nervos wallets adopt the authorization model within the first year would be a strong indicator that the reusable infrastructure model is gaining adoption beyond just our own user growth.

On your new question — the primary use case for the first few years: realistically, this happens in phases.

Phase 1 is solving a real problem for existing CKB holders — people who already hold the asset and have limited practical ways to spend it directly. That’s what V2 is designed to prove.

Phase 2 is making the authorization framework reusable across other Nervos wallets, so adoption isn’t dependent solely on our own user growth. This is already built into the architecture.

Phase 3 is the bigger ambition: reaching users who don’t think about blockchain at all. Apple Pay succeeded not because people understood NFC or EMV, but because the technology disappeared into the background. We believe blockchain payments should evolve the same way, with Nervos operating quietly as infrastructure rather than something users need to learn about first.

Because the authorization framework is wallet-agnostic, that vision isn’t limited to a single application. As it is adopted by more wallets and applications, it creates a path to reach users far beyond today’s Nervos community. So rather than relying solely on Nervos’s own community, integrating with larger multi-chain wallets could put CKB in front of people who’ve never encountered it before.

That’s why we see the card as more than a product for existing holders—it’s a distribution channel for the wider Nervos ecosystem. But that vision has to be earned, so we’re not skipping steps to get there.

Really glad the direction resonates, conversations like this are exactly what sharpens the long-term vision. Thanks again for engaging so thoughtfully.

[BuildUnion]

Final call: CKB Anywhere Card V2 — Voting ends in 24 hours

Over the past few days we’ve had a genuinely valuable discussion with the Nervos community. The proposal has been refined throughout the review, including clarifications around transaction costs, the authorization and settlement architecture, liquidity safeguards, team background, success metrics, and the long-term vision for reusable payment infrastructure on Nervos.

If you’ve read the proposal and the discussion and think it’s worth moving to a full community vote, I’d appreciate your support. If you haven’t had a chance to review it yet, there’s still time to read through the discussion and make your own assessment.

Thank you to everyone who has taken the time to ask questions, challenge assumptions, and provide feedback throughout the process. The discussion has genuinely helped strengthen the proposal.

[tdndo]

the authorization framework can support additional Nervos-native assets, including stablecoins and RGB++ assets

This means BTC, USDT, and other UTXO-enabled blockchains that link to Nervos, those assets can be spent crosschain?

What wallets will the Anywhere Card be compatible with?

For refunds, what price oracle is being used?

End-user KYC

What does this involve? ID? Face scan?

The UI is mobile only in the wallet or will there be a desktop interface?

Will we be able to have multiple cards for multiple assets? Temporary cards? Transferable cards like giving a loaded gift card to someone else?

[BuildUnion]

Thanks for the questions.

This means BTC, USDT, and other UTXO-enabled blockchains that link to Nervos, those assets can be spent crosschain?

Potentially, yes, but with an important distinction. The authorization framework isn’t limited to CKB specifically—it’s designed to support additional Nervos-native assets over time, including stablecoins and RGB++ assets. For V2, the focus is CKB. Support for assets such as BTC would depend on how those assets are represented within the Nervos ecosystem (for example, via RGB++) and would come in a later phase rather than the initial release.

What wallets will the Anywhere Card be compatible with?

The initial implementation targets JoyID as the reference wallet. Because the authorization framework is wallet-agnostic, the goal is for other Nervos wallets to integrate the same authorization model over time without requiring changes to the core payment infrastructure.

For refunds, what price oracle is being used?

Refunds follow the standard card-network process. The merchant refunds the original fiat amount, which is then converted back into the user’s selected asset using the exchange rate at the time the refund is processed. This uses the same exchange-rate mechanism as settlement, so a separate refund-specific oracle isn’t required.

End-user KYC – what does this involve? ID? Face scan?

KYC is handled by our regulated partner, Rain. The exact verification flow depends on the jurisdiction and regulatory requirements, but typically includes government-issued ID verification, with additional checks such as selfie/liveness verification where required.

The UI is mobile only in the wallet or will there be a desktop interface?

The primary experience is mobile-first because card provisioning is through Apple Wallet and Google Wallet, and most in-store transactions are expected to happen via tap-to-pay. However, once issued, the card can also be used for online purchases wherever the issued card network is accepted, including desktop websites, just like a traditional payment card.

Will we be able to have multiple cards for multiple assets? Temporary cards? Transferable cards?

Temporary virtual cards are certainly a feature we’d be interested in exploring in the future, subject to issuer support. Transferable cards are more complex because they introduce additional compliance, KYC, and card-network considerations. For V2, our focus is on delivering the core spending infrastructure first before expanding into additional card management features such as multiple cards, temporary cards, or asset-specific cards

[fgh]

Based on the description, authorization comes before the tap. I assume the user is told the total at checkout and enters it in the wallet first, so they know the exact amount to authorize. Three questions:

1. Amount mismatch. At a gas pump or hotel, the final amount often isn’t known at tap time, and restaurant tips can be adjusted after authorization. If the solution is a tolerance band or a maximum amount, then the approval is really a cap rather than “the exact amount approved by the user.” Could the proposal clarify which model it uses?

2. The gap between authorize and tap. No funds move at authorization, and settlement is only broadcast after Visa approves, so the user controls how long that gap is. A user could authorize, spend the same cell elsewhere, wait for confirmation, then tap. Visa succeeds, but settlement can no longer execute. Is anything preventing this at the contract level? And if it happens, does the loss fall on the DAO-owned liquidity facility?

3. Refunds. Settlement is CKB → USDC and batched, but a refund needs the reverse leg, USDC → CKB. Who executes that conversion, where does the CKB for refunds come from, and does the user pay the spread in both directions? How are partial refunds handled, and what exposure does the facility carry during a Visa dispute?

[BuildUnion]

Thanks for the thoughtful questions, and to everyone who took the time to review the proposal, provide feedback, and support it throughout the discussion. I’d like to give these latest questions the attention they deserve rather than reply hastily. I’m currently away on vacation, so I’ll respond in detail next week when I’m back.

[knmo]

I know of a provider that allows you to set up multiple cryptocurrencies as spending currencies, so that when you use your Visa card, it converts CKB into the equivalent amount at the time of use. These could also be Litecoin or other assets, for example. When withdrawing cash from an ATM, the respective amount is also automatically converted at the time of use.

I don’t see a need for this—solutions like this already exist—even though I personally believe it doesn’t do the crypto industry any favors. Especially since Nervos is an infrastructure project that shouldn’t be funding high-level solutions. Those are subject to regulation, go bankrupt, and get pushed out by competitors.

I’m not against this project; I haven’t even taken the time to read through it thoroughly. I’ve simply learned from many years of experience that it’s better to give hopeful, idealistic ideas very little room to grow. A major stablecoin project just failed recently! Conservative, low-level thinking that’s as uncomplicated as possible pays off over the decades.

[Nervosanno]

I think it’s worth separating two issues here. One is whether crypto cards already exist, and the other is whether Nervos has reusable payment infrastructure that its own wallets can integrate with.

Existing providers certainly exist, but most are vertically integrated products. My understanding of this proposal was that will provide a reusable toolkit that Nervos wallets could adopt, than requiring users to leave the ecosystem for a third-party solution.

Whether that’s the right funding priority is a fair discussion, but I don’t think the existence of other crypto cards alone means the proposal lacks value.

Application-layer infrastructure is inherently outside the scope of ecosystem grants. Wallets, explorers, bridges, developer tooling, and payment infrastructure all sit above the protocol layer, yet many ecosystems fund them because they improve usability and adoption. The more important question is whether the team can execute, rather than whether the category itself should exist.