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

# CAIP Identifiers

> Learn the CAIP-10 account forms, the CAIP-19 asset forms, and the rules for each B2B API field.

The B2B API uses [CAIP](https://github.com/ChainAgnostic/CAIPs) identifiers for
accounts and assets. CAIP gives EVM and non-EVM resources one wire format.
Fields that end in `AccountId` or `assetId` use CAIP. Do not send bare
addresses in these fields.

Two deliberate exceptions appear in the B2B API:

* Enrollment and chain activation accept numeric `chainIds`. These values
  select configured chains. They do not identify an account or an asset.
* EIP-712 requires a bare EVM address in `domain.verifyingContract`.

## CAIP-10 account forms

CAIP-10 identifies an account. The B2B API uses two forms:

### Chain-agnostic: `<namespace>:0:<address>`

Use this form when an account has the same address on each chain in a
namespace. An EVM externally owned account (EOA) uses this form. The chain
reference is the literal string `0` as specified in
[CAIP-10 §Abstract Account Addresses](https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-10.md#abstract-account-addresses).

```
eip155:0:0xabcdef0000000000000000000000000000000001
```

Use this form for end-user wallets (`ownerAccountId`) and agent wallets
(`agentAccountId`).

### Chain-bound: `<namespace>:<chainId>:<address>`

Use this form when an account exists on one chain only. Each smart-contract
account is chain-bound because its deployment exists on one chain.

```
eip155:8453:0xe3a2d1f49aee887e42655b56371d4d76bbf58058
```

Use this form for portfolio smart accounts (`SmartAccount.accountId`) and
withdrawal recipients (`recipientAccountId`).

### Solana accounts

Solana does not have a chain-agnostic `0` form. Solana accounts use the
mainnet CAIP-2 reference as the chain segment. This reference is the chain
genesis hash.

```
solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp:<base58>
```

Use this form for these accounts:

* Solana-rooted owner wallets (`ownerAccountId`, Model B)
* The pooled agent (`agentAccountId`)
* Swig sub-account smart accounts (`SmartAccount.accountId`)

EVM-rooted Solana enrollment (Model A) keeps the EVM
`eip155:0:<addr>` owner form. Only the returned smart accounts use `solana:`
addresses.

## Rules for each field

| Field                    | Form                                                                                      | Why                                                                     |
| ------------------------ | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| `ownerAccountId`         | EVM: chain-agnostic `eip155:0:<addr>`. Solana (Model B): `solana:<ref>:<base58>`          | The EVM owner EOA works on every EIP-155 chain. Solana has no `0` form. |
| `agentAccountId`         | Matches the owner namespace: `eip155:0:<addr>` or `solana:<ref>:<base58>`                 | Same reasoning                                                          |
| `SmartAccount.accountId` | Chain-bound `eip155:<chainId>:<addr>` (EVM) or `solana:<ref>:<base58>` (Swig sub-account) | A smart account exists only at that chain/address                       |
| `recipientAccountId`     | Chain-bound. The API rejects a chain-agnostic value.                                      | Funds move on one chain. `eip155:0:<addr>` is ambiguous.                |

### Validation

The API validates and normalizes each CAIP-10 string for its namespace. EVM
addresses are not case-sensitive. The API converts them to lowercase.
Therefore, uppercase and lowercase EVM addresses are equivalent for lookup.

Solana base58 addresses are case-sensitive. The API keeps their case.

## CAIP-19 for Assets

CAIP-19 identifies an asset. The B2B API uses it for strategy allocation
`assetId`s and withdrawal `assetId`s.

### ERC-20 on EVM

```
eip155:<chainId>/erc20:<address>
```

Example for USDC on Ethereum mainnet:

```
eip155:1/erc20:0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48
```

### SPL on Solana

```
solana:<chainReference>/spl:<mint>
```

### Common IDs

| Asset           | CAIP-19                                                                                    |
| --------------- | ------------------------------------------------------------------------------------------ |
| USDC (Ethereum) | `eip155:1/erc20:0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48`                                |
| USDT (Ethereum) | `eip155:1/erc20:0xdac17f958d2ee523a2206206994597c13d831ec7`                                |
| USDC (Base)     | `eip155:8453/erc20:0x833589fcd6edb6e08f4c7c32d4f71b54bda02913`                             |
| USDC (Solana)   | `solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp/spl:EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v` |

## Build CAIP strings

Do not manually join CAIP strings in the client. A missing `0x`, incorrect
case, or incorrect chain reference produces `400 API_400`. Use a CAIP-10 or
CAIP-19 library. If you cannot use a library, use these canonical forms:

```
<namespace>:<reference>:0x<address>                    # CAIP-10 EVM
<namespace>:<reference>/<assetNamespace>:<assetRef>    # CAIP-19
```

Example for an EVM smart account on Base:

```
eip155:8453:0xe3a2d1f49aee887e42655b56371d4d76bbf58058
```

## Exception: EIP-712 `verifyingContract`

In a signed EIP-712 envelope, `domain.verifyingContract` is a bare EVM
address. It is not a CAIP-10 identifier. EIP-712 requires this form because
wallets do not use CAIP for this field.

This exception applies only to the signed envelope. Do not use this form for
other fields.

## Common errors

* **Do not send bare hex to an `*AccountId` field.** The API rejects bare hex.
  Convert the value to the correct CAIP-10 form.
* **Do not use `eip155:0:<addr>` as a withdrawal recipient.** A withdrawal
  recipient must be chain-bound.
* **Do not send a chain-bound EVM owner during enrollment.** Use
  `eip155:0:<addr>` for an EVM owner. Model B Solana enrollment is the
  exception. It uses the mainnet `solana:5eykt4…:<base58>` form.
* **Do not compare raw EVM account strings.** Normalize EVM identifiers with a
  CAIP-10 parser before comparison. Do not convert Solana identifiers to
  lowercase.