Skip to main content

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.

The Glider V2 API uses CAIP identifiers for every on-chain value. This lets the same request shape work across EVM and non-EVM chains without any chain-specific fields. Bare hex addresses and numeric chain ids never appear on the wire.

​
The Two Forms of CAIP-10

CAIP-10 identifies an account. V2 uses two forms:

​
Chain-agnostic: <namespace>:0:<address>

Used when an account exists at the same address on every chain in the namespace — i.e., an EVM externally-owned account (EOA). The chain reference is the literal string 0 per CAIP-10 §Abstract Account Addresses. 
eip155:0:0xabcdef0000000000000000000000000000000001
Use this form for: end-user wallets (ownerAccountId), agent wallets (agentAccountId).

​
Chain-bound: <namespace>:<chainId>:<address>

Used when the account only exists at that (chain, address) pair — every smart-contract account is chain-bound, because a deployment exists on one chain only. 
eip155:8453:0xe3a2d1f49aee887e42655b56371d4d76bbf58058
Use this form for: portfolio smart accounts (SmartAccount.accountId), withdrawal recipients (recipientAccountId).

​
Rules Per Field

FieldFormWhy
ownerAccountIdChain-agnostic eip155:0:<addr>The owner EOA works on every EIP-155 chain
agentAccountIdChain-agnostic eip155:0:<addr>Same reasoning
SmartAccount.accountIdChain-bound eip155:<chainId>:<addr>A smart account exists only at that chain/address
recipientAccountIdChain-bound — rejected if chain-agnosticFunds move on a specific chain; eip155:0:<addr> is ambiguous

​
Validation

All CAIP-10 strings are validated and normalized. Mixed-case input is accepted; the address is lowercased, so eip155:1:0xABCDEF... and eip155:1:0xabcdef... are equivalent for lookup but you will always receive the lowercase form in responses.

​
CAIP-19 for Assets

CAIP-19 identifies an asset. V2 uses it for strategy allocation assetIds and withdrawal assetIds.

​
ERC-20 on EVM

eip155:<chainId>/erc20:<address>
Example — USDC on Ethereum mainnet: 
eip155:1/erc20:0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48

​
SPL on Solana

solana:<chainReference>/spl:<mint>

​
Common IDs

AssetCAIP-19
USDC (Ethereum)eip155:1/erc20:0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48
USDT (Ethereum)eip155:1/erc20:0xdac17f958d2ee523a2206206994597c13d831ec7
USDC (Base)eip155:8453/erc20:0x833589fcd6edb6e08f4c7c32d4f71b54bda02913

​
Building CAIP Strings

Avoid hand-concatenating CAIP strings on the client. Small mistakes (missing 0x, wrong checksum case, chain reference off by one) produce 400 API_400. Prefer a CAIP-10/19 library, or build from the canonical shapes: 
<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

Inside a signed EIP-712 typed-data envelope only, domain.verifyingContract is a bare EVM address, not a CAIP-10. This is dictated by EIP-712 itself — the field is what the user’s wallet renders during signing, and wallets do not understand CAIP. This exception is scoped to the signed envelope. Do not generalize it to other fields or other endpoints.

​
Common Pitfalls

  • Sending 0xabc... to a *AccountId field. Bare hex is always rejected. Wrap it in the appropriate CAIP-10 form first.
  • Sending eip155:0:<addr> as a withdrawal recipient. The chain-bound form is required; chain-agnostic is explicitly rejected.
  • Sending a chain-bound owner to enrollment. Enrollment expects chain-agnostic eip155:0:<addr> for owners. Chain-bound owners are rejected with 400.
  • Mixing cases for lookups. eip155:1:0xABC... and eip155:1:0xabc... normalize to the same value, but comparing raw strings on your side may miss a match. Compare either both normalized, or always compare via CAIP-10 parsing.