TON's Actor-Model Sharding vs EVM: Why TON Scales Differently

A TON smart contract cannot call another smart contract and get a return value in the same transaction. That single fact explains more about why TON scales the way it does than any whitepaper diagram of shard counts. Ethereum's EVM gives you one shared ledger and synchronous calls; TON gives you millions of independent actors mailing each other and hoping the reply shows up a block or two later. Both are "smart contract platforms." The engineering you do on top of them is barely related.

Two different definitions of "smart contract"

On the EVM, every contract lives in the same global state trie. When contract A calls contract B, the EVM pushes a new frame onto the call stack, executes B's code against the shared state, and returns control to A — all inside one transaction, one block, one atomic unit. If anything downstream reverts, the entire transaction unwinds. This is why flash loans, multi-hop arbitrage, and one-shot liquidations work the way they do: you can chain five external calls and know that either all five succeed or none of them touch state.

TON was built on the actor model from day one. Every smart contract — including every user's jetton wallet, which is its own deployed contract, not a balance entry in a token contract — is an isolated actor with its own persistent state and its own queue of incoming messages. Contracts don't call each other. They send asynchronous messages, and the recipient processes that message in its own transaction, on its own schedule, possibly in a different shard, possibly several blocks later. There is no shared call stack and no synchronous return value. What looks like "call the DEX router" in TON is really "mail a request and write a handler for whatever mail comes back."

The sharding mechanism itself

Ethereum shelved execution sharding around 2021 and moved to a rollup-centric roadmap instead. Blob space from EIP-4844 (proto-danksharding) scales data availability for L2s, but each rollup is still a single sequential state machine underneath — Arbitrum, Base, and Optimism all inherit the EVM's synchronous-call, single-global-state design. You scale by running more separate EVMs and bridging between them, which reintroduces async messaging at the bridge layer, just with far worse latency than anything native.

TON took a different bet: the "infinite sharding paradigm." The basechain can theoretically split into up to 2^60 shardchains, and in practice it splits and merges dynamically based on message queue depth. Under normal load TON runs a handful of active shards; during genuine demand spikes — the tap-to-earn mania in 2024 is the textbook case — it has split into dozens of shardchains to absorb the message backlog, then merged back down once load dropped. No governance vote, no manual resharding. The validator set just responds to queue pressure per shard.

The tradeoff for that elasticity is exactly the synchronicity you gave up above. Since accounts can end up on different shards, and shards produce blocks independently, a message from your contract on shard A to a contract on shard B is a cross-shard hop with its own latency, not a free lookup.

What this means for bot logic

Say you're writing arbitrage logic between two DEXes. On EVM this is trivial to reason about:

function arb(uint amountIn) external {
    uint out1 = dexA.swap(tokenIn, tokenMid, amountIn);
    uint out2 = dexB.swap(tokenMid, tokenIn, out1);
    require(out2 > amountIn, "not profitable");
}

If out2 doesn't cover amountIn, the whole call reverts, state is untouched, and you're out gas — nothing else. One transaction, one atomic boundary.

The TON equivalent isn't one function, it's a state machine spread across several transactions:

() recv_internal(int msg_value, cell in_msg, slice body) impure {
    ;; handler for the swap request — runs once, sends a message, exits
    send_raw_message(build_swap_msg(dex_a_addr, amount_in), 64);
    ;; execution ends HERE. dex A's reply is a separate future transaction.
}

() handle_dex_a_reply(slice body) impure {
    int out1 = body~load_coins();
    if (out1 < min_acceptable) {
        send_raw_message(build_refund_msg(sender, out1), 64); ;; manual bounce
        return ();
    }
    send_raw_message(build_swap_msg(dex_b_addr, out1), 64);
}

That's three separate transactions, potentially on three shards, with no shared call stack tying them together. If the second swap comes back underwater, there's no require() to unwind everything — you write explicit refund and bounce-message logic, and you track the whole chain yourself via query_id fields, because the chain has no idea these three transactions are "one operation" unless you tell it so. Bots that assume EVM-style atomicity lose funds here; a stuck or bounced message mid-chain leaves a contract holding an intermediate asset with no automatic path back.

This is also why serious TON trading infrastructure leans hard on off-chain indexing and message-tracking layers rather than polling contract state the way an EVM bot would — it's a similar problem to streaming account updates over gRPC instead of polling websocket RPC, except here you're reconstructing causally-linked message chains across shards, not just watching account diffs. Getting that indexing and settlement layer right is most of what we build when we take on infrastructure and data pipeline work for TON-based bots.

Comparison at a glance

Dimension	EVM (L1 + rollups)	TON
State model	Single global trie, shared by all contracts	Each contract is an isolated actor with private state
Cross-contract calls	Synchronous, same call stack	Asynchronous messages, separate transactions
Atomicity	Whole tx reverts on failure	No cross-message atomicity; manual bounce/refund
Scaling mechanism	Rollups (external, bridged)	Native dynamic shard split/merge
Practical shard count	N/A (each rollup is its own chain)	Handful normally, dozens under load
Multi-hop latency	One block	Multiple blocks, hop-dependent
Composability	High — flash loans, one-tx arb	Low — requires explicit choreography
Tooling maturity	Very high (Foundry, Tenderly, etc.)	Improving fast, still thinner

Where each one actually breaks

EVM composability breaks down at throughput — you're paying for global ordering and synchronous execution on every hop, which is exactly why gas spikes during congestion and why L2s exist. TON's async model sidesteps that ceiling but pushes correctness work onto the developer: you cannot "just require() it," you have to design for partial failure as a first-class case, the same discipline distributed-systems engineers use for message queues, not the discipline Solidity devs are used to.

It's a similar philosophical fork to picking a shared-sequencer chain over something like the vault-based settlement model in how HLP handles Hyperliquid's counterparty risk — one design keeps everything inside one coordinated state machine, the other trades that coordination away for parallelism and asks you to rebuild the guarantees yourself.

Which to pick when

If your product is arbitrage, liquidations, flash-loan strategies, or anything that depends on atomic multi-step execution, build on EVM (or an EVM rollup). The synchronous call stack isn't a limitation there, it's the feature you're relying on, and the tooling — Foundry, Tenderly, mature simulation — is built for exactly that workload. We'd point that build toward the kind of low-latency execution stack we cover when comparing Jito and Firedancer's approach to validator latency, since the same "minimize hops, maximize determinism" thinking applies.

If you're building for TON specifically — a Telegram-native wallet bot, a jetton trading flow, high-volume mint or airdrop logic — don't fight the actor model, design for it from the start: idempotent handlers, explicit bounce paths, query IDs for correlating multi-hop operations, and a monitoring layer that can show you where a message chain actually is instead of assuming instant finality. That last piece matters more than people expect once you're running it live, which is usually where ongoing support and maintenance work earns its keep, alongside the kind of real-time state visibility a proper trading dashboard needs to give ops teams when a swap is sitting mid-chain across two shards.

Building or auditing cross-shard TON contract logic is the kind of thing worth getting reviewed before mainnet — talk to us about an infra and contract audit.