🧵 Why Solana tx_hash & address take more storage than EVM

Source: Dev.to

After decoding on‑chain transactions and saving them to a database, I noticed that Solana transaction hashes and addresses consume more storage than their EVM counterparts.

1️⃣ tx_hash size

EVM

• Hex encoding
• 0x + 64 hex characters → ~66 ASCII bytes (0‑9a‑f)

Solana

• Base58 encoding
• ~88–90 ASCII characters (1‑9A‑H‑J‑N‑P‑Z a‑k‑m‑z)

➡️ Solana tx_hashes are ~35–40 % larger.

2️⃣ Address size

EVM address

• 20 bytes → hex (40 chars + 0x)
• Strong prefix patterns, lower entropy

Solana address

• 32 bytes → Base58
• Wider charset, higher entropy

➡️ Similar visible length, but Solana compresses less efficiently.

3️⃣ Compression matters

Storage engines (Snappy, Zstd) favor:

• Repeated prefixes
• Low‑entropy strings

Hex (0‑9a‑f) compresses far better than Base58.

➡️ EVM data shrinks more effectively at the block level.

4️⃣ Real‑world impact

At scale:

• Billions of transactions
• Multiple address fields per transaction

Even small per‑field differences accumulate, leading to huge disk‑cost differences.

5️⃣ Takeaway

Solana optimizes for

• Signatures
• Runtime performance
• Parallel execution

EVM unintentionally optimizes for

• Storage efficiency
• Analytics
• Long‑term indexing

Different trade‑offs; no outright winner—just design choices.

About txdecoder.xyz

Transaction decoding API — standardizing blockchain data into one unified, readable schema on Ethereum, Base, BSC, Solana.

• Website:
• X:
• Telegram:
• Telegram channel:
• Blog: