# TON vs. EVM differences

A reference for engineers and reviewers who know the original Tornado Cash contracts and want to follow what's different.

## Curve & hash

|                  | EVM Tornado                    | TONado Cash                        |
| ---------------- | ------------------------------ | ---------------------------------- |
| Pairing curve    | BN254 (alt\_bn128)             | **BLS12-381**                      |
| On-chain pairing | Solidity precompile            | TVM `BLS_*` opcodes                |
| Circuit hash     | MiMC sponge                    | **Poseidon**                       |
| Field size       | 21888242871839275...           | 52435875175126190...               |
| ZERO\_VALUE      | keccak256("tornado") mod BN254 | keccak256("tornado") mod BLS12-381 |
| Verifier source  | Hand-tweaked snarkjs export    | `export-ton-verifier` output       |

## Execution model

|                      | EVM                            | TON                                     |
| -------------------- | ------------------------------ | --------------------------------------- |
| Call style           | Synchronous, atomic            | **Asynchronous message-passing**        |
| State at end of tx   | Reflects entire call tree      | Reflects only this contract's reactions |
| "Events"             | `event` keyword in Solidity    | `ext_out_msg_info` with body            |
| Cross-contract calls | Direct `call` / `delegatecall` | Send a message; receive reply later     |

**Implication for users:** a deposit is *not* confirmed in the same tx the user signed. The user signs a tx to their *wallet*, which sends an internal message to the pool, which processes it in its own tx. The CLI/relayer must poll for the deposit log via the indexer rather than reading a receipt.

## Token model

|                        | EVM                                       | TON                                                      |
| ---------------------- | ----------------------------------------- | -------------------------------------------------------- |
| Standard               | ERC-20                                    | TEP-74 (Jettons)                                         |
| Holder representation  | Balance in token contract                 | **Per-(holder, master) jetton wallet contract**          |
| Transfer flow          | `token.transferFrom(from, to, amt)`       | `holder_jetton_wallet → recipient_jetton_wallet` (async) |
| Approval pattern       | `approve` + `transferFrom`                | No approve; use forward payload semantics                |
| Counterfeit-token risk | Low (clearly distinct contract addresses) | **High: must validate sender wallet**                    |

## Storage rent

EVM contracts pay nothing to retain state. TON contracts pay **storage rent** proportional to data size and held forever. The pool's monotonically-growing nullifier dict needs ongoing TON to cover it. Mitigation: fee accrual on each withdraw funds future storage; we recommend a back-of-envelope test in Phase 1.5 to verify the steady-state economics.

## Event-equivalent indexing

EVM: `eth_getLogs` is universal and cheap. TON: no log index. We rely on Toncenter's transaction API and decode pool out-messages manually (see `packages/core/src/indexer.ts`).

## Gas / fee accounting

EVM: caller pays gas, return value is success/failure of the entire tx. TON: the **attached value** of an internal message both pays gas AND is the amount transferred. Excess value attached to a message is returned to sender if the contract opts in. Our pool refunds excess on deposit.

## Compatibility with mainnet Tornado notes

**None.** TONado Cash notes have a different format, different field, different hash. There's no path to redeem a Tornado mainnet note on TONado Cash. If we ever wanted bridging, it'd be a separate trust-bridged "wrap" pool, out of scope for v1.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.tonadocash.com/protocol-reference/ton-vs-evm.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.