DEV Community: txdecoder.xyz

Streaming Blocks on Solana: Data Volume, Latency, and Unavoidable Trade-offs

txdecoder.xyz — Tue, 10 Feb 2026 02:21:11 +0000

Solana is known for high throughput and low latency.

But if you are building:

a block indexer
a transaction decoder
real-time analytics
monitoring or alerting systems

you will quickly realize:

Streaming blocks on Solana is not just about speed —

it’s about managing uncertainty, data volume, and trade-offs.

This post walks through:

how block streaming actually works on Solana
the main streaming approaches
why RPC latency becomes a bottleneck
and why commitment level choices matter more than you think

Solana does not really stream “blocks”

Solana is slot-based, not block-based.

Some important consequences:

a slot occurs roughly every ~400ms
not every slot produces a block
blocks may arrive late
confirmation levels change what data you receive

So when people talk about block streaming on Solana,

they are really talking about:

streaming execution results derived from slots, under different guarantees

Every streaming approach is just a different way to deal with this reality.

The three main block streaming approaches on Solana

1. RPC polling: latest slot → fetch block

The most basic approach:

call getSlot
fetch block data for that slot: getBlock / getParsedBlock
decode transactions and instructions

This is often the first implementation.

Why it looks appealing

simple to reason about
no persistent connections
easy to prototype

Why it breaks at scale

slots can be skipped
blocks may not exist yet
retries are frequent
RPC rate limits are hit quickly
Large transactions, instruction data cause high latency

You end up building:

retry loops
backfill logic
slot-to-block reconciliation

At low volume, it works.

At scale, it becomes fragile and expensive.

2. WebSocket streaming: `blockSubscribe`

A more event-driven approach:

subscribe via WebSocket
receive blocks pushed from the RPC node
choose commitment level (confirmed or finalized)

This feels closer to traditional block streaming.

Pros

fewer RPC round-trips
lower latency than polling
simpler flow control
fewer RPC call

Cons

typically limited to confirmed and finalized
processed is usually unavailable or unreliable
blocks may still be partial: may miss some instructions / inner instructions
provider behavior varies

You gain safety and simplicity,

but sacrifice ultra-low latency.

3. Validator-level streaming: Geyser gRPC

The most powerful — and most complex — option.

With a Geyser plugin:

data is streamed directly from validators
no RPC bottlenecks
near-zero latency
full instruction visibility

This is how serious Solana data platforms operate.

Pros

highest completeness
predictable performance
minimal retries
very low latency

Cons

requires validator access or partnerships
more complex infrastructure
higher operational cost

Geyser does not remove complexity —

it moves it into infrastructure, where it belongs.

The hidden cost: Solana block data is large

One of the most underestimated aspects of Solana streaming is data volume.

A single Solana block can contain:

hundreds or thousands of transactions
deeply nested instructions
large inner instruction trees
verbose account metadata

This has direct performance consequences.

RPC latency becomes the bottleneck

When fetching blocks via RPC:

response payloads are large
serialization and deserialization are expensive
network transfer dominates end-to-end latency

In practice:

getBlock often takes hundreds of milliseconds
under load, it can reach seconds
retries amplify the cost

Even with a fast decoder,

you are often waiting on the wire.

Why polling amplifies latency problems

A typical polling loop looks like:

getSlot
getBlock
retry if missing
refetch if commitment changes

Now combine that with:

skipped slots
partial blocks
confirmation re-checks

The result:

high tail latency
uneven block arrival
backpressure in your pipeline
escalating RPC costs

This is why many Solana indexers feel:

fast in tests, unstable in production

Commitment levels are not just a setting

Every Solana streaming setup must answer one question:

How wrong am I willing to be, and for how long?

Geyser gRPC: fast and stable at `processed`

With Geyser:

data comes directly from the validator execution path
processed commitment is commonly used in practice
latency is extremely low
stream stability is high

Because execution data is emitted immediately:

blocks arrive consistently
instruction data is complete
reprocessing logic is predictable

In practice, Geyser + processed is often:

the fastest
and the most operationally stable streaming setup on Solana.

This is ideal for:

real-time decoding
monitoring systems
low-latency analytics
applications that tolerate short-lived reorgs

WebSocket `blockSubscribe`: safer, but slower

In contrast, blockSubscribe typically:

supports only confirmed and finalized
does not reliably expose processed
varies across RPC providers

This leads to:

higher end-to-end latency
fewer reorgs
simpler correction logic

It is safer,

but fundamentally different from validator-level streaming.

Streaming doesn’t remove the cost — it shifts it

WebSocket and Geyser reduce:

redundant RPC calls
polling overhead

But they do not change the core reality:

transaction + instruction data is large
decoding cost is unavoidable
memory pressure is real

On Solana, data size is part of the protocol design, not an implementation detail.

How txdecoder.xyz handles Solana block streaming in practice

At txdecoder.xyz, we treat Solana block streaming as an infrastructure problem, not just an API choice.

Our production setup uses a hybrid streaming architecture:

multiple Geyser gRPC block streaming workers as the primary data source
an additional WebSocket blockSubscribe worker as a fallback path

Why multiple Geyser gRPC workers

Geyser gRPC is:

the fastest option
the most complete in terms of instruction data
stable enough to run at processed commitment

But like any long-lived stream:

connections can drop
validators can restart
transient network issues do happen

To handle this, we:

run multiple independent Geyser streaming workers
de-duplicate blocks downstream
treat each worker as a non-authoritative source

This gives us:

higher availability
predictable latency
graceful degradation instead of hard failure

WebSocket streaming as a safety net

In addition to Geyser, we maintain a WebSocket blockSubscribe worker:

used as a backup when gRPC streams disconnect
typically running at confirmed or finalized
slower, but more resilient across providers

The WebSocket path is not the primary data source —

it exists to ensure:

no long blind spots
smoother recovery
continuity during validator-level disruptions

The key idea: redundancy over perfection

On Solana, no single streaming method is perfect.

Instead of chasing one “ideal” solution, we:

combine multiple imperfect streams
accept short-lived inconsistencies
resolve them deterministically downstream

This approach allows txdecoder.xyz to:

stay low-latency under normal conditions
remain correct under failure
and avoid catastrophic data gaps

On Solana, resilience is a feature you have to build yourself.

Final takeaway

Solana block streaming is not hard because Solana is “bad”.

It is hard because Solana optimizes for:

throughput
parallel execution
low confirmation latency

Those choices push complexity downstream.

If you are building Solana data infrastructure,

you are not just streaming blocks —

you are managing uncertainty, volume, and trade-offs.

There is no perfect approach.

Only conscious ones.

About txdecoder.xyz

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

Website: https://txdecoder.xyz/
X: https://x.com/txdecoder_xyz
Telegram: https://t.me/txdecoder
Telegram channel: https://t.me/txdecoder_announcements
Blog: https://medium.com/@txdecoder

🧵 Why Solana tx_hash & address take more storage than EVM

txdecoder.xyz — Sat, 07 Feb 2026 13:21:45 +0000

After decoding on-chain transactions and saving to database, I realized that Solana tx_hash, address take more storage than EVM

👇

1️⃣ tx_hash size

EVM

Hex encoding
0x + 64 hex chars
~66 ASCII bytes 0-9a-f

Solana

Base58 encoding
~88–90 ASCII chars 1-9A-HJ-NP-Za-km-z

➡️ Solana tx_hash is ~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 worse

3️⃣ Compression matters

Storage engines (Snappy / Zstd) love:

repeated prefixes
low-entropy strings

Hex (0-9a-f) ≫ Base58 for compression

➡️ EVM data shrinks better at block level

4️⃣ Real-world impact

At scale:

billions of txs
multiple address fields per tx

Small per-field differences

➡️ huge disk cost difference

5️⃣ Takeaway

Solana optimizes for:

signatures
runtime
parallel execution

EVM accidentally optimizes for:

storage
analytics
long-term indexing

Different trade-offs. No winners, just design choices.

About txdecoder.xyz

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

Website: https://txdecoder.xyz/
X: https://x.com/txdecoder_xyz
Telegram: https://t.me/txdecoder
Telegram channel: https://t.me/txdecoder_announcements
Blog: https://medium.com/@txdecoder

Uniswap V3: When collect() Is More Than “Collect Fees”

txdecoder.xyz — Thu, 05 Feb 2026 23:11:55 +0000

Uniswap V3 introduced concentrated liquidity, NFTs for positions, and a much more expressive — but also more subtle — event model.

One consequence of this design is that on-chain events can be perfectly correct, yet still semantically confusing for end-users.

A common example is the Collect action.

The Common Assumption

For many users (and even some dashboards):

collect() = collect earned fees

What Actually Happens in Uniswap V3 when user fully exits a position

A Uniswap V3 position is an NFT that tracks:

liquidity
fee growth inside the tick range
last fee checkpoints

When a user wants to exit a position, the flow usually looks like:

event: burn - emit with leftover liquidity amount
event: collect fee - emit with leftover liquidity amount + fees earned ( the magic thing is here )

From the protocol’s point of view, this is perfectly valid:

everything owed to the position is paid out

all values are emitted correctly in event logs

But semantically, fees and principal are very different concepts.

Why Explorers Look “Misleading” (But Aren’t Wrong)

Most explorers (Etherscan included) do the right thing at the log level:

Decode Collect events faithfully
Display the amounts emitted by the contract
Label the action according to the function/event name

The problem is not decoding accuracy.

The problem is that:

Log-level correctness ≠ user-level semantic clarity

For an end-user, seeing:

Collect: 21.12 USDT

raises a very different interpretation than:

Fees earned: 21.12 USDT
Liquidity returned: 201,762.98 USDT

Sample transaction:
https://etherscan.io/tx/0x77613b2370de015fdf904effea3da3671ead1284279be7b5e0138d3409c51069

Why This Is Harder Than It Looks

You cannot reliably separate fees vs liquidity by:

decode a single event

To do this correctly, you need to:

decode all event logs in the transaction
detect remove liquidity event, collect fee event
extract "Liquidity return" of collect fee earned amount

A Broader Takeaway for On-Chain Data

Events remain low-level and composable

Meaning emerges only when state is reconstructed

UX gaps grow between “what happened” and “what users think happened”

For data builders, this is a reminder:

Accurate decoding is the baseline.
Semantic decoding is where real understanding begins.

About txdecoder.xyz

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

Website: https://txdecoder.xyz/
X: https://x.com/txdecoder_xyz
Telegram: https://t.me/txdecoder
Telegram channel: https://t.me/txdecoder_announcements
Blog: https://medium.com/@txdecoder

Slots and Blocks on Solana — Why You Can’t Think Like EVM

txdecoder.xyz — Mon, 02 Feb 2026 11:18:18 +0000

If you’re coming from EVM chains (Ethereum, Base, BSC, etc.), it’s very tempting to map Solana concepts 1:1 to what you already know.

That’s where a lot of misunderstandings start.

On Solana, slots and blocks are not the same thing — and treating them like Ethereum blocks will give you wrong assumptions about time, ordering, and data completeness.

Let’s break it down.

1. What Is a Slot on Solana?

A slot is a logical unit of time in Solana: ~ 400 ms per slot
Each slot has a designated leader
The leader may produce a block during that slot
Key point:
- A slot does NOT guarantee a block.
- Some slots are: Empty, Skipped, Or produce partial data that never becomes finalized

So:

Slot ≠ Block

2. What Is a Block on Solana?

A block only exists if the leader successfully produces one for that slot.

A Solana block:

Is associated with exactly one slot
Contains:
- Transactions
- PoH entries (hashes)
Has:
- blockTime
- blockHeight

But:

 - ❌ Not every slot has a block
 - ❌ Slot numbers are continuous, block heights are not

Sample slot without block
https://solscan.io/block/397551930

This already breaks a common EVM assumption.

3. Compare This to EVM Blocks

On Ethereum-style chains:

 - Time is organized by blocks
 - Each block:
         - Advances state
         - Has a parent
         - Has a timestamp
 - No concept of “empty time units”
 - Simplified EVM model:

         - time → block → state

Solana model is closer to:

 - time → slot → (maybe) block → state

4. Finality and Reorgs Feel Different

Another big mental shift:

EVM - Blocks may reorg - Finality is probabilistic (or epoch-based)

Solana
- Slots are always advancing
- Blocks can be:
- Produced
- Dropped
- Replaced before finalization

 - This means:
         - You may see a block at a slot
         - Then later that block is no longer part of the finalized chain
         - If you index Solana data, you must care about commitment levels: processed, confirmed, finalized

5. Practical Implications for Data Builders

If you’re building analytics, indexers, or decoders:

❌ Common mistakes

Assuming every slot has a block
Using slot count as a proxy for time
Treating block height like Ethereum block number
Assuming monotonic, gapless blocks

✅ Correct mental model

Slots are the clock
Blocks are optional outputs
Finalized data matters more than “first seen” data
Slot-based APIs ≠ block-based APIs

6. TL;DR

Slot = time window
Block = optional result of a slot
Not every slot has a block
Solana ≠ fast Ethereum
Don’t port EVM assumptions into Solana

If you’re decoding or indexing Solana transactions, this distinction is not academic — it directly affects correctness.

Curious how others model slot-based data in their pipelines.
How do you handle skipped slots and block finality in practice? 👇

About txdecoder.xyz

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

Website: https://txdecoder.xyz/
X: https://x.com/txdecoder_xyz
Telegram: https://t.me/txdecoder
Telegram channel: https://t.me/txdecoder_announcements
Blog: https://medium.com/@txdecoder

Decoding a block: how fast is fast enough? How many RPC call needed ?

txdecoder.xyz — Tue, 27 Jan 2026 04:25:46 +0000

For EVM & Solana data builders:

If decoding a block takes > 3s
If you need > 3 RPC calls per block

You’re probably over-indexing or doing redundant reads.

Here’s a real decode log:
<2s end-to-end
2 RPC calls total

Would love to hear your thoughts.

Why Decoding Uniswap V4 is Harder Than V2 & V3

txdecoder.xyz — Tue, 27 Jan 2026 03:18:46 +0000

A transaction-level, data-engineering perspective

When people say “Uniswap V4 is just another AMM version”, that’s only true at the UX level.
From a transaction decoding and on-chain data perspective, V4 is a very different beast.

If you’ve ever built:

a tx decoder
an indexer
a trade analytics pipeline -or a MEV / monitoring system

you’ll immediately feel the difference.

This post explains why decoding Uniswap V4 is fundamentally harder than V2 and V3, and what changes at the data layer.

1. V2 & V3: decoding by pattern recognition

V2/V3 decoding is almost trivial:

One pool = one contract -> Liquidity is balance of pool contract
Swap logic is fixed
Key events:
- Swap
- Mint
- Burn
A decoder can:
- Identify pool address
- Parse Swap event
- Infer: token0 / token1 from pool contract

➡️ Event-driven, deterministic, stateless

2. Uniswap V4: everything breaks 😅

Uniswap V4 introduces a paradigm shift, not an iteration.

The biggest change

Pools are no longer contracts.

All pools live inside one singleton contract (PoolManager), and everything is keyed by a PoolId

That single design choice cascades into multiple decoding problems.

3. PoolId ≠ Pool Address

In Uniswap V4:

poolId is a bytes32
Derived from:
- token0
- token1
- fee
- tickSpacing
- hooks
Problems for decoders:
- No on-chain pool address to index
- No ERC-20 balance per pool
- No direct contract logs per pool

➡️ You must detect event pool initialize, save pool information to your local database before you start decoding any transactions of the pool.

4. Hooks: decoding without knowing the rules

Hooks are the real game changer.
A pool can attach arbitrary logic at:

beforeSwap
afterSwap
beforeModifyPosition
afterModifyPosition ...

From a decoder’s point of view:

Swap behavior is no longer deterministic
Token flows may:
- be modified
- be redirected
- be conditionally executed
Even worse:
- Hooks are external contracts
- They may emit their own events
- Or emit nothing at all

➡️ You cannot decode V4 swaps correctly by reading PoolManager logs alone.

5. One tx ≠ one action

- In V2/V3:

   - One swap tx ≈ one swap action
   - transparently token transfers

- In V4:

   - A single tx can include:
   - multiple pool interactions
   - nested swaps
   - hook-triggered internal swaps
   - non-swap token movements
   - aggregated token movements

➡️ Decoding becomes stateful, not event-local.

6. Event semantics are weaker

Another subtle but painful difference:

V2/V3 events are semantic
→ “this is a swap, this is mint, this is burn”

V4 logs are often mechanical
→ balance deltas, internal calls, state updates

To reconstruct a “swap”, you may need:

call trace
storage reads
hook-specific logic
token balance diffs

➡️ You’re rebuilding meaning, not parsing events.

7. Why generic decoders fail on V4

Most existing decoders assume:

pool = contract
swap = event
tokens = known upfront

These assumptions fail in V4.

A V4-capable decoder must:

Resolve PoolId → PoolKey
Track pool state off-chain
Understand hook execution paths
Aggregate multi-step flows into one semantic action

➡️ This is closer to program analysis than log parsing.

8. Practical implications for infra teams

If you’re building:

analytics dashboards
tax tools
MEV monitors
compliance / forensics
copy-trading systems

Then V4 forces you to rethink:

indexing strategy
storage model
decoding abstractions

“Just listen to events” is no longer enough.

Closing thoughts

Uniswap V4 isn’t harder because it’s poorly designed.
It’s harder because it’s more expressive.
That expressiveness moves complexity:

from smart contracts

to off-chain decoding and interpretation

For data engineers and infra builders, V4 is not an upgrade — it’s a new problem class.

About txdecoder.xyz

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

Website: https://txdecoder.xyz/
X: https://x.com/txdecoder_xyz
Telegram: https://t.me/txdecoder
Telegram channel: https://t.me/txdecoder_announcements
Blog: https://medium.com/@txdecoder

Transaction Decoding on Ethereum (EVM blockchains ) vs Solana: A Technical Perspective

txdecoder.xyz — Mon, 26 Jan 2026 09:35:43 +0000

From an infrastructure perspective, “transaction decoding” is not about parsing bytes.
It is about reconstructing intent from execution artifacts.

On Ethereum, that intent is primarily encoded through ABIs and event logs.
On Solana, it emerges from instruction flows and account state mutations.

Treating these two systems as variations of the same decoding problem leads to lossy abstractions and incorrect analytics.

Before diving into implementation details, it is worth comparing the core primitives that each chain exposes to indexers and data pipelines.

Core differences in transaction decoding

Aspect: Primary semantic signal

Ethereum (EVM)

Event logs emitted during contract executions

Solana

Instructions executed by programs

Aspect: How user intent is expressed

Ethereum (EVM)

Function calls combined with structured event emissions

Solana

Ordered instruction sequence with explicit account inputs

Aspect: Role of logs / events

Ethereum (EVM)

Logs are first-class semantic artifacts designed for off-chain consumption

Solana

logMessages rarely includes helpful information for semantic artifacts

Aspect: Main decoding dependency

Ethereum (EVM)

Contract ABI (function and event definitions)

Without the ABI, decoding a transaction into meaningful semantic actions becomes extremely difficult, if not impossible.

Solana

Program interface (IDL when available) and instruction layout
Without the IDL/ instruction layout, decoding a transaction into meaningful semantic actions still possible in some situation but it’s not make sure we decode enough instructions

Aspect: Visibility of internal execution

Ethereum (EVM)

Internal calls are mostly opaque unless surfaced via logs

Solana

Inner instructions are explicitly exposed and indexed

Aspect: Native token movement

Ethereum (EVM)

Only direct native transfer are visible in transaction receipt.
Internal transaction need to trace_debug with archive node, it’s more complicated and expensive

Solana

SOL transfer, SOL balance change are exposed and indexed

Aspect: Semantic signal for action identification

Ethereum (EVM)

In many cases, the semantic meaning of a user action can be inferred from a single, well-defined event log emitted during execution.

Solana

Semantic decoding typically requires correlating the primary program instruction with one or more associated token transfer instructions to reconstruct the full intent.

Aspect: Related token identification

Ethereum (EVM)

Token addresses are directly exposed in event logs, allowing decoding logic to identify involved tokens without extra inference.

Solana

Transactions expose token accounts rather than the underlying token addresses.
Decoding requires mapping token accounts to their corresponding token mint to determine the actual tokens involved.

Aspect: Token metadata availability

Ethereum (EVM)

Token metadata such as name, symbol, and decimals is available on-chain via standard ERC-20/ERC-721 interfaces.

Solana

Only decimals are reliably stored on-chain.
Other metadata like name and symbol is typically stored off-chain (e.g., via metadata accounts in the Token Metadata program).

Aspect: Realtime subscription & backfill

Ethereum (EVM)

Websocket subscriptions (eth_subscribe) can filter logs by contract address and topic, allowing indexers to receive realtime updates.
Because logs are indexed and immutable, it is also straightforward to backfill historical data to decode a protocol quickly.

Solana

Websocket subscriptions (programSubscribe) can track realtime transactions affecting a program or account, but there is no topic-like filter.
Filtering must be done client-side by decoding instructions, and there is no native historical backfill, making full protocol reconstruction slower and more resource-intensive.

Aspect: Protocol-level event authenticity / instruction trust

Ethereum (EVM)

Early protocols like Uniswap V2/V3 emitted event logs directly from permissionless pools.
Combined with protocol clones, this made it difficult to distinguish legitimate protocol events from fake or malicious logs.
Modern protocols such as Balancer and Uniswap V4 mitigated this by emitting event logs through a single pool manager, centralizing the semantic signal and improving reliability for indexers.

Solana

All user actions interact directly with the protocol’s main program ID, similar to Balancer or Uniswap V4.
This design makes it practically impossible to fake user actions by crafting instructions, because malicious transactions cannot target the main program ID without breaking protocol integrity.

Aspect: Dependency on off-chain storage / database

Ethereum (EVM)

Most transactions can be fully decoded using only on-chain data, without relying on any off-chain storage or local database.
Exception: Protocols like Uniswap V4, Ekubo, and similar, require tracking pool token lists from the pool creation event.
Without storing this information locally, it is nearly impossible to query on-chain later to reconstruct the pool tokens and decode subsequent events.

Solana

All transactions can be decoded entirely using on-chain accounts and instruction data, without relying on any off-chain storage.
Since all user actions interact directly with the main program ID, full semantic intent is available on-chain, making decoding reliable without any database.

I hope this comparison of Ethereum and Solana transaction decoding from a technical perspective was helpful.

We’re continuously working on improving our understanding and decoding infrastructure, and your feedback is invaluable.
If you have thoughts, suggestions, or corrections, please leave a comment below — we’ll carefully review all input and update this article accordingly.

Thank you for reading!

Original URL: https://medium.com/@txdecoder/transaction-decoding-on-ethereum-evm-blockchains-vs-solana-a-technical-perspective-e531451ca6c7

About txdecoder.xyz

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

Website: https://txdecoder.xyz/
X: https://x.com/txdecoder_xyz
Telegram: https://t.me/txdecoder
Telegram channel: https://t.me/txdecoder_announcements
Blog: https://medium.com/@txdecoder

DEV Community: txdecoder.xyz

Streaming Blocks on Solana: Data Volume, Latency, and Unavoidable Trade-offs

Solana does not really stream “blocks”

The three main block streaming approaches on Solana

1. RPC polling: latest slot → fetch block

2. WebSocket streaming: blockSubscribe

3. Validator-level streaming: Geyser gRPC

The hidden cost: Solana block data is large

RPC latency becomes the bottleneck

Why polling amplifies latency problems

Commitment levels are not just a setting

Geyser gRPC: fast and stable at processed

WebSocket blockSubscribe: safer, but slower

Streaming doesn’t remove the cost — it shifts it

How txdecoder.xyz handles Solana block streaming in practice

Why multiple Geyser gRPC workers

WebSocket streaming as a safety net

The key idea: redundancy over perfection

Final takeaway

About txdecoder.xyz

🧵 Why Solana tx_hash & address take more storage than EVM

1️⃣ tx_hash size

2️⃣ Address size

3️⃣ Compression matters

4️⃣ Real-world impact

5️⃣ Takeaway

About txdecoder.xyz

Uniswap V3: When collect() Is More Than “Collect Fees”

The Common Assumption

What Actually Happens in Uniswap V3 when user fully exits a position

Why Explorers Look “Misleading” (But Aren’t Wrong)

Why This Is Harder Than It Looks

A Broader Takeaway for On-Chain Data

About txdecoder.xyz

Slots and Blocks on Solana — Why You Can’t Think Like EVM

1. What Is a Slot on Solana?

2. What Is a Block on Solana?

3. Compare This to EVM Blocks

4. Finality and Reorgs Feel Different

5. Practical Implications for Data Builders

6. TL;DR

About txdecoder.xyz

Decoding a block: how fast is fast enough? How many RPC call needed ?

Why Decoding Uniswap V4 is Harder Than V2 & V3

1. V2 & V3: decoding by pattern recognition

2. Uniswap V4: everything breaks 😅

3. PoolId ≠ Pool Address

4. Hooks: decoding without knowing the rules

5. One tx ≠ one action

6. Event semantics are weaker

7. Why generic decoders fail on V4

8. Practical implications for infra teams

Closing thoughts

About txdecoder.xyz

Transaction Decoding on Ethereum (EVM blockchains ) vs Solana: A Technical Perspective

2. WebSocket streaming: `blockSubscribe`

Geyser gRPC: fast and stable at `processed`

WebSocket `blockSubscribe`: safer, but slower