Blockchain trust. Card-network speed.
Each card receives a verifiable Card Identity on ICP. A customer or corporate treasury has one Wallet Canister for its cards and collateral references. Authorization remains an off-chain Veritas path; the ledger—not ICP—remains the source of payment balance truth.
A proposed bank card-issuing service: Veritas manages cardholder and card records, controls, available spending power, authorizations, holds, captures and the issuer ledger. A card scheme routes purchase messages between merchants and the issuing bank.
“Blockchain card” here means an ICP identity and proof layer attached to a card record—not a payment card or payment transaction running on-chain.
To make each issued card’s identity, lifecycle state, control commitment and collateral/reserve references independently verifiable, while letting customers continue to pay through familiar card-network acceptance.
It is intended to add tamper-evident evidence and reserve transparency; it does not replace issuer authorization, card-network contracts, custody controls, or the Veritas ledger.
Veritas verifies the customer through its governed KYC process, creates one Wallet Canister for that customer or treasury, checks eligible collateral, and creates a distinct ICP Card Identity for each card. The ICP record contains only permitted identifiers, references and cryptographic commitments.
At purchase, the merchant’s acquirer routes an authorization through the card scheme to Veritas. Veritas checks card status, controls, risk and its own ledger, places an authorized hold, then returns approve/decline. Clearing and capture follow later; accepted capture is posted to the append-only ledger. ICP proofs are written separately—they are not awaited for authorization.
ICP can provide a durable, independently verifiable reference for card identity, lifecycle changes, control hashes, collateral links and reserve commitments. A verifier can check that a proof matches the anchored commitment.
ICP is not Visa, the acquirer, the issuer processor, the card network, an authorization system, custody evidence by itself, or balance truth. Anchoring a hash proves commitment to data, not that the underlying reserve is real or sufficient.
A generic card-scheme model: the merchant’s acquirer routes an authorization request through the scheme to Veritas as issuer. Veritas checks its own card controls and ledger, places a hold when approved, and returns an approve/decline decision over the scheme path. Clearing and settlement follow later; neither authorization nor payment balances are put on ICP.
| Step | Animated flow | What happens |
|---|---|---|
| 01 |  | Identity & onboardingKYC is completed in governed Veritas systems. No identity documents are placed on ICP. |
| 02 |  | Customer Wallet CanisterOne canister per customer or treasury groups cards and collateral references; each card remains separately identifiable. |
| 03 |  | RWA collateral depositTokenized gold, Treasuries, ckUSD or ckEUR are examples only; asset eligibility and custody evidence must be verified. |
| 04 |  | Collateral → spending powerCollateral status may be evidenced on ICP, while card limits and available spending power remain internal Veritas projections. |
| 05 |  | On-chain Card IdentityEach card has a unique ICP identity. PAN, CVV, PIN and customer KYC documents are explicitly excluded. |
| 06 |  | Controls & collateral linkThe identity links to a collateral reference and a controls hash; sensitive control values are not published. |
| 07 |  | Card-network issuanceA Veritas-owned adapter would map internal instructions to an external network. No Visa or Mastercard integration is claimed live. |
| 08 |  | Off-chain authorizationMerchant and ATM decisions stay on the fast off-chain path. The under-300-ms figure is a concept target only. |
| 09 |  | Hold → capture → ledgerCapture cannot exceed the hold. Immutable Veritas ledger postings—not blockchain state—remain authoritative for balances. |
| 10 |  | Lifecycle & reserve proofICP can anchor lifecycle and reserve commitments for verification; it does not store payment records or balance truth. |
ILLUSTRATIVE ARCHITECTURE ONLY · SVGs ARE INDEPENDENT FILES FOR EASY EDITING · ANIMATION RESPECTS REDUCED-MOTION PREFERENCE
outline-level planning text — simulated demo content, to be replaced by the programme's real materials
Issue cards whose identity, lifecycle, control and reserve commitments are independently verifiable, while payment stays on the card-network path.
Customers and corporate treasuries that want familiar card acceptance with stronger evidence about the card and its backing.
No scheme affiliation, issuer licence, processor contract, card production or measured latency; under 300 ms is a design target.
Programme materials that would define scope, controls and steps:
outline-level engineering text — planned work is labelled, never claimed as shipped
One wallet canister per customer or treasury, one distinct ICP identity per card, controls committed as a digest.
Off-chain issuer decision, a hold on approval, capture never above the hold — the ledger remains balance truth.
Lifecycle and reserve commitments anchored asynchronously: proof of commitment, never proof that collateral exists.