Live on Base + SKALE

Payment Codes

Authorize a USDC transfer once. Anyone with the code redeems it later — no wallet, no gas, no being online required.

A Payment Code is an 8-character string like HJK7M8P3 that represents a pre-authorized USDC transfer. The payer signs once, the code lives on chain (in an escrow contract or registry), and any party can present the code to a relayer who settles the funds to a recipient address. The payer never opens their wallet again for that transaction.

Generate a codeRead the launch post

BLIK, but on-chain

If you've used BLIK in Poland — the 6-digit code your banking app generates that anyone can use to pay at a checkout — you already know the shape. Payment Codes are the same idea, but:

On-chain instead of banked
The code is registered or escrowed by a smart contract on Base, SKALE, or Solana — not by your bank's back office.
Longer-lived
BLIK codes expire in 2 minutes. Payment Codes you set TTL on yourself — default 24 hours, up to 7 days or longer for gift-card use cases.
No bank, no custody
Funds sit in an audited escrow contract. If RelAI vanished overnight, anyone with the code can still redeem directly via Etherscan.

The point: the redeemer doesn't need a wallet, doesn't need to hold USDC, doesn't need to pay gas. They just need to know what address the funds should land at. Gift cards, agent-to-agent commerce, point-of-sale checkout, batch payouts, “send a friend $20 and let them claim it on their schedule” — all become a single short string.

What you get

8-character code
Readable over a phone call, scannable from a QR, typeable on a numeric keypad. Drawn from a 32-symbol alphabet that drops ambiguous glyphs (no I, O, 0, 1, etc.).
Locked recipient (optional)
Set lockedPayee and only that one address can redeem. Code theft alone does nothing without the matching wallet.
Auto-refund on expiry
Codes have an explicit validUntil. If no one redeems before then, the payer cancels and reclaims the funds. No lost money.
Batch issuance
Generate up to 20 codes with a single wallet signature. Bulk payouts, gift-card runs, refund queues — one tx, twenty deliveries.

Variants

Payment Codes ship in a few flavours that share the same redemption flow but trade off visibility, lifecycle, and how the code can be shared. Pick the variant that fits the distribution channel and the privacy level you need.

Standard code

The 8-character base default. EVM escrow on Base / SKALE, SPL authorization on Solana. Optional lockedPayee, explicit TTL, refundable on expiry. Amount + counterparties are visible on chain after settlement.

Gift voucher

Same on-chain instrument as the standard code, presented as a downloadable PNG voucher (template + amount + code overlay). Useful for retail, events, promo drops — anywhere the code needs to look like something physical.

Claim link

URL-encoded code. Receiver clicks the link and lands on the redeem page with the code pre-filled. Good for SMS / email / chat distribution where typing 8 chars is friction.

Shielded link

Private claim link — the receiver picks any wallet, the on-chain hop hides the amount + counterparty graph via a ZK shielded note. Best when the payer wants privacy from third parties watching the chain.

Private payment codeBearer

~44-char base58 bearer code backed by Private Balance instead of public escrow. Whoever holds the string can redeem to any wallet — no link between issuer and receiver on chain. Requires you to top up a private balance first.

Private gift cardBearer

Same bearer + private-balance backing as above, but the seed is short enough to render as a Wi-Fi-style XXXX-XXXX-XXXX-XXXX code on a PNG voucher. Dictatable, scannable, printable — at the cost of lower entropy (80-bit vs 256-bit). Use for gift-card-sized amounts.

VariantBackingOn-chain privacyLockable to recipientAuto-refund
Standard / Gift voucher / Claim linkEVM escrow · SPL authNoneYes (lockedPayee)Yes, on TTL expiry
Shielded linkZK shielded noteAmount + counterparty hiddenNo (bearer)No expiry
Private payment code / gift cardPrivate Balance (credit-pool tree)Issuer ↔ receiver fully unlinkedNo (bearer)No expiry; cancel by self-cash-out

Private codes live in the Private Balance docs. They're a different on-chain product — based on a credit-pool tree and bearer keys — but integrated into the same /app/send and /app/codes surfaces so the user experience is unified. See Private codes & gift cards for the full flow, security model, and ergonomic trade-offs.

How to use it

For the payer
1.
Connect your wallet (MetaMask, Rabby, Phantom — anything that supports the standard signing flow).
2.
Open the send page at /app/send and pick the Payment Code option. Enter amount, optional TTL, optional locked recipient.
3.
Sign once. A single EIP-3009 (EVM) or SPL authorization (Solana) signature in your wallet. The funds either move into escrow on-chain, or the authorization is locked into a registry — depending on the network.
4.
Share the code: SMS, QR code, link, in-app handoff — whatever fits. The code itself is the bearer instrument.
For the redeemer
1.
Open the redeem page at /app/redeem (or scan the QR — it goes there).
2.
Enter the code + your payout address. No wallet connect, no gas in your pocket. If the code is lockedPayee-bound, only the matching address works.
3.
RelAI's relayer settles the transfer. USDC lands at the address you typed, on the network the code lives on. Status comes back via SSE for merchant flows.

Cross-chain bonus: a buyer holding only Solana USDC can pay an EVM merchant's invoice. The relayer accepts the SPL transfer on Solana and atomically forwards USDC to the merchant on Base or SKALE. The buyer never bridges; the relayer does.

Use cases

Gift cards

Pre-fund a code, print it on a card, sell at a kiosk. The buyer scans it whenever, claims their USDC to whatever wallet they have at that point — including one they don't even own yet.

Agent payouts

An autonomous agent issues a Payment Code at task completion. A human checks the work, types the code into their payout dashboard, USDC arrives. No agent custody, no agent gas.

Point-of-sale checkout

Merchant shows a QR with the invoice. Buyer scans, code generated from their wallet, merchant's POS auto-redeems and unlocks the order. Sub-10-second checkout, no chip-and-PIN.

Batch refunds

Issue 20 refund codes in one signature. Email each customer their code. They claim at their pace, you don't chase missing wallet addresses.

Send-a-friend-some-cash

Recipient doesn't have a wallet yet? Send them a code. They can create a wallet later and claim — TTL gives you a window to cancel if they never get around to it.

Cross-chain commerce

EVM merchant, Solana customer. The customer signs an SPL transfer; the relayer settles USDC on the merchant's chain. No bridge, no asset wrap, no manual handoff.

Networks

EVM — production
  • • Base Mainnet (chain 8453)
  • • Base Sepolia (testnet)
  • • SKALE Base Mainnet (chain 1187947933 — gasless)
  • • SKALE Base Sepolia (testnet)

Powered by EIP-3009 TransferWithAuthorization + user-funded escrow contract. Non-custodial after funding.

Solana — beta
  • • Solana Mainnet (beta)
  • • Solana Devnet

SPL transferChecked + custodial relayer vault. Useful primarily for the cross-chain Solana-buyer → EVM-merchant flow today.

Common questions

Is this private?+
Not by default. Payment Codes hide nothing on chain — the payer's address signs the authorization, and after settlement both addresses are visible. For privacy on top, pair Payment Codes with the private claim-link variant (ZK shielded note) or use the Private Balance primitive instead.
What if no one redeems my code?+
After validUntil passes, the payer can cancel and reclaim the funds. Default TTL is 24 hours; you can set it shorter or longer.
Can someone steal my code and drain my funds?+
A vanilla code is a bearer instrument — anyone with the string can redeem. For higher-value codes, set lockedPayee at creation time: then only that one address can redeem, and stealing the string alone does nothing.
What happens if RelAI goes offline?+
On EVM the funds are in an audited escrow contract. Anyone with the code can call escrow.redeem(code, payee) directly via Etherscan with no RelAI involvement. The backend is a UX layer, not a custody layer.
Is there a fee?+
A small protocol fee applies on redeem to cover relayer gas + service. Generation is free. Cancellation is free. Exact amounts vary by network and are surfaced in the dashboard before you confirm.
Can I generate many codes at once?+
Yes — up to 20 codes in one wallet signature via the batch endpoint. Useful for refund queues, gift-card runs, and bulk payouts. Requires an API key in the dashboard.
Does this work with Stripe or other off-chain checkouts?+
There's a Stripe-to-x402 bridge documented separately — for SaaS that already takes Stripe, you can accept Payment Codes alongside cards. The bridge handles reconciliation between fiat and on-chain.
Can I cancel a code before it expires?+
Yes if cancelLockedUntilExpiry is false (the default). Owner cancel reverts the funds. Set it to true for “must deliver or refund” merchant flows where you don't want the payer to yank funds after sharing the code.

Generate your first code

Open the dashboard, fund a code for a buck on Base Sepolia, redeem it to a fresh test address. End-to-end in under a minute.

Open the appPrivate Balance docs