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.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/dotandev/hintents/llms.txt
Use this file to discover all available pages before exploring further.
How caching works
Erst automatically caches transaction data on your local filesystem:First fetch
When you debug a transaction, Erst fetches data from the RPC endpoint and caches it locally.
Cache directory location
Erst stores cached data in a platform-specific location:- Linux
- macOS
- Windows
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:- 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:List cached transactions
View all cached transaction hashes:Clean the cache
Manually clean old cache entries:Force clean without prompt
Automate cache cleaning:Cache configuration
Maximum cache size
Configure the cache size limit:Disable caching
Disable the cache entirely:- 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
| File | Content |
|---|---|
envelope.xdr | Transaction envelope (binary XDR) |
result_meta.xdr | Transaction result metadata |
ledger_entries.json | Ledger state snapshot |
metadata.json | Cache metadata (timestamp, size) |
Offline workflows
Development workflow
Work efficiently during development:Team collaboration
Share transaction data with teammates:CI/CD integration
Use caching in continuous integration:.github/workflows/test.yml
- 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):LRU eviction
The cache manager uses Least Recently Used eviction:- Tracks access time: Updates timestamp on each cache hit
- Checks size limit: Compares total cache size to configured maximum
- Sorts by age: Identifies oldest accessed files first
- 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:- Preparing for offline work
- Batch analysis of multiple transactions
- Demo preparation
Cache export for archival
Export entire cache for backup:Network-specific caching
Caches are separated by network to prevent conflicts:Troubleshooting
Cache corruption
If the cache becomes corrupted: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:- Fetch once with network
- Iterate offline with cache
- Save RPC bandwidth and time
Export important transactions
Archive transactions you’ll need long-term:Next steps
- Learn about Transaction debugging workflows
- Use the Interactive trace viewer with cached transactions
- Generate Performance profiling flamegraphs offline