Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.moralis.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

Blockchains are probabilistic systems. A transaction may appear in a block and later be removed due to a chain reorganization (re-org). To handle this safely, Moralis Streams distinguishes between unconfirmed and confirmed events and delivers both to your backend. This page explains what confirmation and finality mean, and how they are exposed through Streams.

​
What Is Confirmation?

When a transaction is included in a newly mined block, it is considered unconfirmed. At this stage:
  • The block may still be replaced
  • Transactions may be reordered or dropped
  • State changes are not final
Streams delivers these events with: 
"confirmed": false
This enables low-latency, real-time reactions. See also:

​
What Is Finality?

A transaction becomes confirmed once enough blocks have been mined on top of it. At this point:
  • The risk of re-org is extremely low
  • State can be safely persisted
  • Balances and ownership can be finalized
Streams delivers a second webhook with: 
"confirmed": true
Confirmation thresholds vary by chain. See Supported Chains.

​
Finality by Chain

Each chain has its own finality model, which determines how long it takes for a confirmed: true webhook to arrive after the initial unconfirmed delivery:
EVM finality is probabilistic and varies per chain. Confirmation thresholds are expressed as a number of blocks that must be mined on top of the block containing the transaction. Ethereum and other EVM chains can experience reorgs up to a chain-specific depth, after which the transaction is treated as final.See Supported Chains for the per-chain confirmation block counts.

​
Why Streams Sends Two Webhooks

Streams intentionally sends both states so you can:
  • React instantly (unconfirmed)
  • Persist safely (confirmed)
This avoids the need to:
  • Poll block explorers
  • Manually track confirmations
  • Reconcile state after re-orgs
For how Streams handles re-orgs internally:

​
Ordering & Edge Cases

In rare cases:
  • A confirmed: true webhook may arrive before confirmed: false
This can occur due to:
  • Network latency
  • Retry behavior
  • Regional delivery differences
Your system should:
  • Treat each webhook independently
  • Use transaction hash + confirmation flag
  • Be idempotent

​
Common Patterns

Real-time UX
  • Act on confirmed: false
  • Update UI optimistically
Accounting / Persistence
  • Only persist on confirmed: true
Analytics
  • Use both, but deduplicate by transaction hash

​
Next Steps