> ## Documentation Index
> Fetch the complete documentation index at: https://docs.crycketpay.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Supported chains

> Solana, Base, and Tempo — chain-specific behaviors and configuration

Crycket supports three chains, each with distinct confirmation strategies and memo mechanisms.

## Solana

| Property     | Value                                                      |
| ------------ | ---------------------------------------------------------- |
| CAIP-2 ID    | `solana:5eykt4UsFv8P8NJdTREpY1vzqKq2Kvdp`                  |
| Testnet      | `solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1`                  |
| Block time   | \~400ms                                                    |
| Confirmation | Commitment levels (`confirmed` \~400ms, `finalized` \~13s) |
| Native token | SOL                                                        |

### Memo strategy — reference key

Crycket 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. Crycket 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 Crycket 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

| Property     | Value                          |
| ------------ | ------------------------------ |
| CAIP-2 ID    | `eip155:8453`                  |
| Testnet      | `eip155:84532` (Base Sepolia)  |
| Block time   | \~2s                           |
| Confirmation | Block count (10 blocks, \~20s) |
| Native token | ETH                            |

### 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

Crycket 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

| Property     | Value                                                      |
| ------------ | ---------------------------------------------------------- |
| CAIP-2 ID    | `eip155:4217`                                              |
| Testnet      | `eip155:42431` (Moderato)                                  |
| Block time   | \~500ms                                                    |
| Confirmation | Single block (deterministic BFT finality, \~1s end-to-end) |
| Native token | None (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. Crycket 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.