Skip to main content
Cherp supports three chains, each with distinct confirmation strategies and memo mechanisms.

Solana

PropertyValue
CAIP-2 IDsolana:5eykt4UsFv8P8NJdTREpY1vzqKq2Kvdp
Testnetsolana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1
Block time~400ms
ConfirmationCommitment levels (confirmed ~400ms, finalized ~13s)
Native tokenSOL

Memo strategy — reference key

Cherp generates a random ed25519 keypair at intent creation. The public key serves as the reference. The SDK includes this pubkey as a read-only account in the transfer transaction. Cherp detects fulfillment by monitoring signatures for this reference address — no memo contract or additional wallet-layer cooperation needed.

ATA handling

When the recipient doesn’t have an Associated Token Account (ATA) for the token, the build endpoint includes createAssociatedTokenAccount atomically with the transfer. The response includes ataRentLamports so the SDK can display it as a line item before signing. Rent is charged to the fulfiller’s SOL balance.

Dropped transactions

Solana transactions expire after ~60 blockhashes (~60s). If Cherp detects that a transaction was dropped, it resets the intent to created with retryRequired: true. The SDK prompts the fulfiller to re-sign with a fresh blockhash.

Base

PropertyValue
CAIP-2 IDeip155:8453
Testneteip155:84532 (Base Sepolia)
Block time~2s
ConfirmationBlock count (10 blocks, ~20s)
Native tokenETH

Memo strategy — singleton memo contract

A minimal immutable Memo contract is deployed once per EVM chain. For ERC-20 transfers, the SDK emits two instructions in one transaction:
  1. token.transfer(recipient, amount)
  2. memo.record(bytes32 reference) — zero-value call to singleton
Cherp watches for memo.Recorded(bytes32 indexed reference, address indexed sender, bytes32 indexed txHash) events and correlates by tx hash. The reference is a bytes32 encoding of the intent’s reference ID, prefixed pf:.

Tempo

PropertyValue
CAIP-2 IDeip155:4217
Testneteip155:42431 (Moderato)
Block time~500ms
ConfirmationSingle block (deterministic BFT finality, ~1s end-to-end)
Native tokenNone (fees paid in USDC)

Memo strategy — TIP-20 transferWithMemo

Tempo’s TIP-20 token standard has transferWithMemo(address to, uint256 amount, bytes32 memo) built in. No external memo contract needed — a single function call handles transfer and memo. Cherp listens for TransferWithMemo events to detect fulfillment.

Important differences

  • No native gas token. Transaction fees are denominated in USDC (same token as payment). The SDK must account for this — the fee comes out of the fulfiller’s USDC balance, not a separate ETH balance.
  • Never call eth_getBalance — it returns a fixed placeholder. All balances come from token.balanceOf(address).
  • Token addresses are resolved at runtime from the Tempo token list registry. Cache with a 24-hour TTL.
  • Use viem v2.43.0+ for full Tempo Transaction (type 0x76) support.
  • Deterministic finality. Simplex BFT provides single-block finality. There are no re-orgs, no probabilistic confirmation windows. A single block confirmation maps to both confirmed and finalized states simultaneously.