Hey! I ran a full scan of Meteora DLMM on mainnet and benchmarked on-chain LZ4 compression for idle BinArray accounts. Sharing in case the team finds it useful.
Mainnet scan (script, full scan of all 139,185 pools):
| Status |
Count |
% |
| Inactive (no tx > 30 d) |
125,156 |
89.9% |
| Active |
14,029 |
10.1% |
That's 331,732 BinArray accounts (10,136 B each) sitting idle on dead pools.
On-chain compression benchmark (script, 50 random inactive accounts):
SOL price: $82.25 (Binance)
Sampled 50 BinArrays from 331,732 inactive
BinArray size from scan: 10 136 B
Upload path: storeRaw (≤12 KB)
# Pubkey RawSz CompSz Ratio CompCU DecompCU RentSaved
────────────────────────────────────────────────────────────────────────────────────────
1 8uiKAN…AdHpg7 10136 B 1082 B 9.4x 121,214 61,862 0.0630 SOL
...
50 H3ocGz…EDVJht 10136 B 1156 B 8.8x 123,594 64,253 0.0625 SOL
────────────────────────────────────────────────────────────────────────────────────────
Raw size: 10136 B avg (min 10136 B, max 10136 B)
Compressed size: 1606 B avg (min 787 B, max 3620 B)
Compression ratio: 7.59x avg
Compress CU: 136,990 (one-time keeper cost)
Decompress CU: 61,960 (per chunk read, on demand)
Rent saved: 0.059372 SOL/account
Upload path: storeRaw + compressStoredChunked
────────────────────────────────────────────────────────────────────────────────────────
All inactive Meteora DLMM BinArrays on mainnet
(source: benchmark/meteora/scan.ts)
inactive BinArrays: 331,732
recoverable rent: ~19695 SOL (~$1619951 at $82.25/SOL)
────────────────────────────────────────────────────────────────────────────────────────
How it works: densol is a no_std LZ4 library that runs inside the SBF VM (fits within 32 KB heap, no libc). BinArray at 10 KB uses ChunkedLZ4, 4 KB chunks processed sequentially, ~4 KB heap peak per chunk.
Since BinArray is a zero-copy account, integration would use a hibernation pattern. Discriminator flag marks the account as compressed, the compressed bytes occupy the shrunken account, and on first transaction event the program decompresses and restores the account.
For curiosity, has this been considered ever?
Hey! I ran a full scan of Meteora DLMM on mainnet and benchmarked on-chain LZ4 compression for idle
BinArrayaccounts. Sharing in case the team finds it useful.Mainnet scan (script, full scan of all 139,185 pools):
That's 331,732
BinArrayaccounts (10,136 B each) sitting idle on dead pools.On-chain compression benchmark (script, 50 random inactive accounts):
How it works: densol is a
no_stdLZ4 library that runs inside the SBF VM (fits within 32 KB heap, no libc).BinArrayat 10 KB usesChunkedLZ4, 4 KB chunks processed sequentially, ~4 KB heap peak per chunk.Since
BinArrayis a zero-copy account, integration would use a hibernation pattern. Discriminator flag marks the account as compressed, the compressed bytes occupy the shrunken account, and on first transaction event the program decompresses and restores the account.For curiosity, has this been considered ever?