How to adopt sub-second finality

​

Current status

• Together with the consensus update, the Streaming API v2 delivers status updates with 30 to 100ms latency.
• Testnet remains the primary environment for project testing.

​

Example of sub-second user experience in action

​

What projects need to do

​

Wallets and dApps

​

Actions

• Switch to a streaming API such as TON Center Streaming API v2 or TonAPI Streaming API. Handle all four transaction statuses: "pending", "confirmed", "finalized", and "trace_invalidated".
• 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.

​

Self-hosted nodes, liteservers, and TON Center instances

​

Actions

1. Update all self-hosted components to the versions that include Catchain 2.0 support:
   • TON node and liteserver – update to a release that supports the live mainnet consensus.
   • Self-hosted TON Center – update to a version with Streaming API v2 support.
2. After updating, verify each component on testnet and confirm that it operates correctly under the higher block rate. If any component still runs a pre-upgrade version, update it before relying on it in production.

​

Indexers

​

Actions

1. Connect the indexer to testnet.
2. Run for 30 or more minutes.
3. Measure lag continuously.
4. If lag increases, identify and resolve bottlenecks such as database writes, network latency, and parsing throughput.
5. Generate the typical mainnet load profile on testnet and verify that the indexer keeps up. See Expected user experience and Test on testnet for guidance.

​

Expected user experience

​

Behavior without Streaming APIs

• Poll HTTP endpoints at fixed intervals.
• Wait for full block finalization before updating the UI.
• Show delays of 10+ seconds to users.

1. 0s – user clicks “Send”;
2. ~0.4s – transaction included in a shard block;
3. ~0.8s – shard block committed to masterchain;
4. ~10s – UI updates on the next HTTP polling request.

​

Behavior with Streaming APIs

1. 0s – user clicks “Send”;
2. ~0.1s – "pending" status with expected outcome 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.

​

Why this matters

• TON Core delivers faster block production and low-latency APIs.
• Ecosystem projects must adapt indexers and UI layers to surface this speed.

​

How to integrate

​

Recommended stack

• Streaming API: TON Center or TonAPI.
• Data layer: TON Center API v3 or TonAPI v2.
• SDK: AppKit for balances, tokens, NFTs, and contract interactions.
• Finality: wait for "finalized" in critical flows.

​

Public liteserver

• Mainnet: ton.org/global.config.json
• Testnet: ton.org/testnet-global.config.json

​

Self-hosted liteserver

​

Actions

​

TON Center Streaming API v2

• Push-based delivery of transaction status updates.
• Four statuses: "pending", "confirmed", "finalized", "trace_invalidated".
• Latency: 30–100ms 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, higher connection limits require a paid plan.

​

Endpoints

• SSE – browser-friendly, server-to-client only (unidirectional).
• WebSocket – bidirectional, allows dynamic subscribe and unsubscribe after connection.

​

Transaction status flow to implement

1. Initiate the transaction after the user’s request.
2. Subscribe to the sender or recipient address through the Streaming API before or immediately after sending.
   • On pending, display a processing indicator.
   • On confirmed, optionally display optimistic success.
   • On finalized, display confirmed success and update state.
   • On trace_invalidated, discard a cached trace and recheck the status manually.

​

Configure min_finality

{
  "accounts": ["<ADDRESS>"],
  "min_finality": "pending"
}

​

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.

​

TonAPI Streaming API

​

AppKit for app developers

• TON balance for any address;
• Jetton balances and metadata;
• NFT holdings;
• Contract state reads;
• Transaction sending, including jetton transfers.

​

Test on testnet

​

Testnet endpoints

​

How to get test tokens

• For the standard faucet, up to 2 TON per hour, use Telegram Testgiver TON bot.
• For larger allocations up to 5,000 TON, use the request form.

​

What to test

​

For indexer teams

1. Connect indexer to testnet.
2. Run for 30+ minutes under normal conditions.
3. Measure indexer lag as the time between block production and indexer processing.
4. Ensure lag remains below 500ms and no backlog accumulates.

​

For UX and app teams

1. Connect to testnet endpoints.
2. Initiate a TON transfer.
3. Observe three 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.

​

Resources

• Announcement, Telegram channel
• TON Core deployment progress, Telegram channel
• TON Core R&D technical overview, Telegram channel
• UX approaches for sub-second finality, Telegraph
• TON Center Streaming API v2
• API overview and public endpoints
• AppKit documentation

​

Get support