Private Claim Links for Solana and EVM: Send USDC Without Exposing the Code

Sending someone USDC is easy if they are already crypto native, already on the right chain, and already comfortable copying addresses around.

Real users are not always like that.

Sometimes you want to send money first and let the recipient decide how to receive it later. Sometimes you want a short code you can paste into chat. Sometimes you want a private claim link that feels more like a modern gift card than a raw blockchain transfer.

That is what Payment Codes are for.

And now they work across both Solana and EVM, with a new private-claim-link flow that keeps the underlying code hidden until the recipient actually claims it.

What Shipped

RelAI Payment Codes now support two recipient experiences:

• Standard payment code: a short 8-character code the recipient redeems later
• Private claim link: a secure link that hides the raw code and asks the recipient to connect a wallet and sign once

• Solana: vault-backed payment codes
• EVM: escrow-backed payment codes on Base and SKALE

• Claim USDC: immediately receive the funds
• Claim code: reveal the hidden 8-character code and redeem later

The Problem

A normal on-chain payment asks for a destination address up front.

That sounds fine until you look at real-world flows:

• A support agent wants to issue a refund in chat
• A founder wants to send a reward in a Telegram DM
• A team wants to distribute promo credit without collecting wallets first
• An ops dashboard wants to trigger payouts before the recipient chooses Solana or EVM
• A user wants to share value with someone who is not yet fully onboarded

Payment Codes invert the flow:

1. Sender locks funds first
2. Sender shares a code or private link
3. Recipient finishes the payout later

Two Recipient Experiences

1. Standard payment code

The sender creates a one-time code such as D92T5TPW.

The recipient opens the redeem screen, enters the code, provides a payout address, and receives the funds.

This is the simplest mental model:

• short
• copyable
• easy to paste into chat
• no wallet connection required just to view the payout flow

2. Private claim link

The sender creates a claim link instead of exposing the raw code.

The recipient receives a link like:

https://relai.fi/claim/clm_2qY7...

When they open it, they do not see the hidden code directly. Instead, they:

• connect the right wallet type
• sign a claim message
• choose whether to claim USDC immediately or reveal the code

• more privacy
• less copy-paste friction
• stronger ownership semantics
• sender protection against early cancellation before expiry

One Mental Model, Two Settlement Systems

Under the hood, Solana and EVM use different infrastructure. The user-facing model stays nearly identical.

Solana

Solana payment codes are backed by program vaults.

The sender signs the vault funding transaction, the code is registered, and the recipient later redeems from the vault.

EVM

EVM payment codes are backed by escrow contracts.

The sender approves USDC, funds escrow on-chain, and RelAI registers the code with the associated settlement metadata.

For users, the important part is simpler:

• create a code or claim link
• share it
• recipient redeems later

Diagram: Standard Code Flow

Sender
  -> creates payment code
  -> funds Solana vault or EVM escrow
  -> receives 8-character code
  -> shares code with recipient
Recipient
  -> opens /redeem
  -> enters code
  -> adds payout address
  -> confirms redeem
  -> receives USDC

This is ideal when speed and simplicity matter more than hiding the code itself.

Diagram: Private Claim Link Flow

Sender
  -> creates payment code with Private claim link enabled
  -> funds Solana vault or EVM escrow
  -> receives claim token link
  -> shares link with recipient
Recipient
  -> opens /claim/
  -> connects wallet
  -> signs once
  -> chooses:
       A) Claim USDC now
       B) Claim code for later
  -> completes payout

The raw code stays hidden until the recipient intentionally unlocks it.

How Claim Links Work

A private claim link is not just a prettier URL. It changes the trust model.

Standard code

Anyone with the code can redeem it.

That is often exactly what you want. It behaves like a bearer instrument.

Private claim link

The claim link asks the recipient to prove control of a wallet before the hidden code is revealed or paid out.

The wallet type depends on the source settlement family:

• Solana claim link: recipient signs with a Solana wallet
• EVM claim link: recipient signs with an EVM wallet

Claim Mode 1: Claim USDC

This is the most direct path.

The recipient opens the link, signs once, and receives the funds.

Depending on the flow, they can:

• accept the default connected wallet as destination
• paste a different compatible destination address
• in supported cases, route payout to another supported destination network

Example

A support team issues a $25 refund:

Support agent -> Generate private claim link -> paste into support chat
Customer -> opens link -> signs -> receives USDC

No need to ask for a wallet address upfront.

Claim Mode 2: Claim Code

Sometimes the recipient is not ready to receive funds immediately.

They may want to:

• forward the code internally
• redeem later from another device
• separate wallet-signing from payout timing

The claim link is consumed, the hidden code is revealed to the authorized recipient, and they can later use the normal redeem flow.

Claim link -> wallet signature -> hidden code revealed -> later redeem via /redeem

This is especially useful for workflows where a link should establish ownership first, but payout should happen later.

Why the Cancel Lock Matters

Private claim links are designed to be safely shareable.

If a sender shares a claim link, then cancels it before the recipient opens it, the experience is terrible. The sender has effectively shared something that looks valid but is no longer redeemable.

To prevent that, claim-link funding can be cancel-locked until expiry.

That means:

• sender funds the code
• sender shares the private claim link
• sender cannot cancel it early while it is still valid
• after expiry, normal refund / cancellation paths can resume

Product Use Cases

1. Customer support refunds

Instead of asking the customer for a wallet address in the first message, the support agent sends a private claim link.

Benefits:

• faster resolution
• cleaner support scripts
• less address-copy risk
• better mobile UX

2. Referral rewards and community incentives

Want to reward contributors in Discord, Telegram, or Farcaster?

A private claim link is much cleaner than asking each user for a chain-specific address before you send.

3. Payroll and contractor payouts

For small ad hoc rewards, bounties, or one-off bonuses, a payment code works like a controlled digital voucher.

Create now. Recipient chooses the final wallet later.

4. Agent-to-human handoff

An internal agent can trigger a payment code automatically after a verified event.

Example:

AI ops agent detects successful task completion
  -> creates code or claim link
  -> sends it to human operator
  -> operator chooses when and where to receive funds

5. Embedded wallet onboarding

If your app supports both Solana and EVM, claim links help you avoid asking the user to pick everything upfront.

You can get money moving first, then let the recipient complete the last mile in the wallet context they already use.

Example: EVM Escrow-Backed Private Claim Link

For EVM networks, the sender first funds escrow on-chain, then registers the code with RelAI.

{
  "from": "0xSenderWallet",
  "code": "D92T5TPW",
  "value": 5000000,
  "validBefore": 1735000000,
  "settlementNetwork": "base-sepolia",
  "escrowMode": true,
  "claimLink": true,
  "fundingTxHash": "0xFundingTxHash..."
}

Response:

{
  "code": "D92T5TPW",
  "claimLink": true,
  "claimToken": "clm_2qY7...",
  "validBefore": 1735000000,
  "expiresIn": 300,
  "cancelLockedUntilExpiry": true
}

That claimToken becomes the shareable link.

Example: Frontend UX

From the sender side, the flow is intentionally simple:

const result = await createPaymentCode({
  amount: 5,
  network: 'base-sepolia',
  claimLink: true,
})
const shareUrl = ${window.location.origin}/claim/${result.claimToken}

From the recipient side, there are only two decisions:

• connect the right wallet
• choose claim-usdc or claim-code

Solana and EVM Differences That Matter

Most of the UX is shared, but a few details differ:

You do not need to design two separate payout products. You design one payment-code experience, then let the chain-specific backend handle the execution model.

Why This Is Better Than a Raw Transfer

Raw transfers are still great when the sender already knows the exact destination wallet.

Payment Codes are better when:

• the sender does not know the final destination yet
• the sender wants something shareable
• the recipient should choose when to receive funds
• the product wants to reduce copy-paste friction
• you want a stronger link-based UX than exposing a raw code

They are a product primitive, not just a smart contract trick.

Where This Fits in RelAI

Payment Codes sit next to RelAI's broader payment stack:

• direct x402 API payments
• cross-chain bridge settlement
• Solana vault flows
• EVM escrow flows
• private claim links

Not every payment should look like a wallet-to-wallet transfer form.

Sometimes the best payment UX is a short code. Sometimes it is a secure link. Sometimes it is a chain-agnostic handoff.

That is exactly what this feature unlocks.

Try It

You can create payment codes and private claim links from the RelAI UI today.

A good first test:

1. Create a code on Solana
2. Create a private claim link on Base or SKALE
3. Open the link in a different wallet context
4. Try both claim modes: claim-usdc and claim-code

Read more in the docs:

• Redeem Codes and Claim Links
• Payment Codes