Skip to main content

Caching

The Mina SDK includes a built-in caching layer for chains, tokens, balances, and quotes. This reduces API calls, improves performance, and provides fallback data when the network is unavailable.

Cache TTLs

Each data type has a different cache TTL (Time To Live) based on how frequently the data changes:
Quote caching respects the quote’s expiresAt timestamp. Even if the cache TTL has not passed, expired quotes are not returned from cache.

Cache Classes

The SDK provides four cache classes for different data types:

ChainCache

Caches chain data including metadata and route connections.

TokenCache

Caches token lists per chain and bridgeable token lists.

BalanceCache

Caches user balances with request deduplication and debouncing.

QuoteCache

Caches quote results keyed by quote parameters.

Invalidating Cache

The SDK provides methods to manually invalidate cached data when you need fresh data.

Using the Mina Client

Using Standalone Functions

The isStale Flag

Many SDK responses include an isStale flag that indicates whether the data came from an expired cache (used as a fallback when the API is unavailable).
When isStale is true, the data may not reflect recent changes. Always inform users when displaying stale data, especially for balance and quote information.

Custom Cache Instances

By default, standalone functions use a shared default cache. For isolation (e.g., in server environments with multiple tenants), create separate cache instances:
The Mina client automatically creates its own isolated cache instances. Each new Mina() call has separate caches, preventing cross-contamination between client instances.

Resetting Default Caches

For testing or when you need to completely reset the default caches:

Balance Cache Features

The balance cache includes additional features for optimal performance:

Request Deduplication

Concurrent requests for the same balance are deduplicated:

Debouncing

Rapid balance requests are debounced with a 300ms window (BALANCE_DEBOUNCE_MS) to prevent API flooding:

Best Practices

Let Cache Work

Avoid manually invalidating cache unless necessary. The TTLs are optimized for typical use cases.

Check Staleness

Always check isStale when displaying critical data like balances. Warn users appropriately.

Pre-warm Cache

Fetch chain and token data on app startup to warm the cache before users need it.

Isolate Server Caches

In multi-tenant server environments, create separate cache instances per tenant.

Example: Pre-warming Cache on Startup