Forem: Alfred Zhang

TCP/IP for Money: Why Card Networks Are the Next Telcos

Alfred Zhang — Fri, 03 Apr 2026 11:53:17 +0000

Visa is AT&T in 1995.

Hear me out.

AT&T charged per-minute for calls. Visa charges per-tap for payments. Both built proprietary networks. Both claimed alternatives were impossible.

Then VoIP happened. Same phone. Same call quality. No per-minute charges. The network was replaced by a protocol.

OpenPasskey is doing the same thing to card networks.

Same EMV tap. Same terminal. Same sub-500ms experience. But the network underneath is different: P-256 cryptography, on-chain settlement via RIP-7212 on Base L2, AUD stablecoins. No interchange. No scheme fees. No 2-3 day settlement.

The IIN from ISO is the key. It lets any terminal recognize our card, just like it recognizes Visa. We're not asking merchants to install new hardware. We're upgrading the rails under their existing setup.

3,200+ users across 20+ Sydney cafes. 45,509 transactions. Built by 3 people with zero funding.

The RBA just banned card surcharges in Australia. The surcharge was the symptom. The 0.3-0.8% extraction by intermediaries was the disease. The ban hides it. OpenPasskey removes it.

Blackbird Giants Cohort 11. Australia's largest VC recognized the pattern.

The card networks are the next telcos. The question isn't if, it's when.

openpasskey.com | @OpenPasskey

Building a Custom Java Card Applet for Payment Cards

Alfred Zhang — Fri, 03 Apr 2026 09:39:48 +0000

Our card runs a custom applet on a JCOP4 (Java Card Open Platform) chip. Here's what that actually means and how we built it.

What Is Java Card?

Java Card is a technology that allows Java-based applets to run on smart cards and secure elements. It's the platform behind most EMV chip cards, SIM cards, and government ID cards.

JCOP (Java Card Open Platform) is NXP's implementation. JCOP4 is the latest generation, supporting:

RSA up to 4096 bits
ECC including P-256 (secp256r1)
AES-256
Secure key storage
Multiple applet isolation

What Our Applet Does

The OpenPasskey applet:

1. Key Generation

On first use, the applet generates a P-256 key pair inside the card's secure element. The private key never leaves the chip. Not during manufacturing, not during use, not ever.

2. EMV Protocol

The applet implements the EMV contactless protocol (ISO 14443-4). When a terminal emits an NFC field:

Card powers up from the RF field
Terminal sends SELECT command with our AID
Applet responds with card capabilities
Terminal sends GET PROCESSING OPTIONS
Applet prepares transaction data
Terminal sends GENERATE AC (authorization cryptogram)
Applet signs transaction data with P-256
Returns signature + payment metadata

Total time: under 500ms.

3. Transaction Signing

For each tap, the applet:

Increments a transaction counter (prevents replay)
Builds a data structure: amount, merchant ID, counter, timestamp
Signs with P-256 ECDSA using the stored private key
Returns: signature (r, s), public key (x, y), transaction data

4. Multiple Interfaces

The same applet supports:

Contact interface (chip inserted into reader)
Contactless interface (NFC tap)
Both use the same key pair and signing logic

Host Card Emulation (HCE)

For mobile phones, we implement the same protocol in software using HCE (Host Card Emulation). The phone's NFC chip emulates a contactless card, speaking the same APDU commands.

The key difference: on HCE, the private key is stored in the phone's secure element or TEE (Trusted Execution Environment) rather than a Java Card chip.

Why Java Card?

Hardware security: Private key in a certified secure element
EMV compliance: Industry-standard protocol implementation
Terminal compatibility: Works at any existing EMV terminal
Tamper resistance: Physical + logical protection

The Result

A card that taps identically to Visa from the terminal's perspective, but signs with P-256 (stronger than Visa's 3DES) and settles on-chain instead of through banks.

3,200+ users, 20+ Sydney cafes. Zero complaints about tap speed or reliability.

OpenPasskey | @OpenPasskey

How Any Acquirer Can Add OpenPasskey in 1 Day (No Integration Needed)

Alfred Zhang — Fri, 03 Apr 2026 09:39:18 +0000

The biggest question we get: how do you get merchants to adopt a new card?

The answer: we don't have to. EMV handles distribution for us.

How Card Routing Works

When you tap a card at a terminal, the terminal reads the card's IIN (first 6-8 digits) and looks it up in a routing table maintained by the acquirer (the merchant's payment processor).

Visa's IINs start with 4. The acquirer's routing table says: "IIN starts with 4 → route to Visa network."

Adding OpenPasskey

We have our own IIN from ISO. When an acquirer adds our IIN to their routing table:

Every terminal they manage instantly recognizes our cards
Merchants don't install anything
Merchants don't sign anything new
The terminal just works

This takes approximately one day of configuration.

Why Acquirers Would Do This

Acquirers make money on the merchant service fee (typically 1-2.5% including interchange). With OpenPasskey:

No interchange to pass through (they keep more of the fee, or offer lower rates)
Instant settlement reduces risk (no 2-3 day float)
Differentiation in a commoditized market

For acquirers competing on price (Tyro, Zeller, Square in Australia), offering a zero-interchange card network is a compelling feature.

The Numbers

Australia has several major acquirers:

Tyro (~80,000 merchants)
Zeller (growing fast in SMB)
Square/Block
Airwallex
Novatti
The big four banks

One acquirer partnership = instant access to their entire merchant base.

Current State

3,200+ users across 20+ Sydney cafes on our direct integration. The acquirer distribution path scales this to tens of thousands of merchants per partnership.

Blackbird Giants Cohort 11. Base ecosystem grant. Zero external funding.

OpenPasskey | @OpenPasskey

How a New Card Network Gets Distribution Without Partnerships

Alfred Zhang — Fri, 03 Apr 2026 09:09:44 +0000

The hardest part of building a payment network isn't the technology. It's distribution.

Visa has 100+ million terminals worldwide. How does a 3-person startup compete with that?

The answer: you don't compete. You use the same terminals.

The EMV Distribution Hack

EMV (Europay, Mastercard, Visa) is an open standard. Any terminal that reads Visa cards can read any EMV-compliant card. The terminal doesn't care who issued the card. It cares about the protocol.

When you tap a card:

Terminal reads the card's Application Identifier (AID)
Matches it against supported applications
Routes the transaction accordingly

Visa's AID: A0000000031010
Mastercard's AID: A0000000041010
OpenPasskey's AID: [registered under our IIN]

The Acquirer Route

Acquirers are the companies that provide payment terminals to merchants (think Tyro, Square, Zeller, Airwallex in Australia).

Adding a new card network to an acquirer's routing table is straightforward:

Register our IIN and AID
Configure routing rules
Done. Their terminals now recognize our cards.

Estimated time: approximately one day.

The merchant doesn't install anything. They don't sign a new contract. Their existing terminal just starts accepting our cards alongside Visa and Mastercard.

Why This Works

This is exactly how Visa and Mastercard got distribution. They didn't install custom terminals. They used the EMV standard. Acquirers added them to routing tables. Terminals recognized them.

We're doing the same thing, but our settlement layer is on-chain instead of through the banking system.

The Numbers

Right now: 20+ Sydney cafes, direct merchant relationships.

Next: acquirer partnerships that scale to thousands of merchants without individual onboarding.

With our IIN from ISO: any acquirer, any country that uses EMV contactless.

The Business Model

Visa charges interchange (0.3-0.8%) and scheme fees. That's how they monetize the routing.

We remove those fees. Our monetization comes from the settlement layer, not from taxing every tap.

3,200+ users. 20+ cafes. Zero external funding. Blackbird Giants Cohort 11.

OpenPasskey | @OpenPasskey

Building a Payment Applet on Java Card: From JCOP4 to EMV Contactless

Alfred Zhang — Fri, 03 Apr 2026 09:09:12 +0000

Java Card is the platform that runs inside billions of smart cards worldwide. If you've ever tapped a Visa or Mastercard, you've interacted with a Java Card applet.

We built our own. Here's what that looks like.

What Is Java Card?

Java Card is a stripped-down Java environment designed for smart cards and secure elements. It runs on chips with:

1-5 KB RAM
32-128 KB EEPROM
8-32 bit processors

Despite these constraints, it supports cryptographic operations, secure storage, and the APDU (Application Protocol Data Unit) communication protocol that EMV relies on.

JCOP4: Our Chip Platform

JCOP4 (Java Card Open Platform 4) is NXP's latest Java Card platform. It supports:

Java Card 3.0.5 API
GlobalPlatform 2.3
P-256 ECDSA (critical for our use case)
ISO 14443 contactless interface
Common Criteria EAL5+ certification

The OpenPasskey Applet

Our applet does four things:

1. Key Generation

On first initialization, the applet generates a P-256 key pair inside the card's secure element. The private key never leaves the chip.

// Simplified flow
KeyPair kp = new KeyPair(KeyPair.ALG_EC_FP, KeyBuilder.LENGTH_EC_FP_256);
kp.genKeyPair();
// Private key is stored in chip's secure storage
// Public key is exportable for on-chain registration

2. EMV Protocol Implementation

The applet implements the EMV contactless protocol so that payment terminals recognize it. This includes:

Application selection (AID matching)
Get Processing Options
Read Record
Generate Application Cryptogram

Our AID is registered under our IIN from ISO. When a terminal selects our AID, it follows the standard EMV flow.

3. Transaction Signing

On each tap, the applet:

Receives transaction data (amount, merchant ID, nonce, timestamp)
Signs it with P-256 ECDSA using the card's private key
Returns the signature, public key reference, and transaction metadata

4. NFC Communication

All communication happens via ISO 14443 (13.56 MHz NFC). The card harvests power from the terminal's RF field. No battery needed. Tap-to-response in under 500ms.

Host Card Emulation (HCE)

The same protocol runs on Android phones via Host Card Emulation. Instead of a physical chip, the phone's NFC controller emulates the card. The private key is stored in the phone's secure element or TEE (Trusted Execution Environment).

From the terminal's perspective, a phone tap and a card tap are identical.

The On-Chain Bridge

The card's P-256 signature is the bridge between physical world and blockchain:

Card signs with P-256 (in the chip)
Signature submitted to Base L2
RIP-7212 precompile verifies the signature (~3,450 gas)
ClearingVault settles the payment in stablecoins

This is the key insight: EMV cards already produce cryptographic signatures. We just verify them on-chain instead of through Visa's network.

Why P-256 Over secp256k1?

Ethereum uses secp256k1. EMV cards use P-256. These are different elliptic curves.

We use P-256 because:

It's the EMV standard (compatibility with 11B+ cards)
Java Card chips have hardware acceleration for P-256
RIP-7212 makes on-chain verification economical
It's the same curve as TLS 1.3, FIDO2, and Apple Secure Enclave

The Result

3,200+ users across 20+ Sydney cafes. Three payment methods (card, phone, QR) through one settlement pipeline. All starting from a Java Card applet on a JCOP4 chip.

OpenPasskey | @OpenPasskey

Australia's Card Surcharge Ban: What Actually Happens on October 1

Alfred Zhang — Fri, 03 Apr 2026 08:40:22 +0000

On March 31, 2026, the Reserve Bank of Australia announced sweeping changes to the payment system:

Card surcharges banned from October 1, 2026 (Eftpos, Visa, Mastercard)
Interchange fee caps reduced (credit cards from 0.8% to 0.3%)
Consumer savings: estimated $1.6 billion/year
Business savings: estimated $910 million/year
Mid-2026 consultation planned on mobile wallets, BNPL, and e-commerce

Sounds great. Here's what's actually going to happen.

What the Headlines Say

"Australians save $1.6 billion in surcharge fees!"

What Actually Happens

For Consumers

The 1.5% surcharge line item disappears ✓
Your coffee price goes up ~10 cents (RBA's own estimate: 0.1% one-off price increase)
Your credit card rewards get cut (banks already warned)
Your annual card fee increases
Your interest-free period may shrink

For Merchants

They can no longer pass card costs to card users
They still pay 0.3-0.8% on every tap (reduced from 0.3-0.8% after interchange cap changes, but not zero)
They raise prices across the board to compensate
Small businesses hit hardest (thin margins)

For Banks

Interchange revenue drops ~$910M/year
They cut rewards, raise fees, reduce interest-free periods
Net effect on bank profitability: minimal (they pass the cost to consumers)

The Core Problem

The surcharge ban removes the visibility of the cost. It doesn't remove the cost.

Every card tap still goes through: issuing bank → card network (Visa/MC) → acquirer → processor → terminal provider. Each takes a cut. The merchant pays. The consumer pays indirectly.

The Alternative

OpenPasskey built a payment network that removes the intermediaries entirely:

Own IIN from ISO (same card identifier system as Visa)
EMV contactless standard (works at any terminal)
No bank, no card network, no interchange
Settlement on Base L2 in seconds
Merchant keeps the full amount

3,200+ users across 20+ Sydney cafes. Built by 3 people with zero external funding. Blackbird Giants Cohort 11.

The surcharge ban is a bandaid. OpenPasskey is the fix.

openpasskey.com | @OpenPasskey

The IIN Is the Moat: Why Most Crypto Payment Projects Are Wrappers

Alfred Zhang — Fri, 03 Apr 2026 08:39:55 +0000

Every month, a new "crypto debit card" launches. They all have one thing in common: they're Visa cards.

They settle through Visa's network. They pay interchange. The merchant pays the same 0.3-0.8%. The only difference is what happens before the Visa transaction: your crypto gets converted to fiat.

That's not disruption. That's a wrapper.

What Actually Disrupts Card Networks

To replace Visa, you need three things:

Your own IIN from ISO — Without it, you can't issue cards that terminals recognize
EMV compliance — Without it, your cards don't work at existing terminals
An alternative settlement layer — Without it, you're still using Visa's rails

OpenPasskey has all three.

The IIN

An Issuer Identification Number is the first 6-8 digits of every card number. It's how terminals know where to route a transaction. Visa's IINs start with 4. Mastercard's start with 5.

We applied directly to ISO (International Organization for Standardization) and received our own IIN range. Capacity: 99 billion unique card numbers.

With an IIN, any acquirer can add us to their routing table in approximately one day. The merchant doesn't install anything. They don't sign a new contract. Their terminal just starts recognizing our cards.

Why This Is Hard

Most crypto payment projects skip the IIN because:

They don't know it exists
They don't understand EMV
It's easier to partner with Visa and slap a logo on a card
Building a custom Java Card applet requires firmware expertise most teams don't have

The result: hundreds of "crypto cards" that are really Visa cards with a crypto on-ramp.

The OpenPasskey Difference

IIN from ISO ✓ (same standard as Visa)
Custom Java Card applet ✓ (P-256 ECDSA, stronger than Visa's 3DES)
EMV contactless compliance ✓ (works at any terminal)
On-chain settlement ✓ (Base L2, seconds not days)
Three payment methods ✓ (card tap, phone tap, QR scan)
Zero interchange ✓ (merchant keeps everything)

The Numbers

3,200+ users. 20+ Sydney cafes. 45,509 transactions. AU$66K volume. 4.5x industry average retention.

3 people. 10 months. Zero external funding. Blackbird Giants Cohort 11.

The IIN is the moat. Everything else is a wrapper.

OpenPasskey | @OpenPasskey

CREATE2 in Payments: Deterministic Merchant Addresses on Base L2

Alfred Zhang — Fri, 03 Apr 2026 08:12:58 +0000

One of the lesser-discussed technical decisions in our payment architecture: using Ethereum's CREATE2 opcode to generate deterministic merchant receiver addresses.

The Problem

When settling card payments on-chain, each merchant needs a unique address to receive funds. You could:

Generate random addresses: Simple, but the card/terminal needs to know the merchant's address at tap time
Use a central registry: Works, but adds a lookup step and a centralization point
Use CREATE2: Compute the address deterministically from the merchant ID

We chose option 3.

How CREATE2 Works

CREATE2 computes a contract address from:

The deployer address (our ClearingVault)
A salt (derived from the merchant's ID)
The bytecode of the receiver contract

address receiver = address(uint160(uint256(keccak256(
    abi.encodePacked(bytes1(0xff), clearingVault, salt, bytecodeHash)
))));

This means:

The receiver address is known before deployment
Any party can compute it from the merchant ID
The contract only needs to be deployed when first receiving funds
No central registry or lookup needed

Why This Matters for Card Payments

At tap time:

Card signs transaction data (includes merchant ID)
ClearingVault receives the transaction
ClearingVault computes the merchant's receiver address via CREATE2
If receiver doesn't exist yet, deploy it
Route stablecoins to the receiver

The merchant's address is deterministic. The card doesn't need to store it. The terminal doesn't need to look it up. It's computed on the fly.

The Receiver Contract

Each merchant's receiver is a minimal contract:

contract MerchantReceiver {
    address public merchant;
    address public clearingVault;

    function withdraw(address token) external {
        require(msg.sender == merchant);
        IERC20(token).transfer(merchant, IERC20(token).balanceOf(address(this)));
    }
}

Merchants can withdraw at any time. Funds accumulate between withdrawals.

Gas Efficiency

On Base L2:

Computing a CREATE2 address: ~100 gas
First-time deployment: ~50,000 gas (~$0.001)
Subsequent settlements: ~30,000 gas (~$0.0005)

Compare this to Visa's 0.3-0.8% per transaction. On a $5 coffee, Visa takes $0.015-$0.04. Our on-chain cost is less than $0.001.

For Developers

If you're building any system that needs deterministic, per-entity addresses:

Use CREATE2 with entity ID as salt
Keep receiver contracts minimal
Consider lazy deployment (only deploy on first receipt)
Use Base L2 for sub-cent gas costs

This pattern works for: payment settlement, subscription billing, marketplace escrow, royalty distribution.

OpenPasskey | @OpenPasskey

Stablecoin Settlement: How We Replace 2-3 Day Card Settlement with Seconds

Alfred Zhang — Fri, 03 Apr 2026 08:12:26 +0000

When you tap your Visa card at a cafe, the money doesn't arrive for 2-3 business days. On weekends and holidays, it's even longer.

Our settlement happens in seconds. Here's how.

How Visa Settlement Works

Visa's settlement process:

Authorization (~2 seconds): Issuer approves the transaction
Clearing (~24-48 hours): Transaction data is batched and reconciled
Settlement (~2-3 business days): Actual funds move between banks via ACH/wire

During this 2-3 day window:

The merchant doesn't have the money
The consumer's bank has put a hold on the funds
Multiple intermediaries are reconciling ledgers
Each intermediary takes a fee

How OpenPasskey Settlement Works

Tap (~500ms): Card signs transaction with P-256
Verification (~2 seconds): RIP-7212 precompile verifies signature on Base L2
Settlement (~3 seconds): AUD stablecoin transfers to merchant's CREATE2 receiver

Total time: under 6 seconds.

The ClearingVault

Our settlement happens through a ClearingVault smart contract. When a valid card tap is verified:

The ClearingVault checks the P-256 signature (via RIP-7212)
Verifies the transaction hasn't been replayed (nonce check)
Routes AUD stablecoins to the merchant's dedicated receiver address
The receiver is a CREATE2 address, deterministically generated from the merchant's ID

Each merchant gets their own receiver address. Funds are instantly accessible.

Why Stablecoins?

Regulated AUD stablecoins maintain a 1:1 peg with the Australian dollar, backed by AUD reserves held in regulated Australian institutions.

For the merchant, the experience is: tap happens, AUD appears in their account. The fact that settlement happens on-chain is invisible.

The Cost Comparison

	Visa	OpenPasskey
Settlement time	2-3 business days	~5 seconds
Interchange fee	0.3-0.8%	0%
Scheme fee	~0.05%	0%
On-chain gas	N/A	<$0.001
Merchant receives	99.2-99.7%	~100%

For Developers

The ClearingVault is a standard Solidity contract deployed on Base. The key innovation is using RIP-7212 to bridge the gap between EMV card cryptography (P-256) and on-chain settlement.

This pattern (physical device signature → on-chain verification → instant settlement) is applicable beyond payments: access control, ticketing, supply chain, identity.

3,200+ users, 20+ Sydney cafes, settling in seconds. OpenPasskey | @OpenPasskey

How 3 People Built a Card Network in 10 Months with Zero Funding

Alfred Zhang — Fri, 03 Apr 2026 08:06:33 +0000

In January 2025, three engineers in Sydney started building a payment network to compete with Visa.

By November 2025, they had 20+ cafes live with 3,200+ users. Zero external funding. No VC. No grants (yet).

Here's what that actually looked like.

The Team

Victor Zhang: Co-invented Ethereum token standards ERC-5169 and ERC-7738. Co-founded AlphaWallet. 8 years building on Ethereum.
James Brown: Co-founded AlphaWallet. 25 years systems engineering. IoT firmware expert.
Cindy Chuah: Growth and merchant success. Previously scaled 1,500+ SMBs at Booking.com and TripAdvisor.

No payments industry veterans. No card network experience. Just engineers who understood cryptography and a growth person who understood merchants.

Month 1-3: The IIN

The first thing we did was apply for our own Issuer Identification Number from ISO. This is the same identifier that Visa and Mastercard use. Without it, you can't issue cards that work in the existing payment ecosystem.

Getting an IIN means you're recognized at the same level as Visa. You're in routing tables. Terminals read your cards.

Month 3-6: The Card

We built a custom applet for JCOP4 (Java Card Open Platform) chips. The applet:

Generates a P-256 key pair in the card's secure element
Implements EMV contactless protocol
Signs transaction data on each tap
Works identically to a Visa card from the terminal's perspective

Simultaneously, we built the mobile NFC version using Host Card Emulation (HCE) and a QR code payment option using ERC-681.

Month 6-8: The Settlement Layer

This is where the blockchain part comes in. We built a ClearingVault smart contract on Base L2 (Coinbase's Ethereum layer 2) that:

Accepts P-256 signatures from card taps
Verifies them on-chain via the RIP-7212 precompile
Routes AUD stablecoins to merchant-specific CREATE2 receivers
Enables instant settlement

Month 8-10: Going Live

We launched with a loyalty solution first. Cafe customers get a card, tap for rewards, build the habit. Then payments come next.

The results:

3,200+ wallet users
45,509 total transactions
AU$66,000 in volume
4.5x industry average week-12 retention
20+ Sydney cafes

Month 11: Blackbird Giants

Blackbird Ventures (Australia's largest VC, Canva's earliest investor) selected us for Giants Cohort 11. This isn't investment, it's an accelerator program. But it's validation from the most respected VC in the country.

What We Learned

The IIN is everything. Without it, you're just another crypto card on Visa's rails.
EMV compatibility is the distribution hack. Merchants don't need to change anything.
Start with loyalty, add payments. Users build the tap habit first.
3 people is enough. If you know the tech deeply, you don't need a large team.
Zero funding forces focus. We couldn't build features nobody wanted.

What's Next

The RBA just banned card surcharges in Australia. Mid-2026, they're opening a consultation on mobile wallets and BNPL. The regulatory environment is shifting in our favor.

We're building TCP/IP for money. One cafe tap at a time.

OpenPasskey | @OpenPasskey

EMV: The Global Standard That Makes OpenPasskey Work at Any Terminal

Alfred Zhang — Fri, 03 Apr 2026 07:58:30 +0000

11 billion cards. 100+ million terminals. One standard.

EMV (Europay, Mastercard, Visa) is the global standard for chip card payments. It's why your Australian Visa card works at a terminal in Tokyo. And it's why our card works at the same terminal Visa does.

What EMV Actually Standardizes

EMV defines:

Physical card dimensions and chip placement
Communication protocol between card and terminal (contact and contactless)
Cryptographic authentication (card proves it's genuine)
Transaction flow (authorization, clearing, settlement)
Application selection (how the terminal picks which card app to use)

The key insight: EMV doesn't require Visa or Mastercard. It's an open standard. Any card issuer with an IIN from ISO can build a card that speaks EMV.

How Terminal Routing Works

When you tap a card, the terminal:

Reads the card's AID (Application Identifier)
Matches it against the terminal's supported applications
Routes the transaction to the appropriate network

Visa's AID starts with A0000000031010. Mastercard's starts with A0000000041010.

OpenPasskey has its own AID. When we're in an acquirer's routing table, their terminals recognize our card just like they recognize Visa.

The Contactless (NFC) Part

Modern EMV contactless uses ISO 14443 for NFC communication. When you tap:

Terminal emits RF field (13.56 MHz)
Card's antenna harvests power from the field
Card and terminal exchange APDUs (Application Protocol Data Units)
Card signs transaction data
Terminal receives signature and payment details

This happens in under 500ms.

Our Java Card applet implements this exact protocol. A terminal can't tell the difference between tapping our card and tapping a Visa.

Why This Is Our Moat

EMV compatibility means:

No new terminals needed (merchants change nothing)
Familiar UX (tap like you always do)
Global potential (EMV is used in 100+ countries)
Any acquirer can add us in approximately one day

The payment industry has spent decades building EMV infrastructure. We're using that infrastructure with different rails underneath.

The Three Rails

All three of our payment methods speak EMV-compatible protocols:

Physical card (Java Card NFC applet)
Mobile phone (Host Card Emulation, same protocol)
QR scan (ERC-681 URI, for wallets without NFC)

All three settle through the same on-chain pipeline.

The Numbers

3,200+ users, 20+ Sydney cafes
45,509 transactions, AU$66K volume
3 people, 10 months, zero external funding
Blackbird Giants Cohort 11

OpenPasskey | @OpenPasskey

RIP-7212: The Precompile That Makes Card Payments On-Chain

Alfred Zhang — Fri, 03 Apr 2026 07:56:55 +0000

If you're building payment infrastructure on Ethereum L2s, RIP-7212 is the most important precompile you've never heard of.

The Problem

EMV payment cards (Visa, Mastercard, and now OpenPasskey) use P-256 (secp256r1) elliptic curve cryptography. Ethereum natively supports secp256k1 (a different curve). Verifying a P-256 signature in Solidity costs approximately 300,000 gas, making on-chain card payment verification economically impractical.

The Solution: RIP-7212

RIP-7212 adds a precompiled contract for P-256 signature verification at address 0x100. It reduces verification cost from ~300K gas to ~3,450 gas.

This is deployed on:

Base (Coinbase's L2)
Optimism
Polygon
Arbitrum
And several other L2s

Why It Matters for Payments

With RIP-7212, you can:

Verify EMV card signatures on-chain at minimal cost
Build trustless payment settlement without centralized processors
Enable card-to-blockchain bridges that don't require trusted intermediaries

How We Use It at OpenPasskey

Our payment flow:

Card Tap → P-256 Signature → Base L2 → RIP-7212 Verify → ClearingVault → Merchant

Customer taps their OpenPasskey card (Java Card with P-256 key pair)
Card signs transaction data (amount, merchant, nonce)
Signature submitted to Base L2
Smart contract calls RIP-7212 precompile to verify (~3,450 gas, sub-cent)
ClearingVault releases AUD stablecoins to merchant's CREATE2 receiver
Merchant gets AUD in their bank account

Total on-chain cost: fractions of a cent.
Settlement time: seconds.
Intermediary fees: zero.

The Broader Implication

There are 11+ billion EMV cards in circulation globally. All modern ones use P-256 or compatible curves. RIP-7212 means any of these cards could theoretically interact with on-chain settlement.

We're proving this with physical cards in 20+ Sydney cafes. 3,200+ users. 45,509 transactions.

For Developers

If you're building on Base or any L2 with RIP-7212:

// Verify P-256 signature via precompile
function verifyP256(
    bytes32 messageHash,
    bytes32 r,
    bytes32 s,
    bytes32 x,
    bytes32 y
) internal view returns (bool) {
    (bool success, bytes memory result) = address(0x100).staticcall(
        abi.encode(messageHash, r, s, x, y)
    );
    return success && abi.decode(result, (uint256)) == 1;
}

This opens up payment applications that were previously impossible on-chain.

OpenPasskey | @OpenPasskey