Skip to main content
Offline analysis enables you to debug and analyze Stellar smart contract transactions without requiring network connectivity. Erst’s caching system stores transaction data locally, allowing you to work offline or reduce network requests during repeated analysis.

How caching works

Erst automatically caches transaction data on your local filesystem:
1

First fetch

When you debug a transaction, Erst fetches data from the RPC endpoint and caches it locally.
2

Cache storage

Transaction envelopes, ledger state, and metadata are stored in the cache directory.
3

Subsequent access

Future debug sessions use the cached data automatically, no network required.
4

Automatic cleanup

The cache manager maintains size limits using LRU (Least Recently Used) eviction.

Cache directory location

Erst stores cached data in a platform-specific location:

Custom cache directory

Override the default location:

Debugging offline

From cached transactions

Once a transaction is cached, debug it without network access:
Erst automatically detects cached data and uses it when available. No special flags needed.

From raw XDR files

Debug transactions from XDR envelope files:
This is useful for:
  • Analyzing transaction proposals before submission
  • Debugging transactions from external sources
  • Working with archived transaction data
  • Testing locally simulated transactions
XDR-based debugging may have limited ledger state information compared to network-fetched transactions.

Cache management

View cache size

Check current cache usage:
Output:

List cached transactions

View all cached transaction hashes:
Output:

Clean the cache

Manually clean old cache entries:
The cleaner uses LRU (Least Recently Used) eviction:

Force clean without prompt

Automate cache cleaning:
Force cleaning deletes cached data without confirmation. Make sure you have network access to re-fetch if needed.

Cache configuration

Maximum cache size

Configure the cache size limit:
Default: 1 GB (1,073,741,824 bytes)

Disable caching

Disable the cache entirely:
Useful for:
  • Ensuring fresh data from the network
  • Testing cache behavior
  • Debugging cache-related issues

Clear specific transaction

Remove a specific transaction from cache:

Cache file structure

The cache directory is organized by network and transaction hash:

Cache file types

Offline workflows

Development workflow

Work efficiently during development:
1

Initial debug with network

Debug your transaction once while online:
2

Work offline

Continue debugging the same transaction offline:
3

Analyze variants

Use the cached data for different analysis modes without re-fetching.

Team collaboration

Share transaction data with teammates:
1

Export cache entry

Zip the cached transaction directory:
2

Share archive

Send the archive to teammates via Slack, email, or shared drive.
3

Import on teammate's machine

Extract to their cache directory:
4

Debug offline

They can now debug without network access:

CI/CD integration

Use caching in continuous integration:
.github/workflows/test.yml
Benefits:
  • Faster CI runs (no repeated network fetches)
  • Consistent test data across runs
  • Works even if RPC is temporarily unavailable

Cache performance

Cache hit vs miss

Cache hit (fast):
Cache miss (slower):

LRU eviction

The cache manager uses Least Recently Used eviction:
  1. Tracks access time: Updates timestamp on each cache hit
  2. Checks size limit: Compares total cache size to configured maximum
  3. Sorts by age: Identifies oldest accessed files first
  4. Deletes until under limit: Removes files until cache is 50% of max size
LRU ensures frequently used transactions stay cached while old, unused data is removed automatically.

Advanced caching

Pre-warming the cache

Cache multiple transactions in advance:
Useful for:
  • Preparing for offline work
  • Batch analysis of multiple transactions
  • Demo preparation

Cache export for archival

Export entire cache for backup:
Restore from backup:

Network-specific caching

Caches are separated by network to prevent conflicts:
Both transactions are cached independently under different network directories.

Troubleshooting

Cache corruption

If the cache becomes corrupted:
1

Clear corrupted cache

2

Or delete manually

3

Re-fetch transaction

Permission issues

Fix cache directory permissions:

Disk space issues

Reduce cache size or clean manually:

Best practices

Set appropriate size limits

Balance disk space and convenience:
  • Small disk: 256-512 MB cache
  • Medium disk: 1-2 GB cache (default)
  • Large disk: 5-10 GB cache for extensive analysis

Clean periodically

Schedule automatic cache cleaning:

Use offline mode for iteration

When debugging repeatedly:
  1. Fetch once with network
  2. Iterate offline with cache
  3. Save RPC bandwidth and time

Export important transactions

Archive transactions you’ll need long-term:

Next steps