Skip to main content
Sub-second finality is a mode where transactions are processed and finalized in under 1 second. It combines faster block production and low-latency APIs. To deliver this performance to users, ecosystem products must adapt their indexers and UX layers to surface transaction updates in real time.

​
Current status

The testnet has been running stably since the 2026-01-23 update with sub-second mode active.
NetworkBlock intervalBlocks per second (BPS)Pending lagFinalization lag
Current mainnet~2.5 s~0.4 BPS~30–100 ms~10 s
Current testnet~450 ms~2.2 BPS~30–100 ms~4 s
Target mainnet200–400 ms~2.5–5 BPS~30–100 ms~1 s
Testnet operates close to the target speed (200–400ms block finality) and is the primary environment for testing.

​
Wallets and apps

A faster chain alone does not improve user experience if the application continues to use HTTP polling. In this case, users still observe delays of 10+ seconds. To support sub-second UX, transaction updates must be delivered in real time.

​
Transaction flow in sub-second mode

Applications that rely on polling typically behave as follows:
  1. 0s – user initiates a transaction;
  2. ~0.4s – transaction included in a shard block;
  3. ~0.8s – shard block committed to masterchain;
  4. ~10s – UI updates on the next polling request.
With real-time updates, transaction status should appear as it progresses:
  1. 0s – user initiates a transaction;
  2. ~0.1s – pending status is displayed;
  3. ~0.4s – transaction included in a shard block and confirmed status is displayed;
  4. ~0.8s – shard block committed to masterchain and finalized status is displayed.
Applications must update the UI as soon as new status information becomes available.

​
Use Streaming API v2

Switch to TON Center Streaming API v2 or TonAPI Streaming API to receive transaction status updates with 30–100 ms latency. MyTonWallet and tonscan.org have already switched to Streaming API v2 on both mainnet and testnet. This improves how quickly transaction updates appear in the UI by delivering events in real time, even though sub-second mode is not yet enabled on mainnet. If Streaming API cannot be used, reduce polling intervals and adjust assumptions about transaction timing. Interfaces should be designed to expect results in under 1 second.

​
Handle transaction status flow

Handle all transaction statuses:
  • "pending" – show a processing state immediately
  • "confirmed" – optionally show optimistic success
  • "finalized" – confirm success and update state
  • "trace_invalidated" – discard cached data and re-check transaction status

​
Subscribe to transaction events

Subscribe to the sender or recipient address before or immediately after sending a transaction. 
{
  "accounts": ["<ADDRESS>"],
  "min_finality": "pending"
}

​
Configure min_finality

The min_finality parameter controls which transaction status events are delivered. The default value is "finalized". If not set, only "finalized" events are received.
  • Use "pending" for send flows to receive all status updates.
  • Use "finalized" for balances and transaction history to work only with settled data.
For projects building on TON:
  • Data layer: TON Center Streaming API v2 with 30–100 ms latency.
  • SDK: AppKit for balances, tokens, NFTs, and contract interactions. For frontend applications, AppKit reduces integration complexity and removes the need for custom logic. It handles out of the box:
    • TON balance for any address;
    • Jetton balances and metadata;
    • NFT holdings;
    • Contract state reads;
    • Transaction sending, including jetton transfers.
  • Finality: wait "finalized" status for critical flows.
For API reference, see the API overview.

​
Test on testnet

To ensure correct UX and wallet behavior, perform the following tests.
  • For UX and app teams:
  1. Connect to testnet endpoints.
  2. Initiate a TON transfer.
  3. Observe all four statuses in sequence: "pending" → "confirmed" → "finalized".
  4. Measure time from transaction send to "finalized". It should be under 1 second on testnet.
  5. Test "trace_invalidated" path: intentionally send a malformed transaction and confirm that UI handles it correctly.
  • For wallet teams:
  1. Verify balance updates reflect within 1 second of "finalized" status.
  2. Verify transaction history updates in real time.

​
Indexers

Indexers must process up to 10x more blocks per second without accumulating lag. If the indexer is tuned for 2.5s block intervals, it will fall behind under 200–400ms intervals.

​
Test on testnet

  1. Connect the indexer to testnet.
  2. Run for at least 30 minutes under normal conditions.
  3. Measure lag continuously as the time between block production and indexer processing. Target:
    • lag < 500ms
    • no growing backlog
    If lag increases, identify the source of delay:
    • database writes
    • network
    • parsing
    Resolve bottlenecks before mainnet activation.
  4. After that generate the typical mainnet load profile on testnet.

​
Node, liteserver, or self-hosted TON Center

​
Connect to a liteserver

Public liteservers are available for both mainnet and testnet. Use global config files to discover and connect to them:

​
Update components

All self-hosted components must be updated to versions that support Catchain 2.0.
  • TON node and liteserver – update to the latest release before mainnet activation.
  • Self-hosted TON Center – update to a version with Streaming API v2 support.

​
Self-hosted liteserver updates

  • If a liteserver node is self-hosted, ensure it is updated before mainnet rollout.
  • Confirm that the node version supports the new consensus.

​
Test on testnet

After updating, connect each component to testnet and verify that it operates correctly under increased block rate. Do not wait for mainnet activation; issues identified on mainnet are harder to resolve.

​
TON Center Streaming API v2

TON Center Streaming API v2 provides:
  • Real-time push of transaction status changes.
  • Four statuses: "pending", "confirmed", "finalized", "trace_invalidated".
  • Latency: 30–100 ms from chain event to the client.

​
API token

  • For testing purposes, any valid token for TON Center allows for 2 concurrent streaming connections.
  • For production usage only enterprise plan allows for higher connection limits.

​
Endpoints

SSE and WebSocket are available. Choose based on the stack:
  • SSE – browser-friendly, server-to-client only (unidirectional).
  • WebSocket – bidirectional, allows dynamic subscribe and unsubscribe after connection.
ProtocolTestnet URLMainnet URL
SSEhttps://testnet.toncenter.com/api/streaming/v2/ssehttps://toncenter.com/api/streaming/v2/sse
WebSocketwss://testnet.toncenter.com/api/streaming/v2/wswss://toncenter.com/api/streaming/v2/ws

​
SSE known limitations

  1. Rate limit on reconnect (429 error). If a client reconnects immediately after a disconnect, the previous connection may still be open for ~1 minute. The reconnect attempt receives a 429 error. Use exponential backoff or an enterprise API key.
  2. POST-only subscription. Despite SSE typically using GET, this endpoint requires a POST with the subscription JSON in the request body. GET is not supported yet.
  3. No invalidation signal for account_state_change / jettons_change. If a confirmed account state or jetton balance update is later rolled back, no "trace_invalidated" notification is sent for these event types. Teams using account_state_change or jettons_change at "confirmed" finality should be aware of this gap and consider waiting for "finalized" for balance-critical flows.

​
WebSocket keepalive

  • Send a ping every 15 seconds to keep the connection alive.
  • SSE connections receive automatic server-side keepalive (: keepalive) every 15 seconds; no client action required.

​
See also