> ## Documentation Index
> Fetch the complete documentation index at: https://companyname-a7d5b98e-closes-94-guidebook-more.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Coming from Ethereum

export const Aside = ({type = "note", title = "", icon = "", iconType = "regular", children}) => {
  const asideVariants = ["note", "tip", "caution", "danger"];
  const asideComponents = {
    note: {
      outerStyle: "border-sky-500/20 bg-sky-50/50 dark:border-sky-500/30 dark:bg-sky-500/10",
      innerStyle: "text-sky-900 dark:text-sky-200",
      calloutType: "note",
      icon: <svg width="14" height="14" viewBox="0 0 14 14" fill="currentColor" xmlns="http://www.w3.org/2000/svg" className="w-4 h-4 text-sky-500" aria-label="Note">
          <path fill-rule="evenodd" clip-rule="evenodd" d="M7 1.3C10.14 1.3 12.7 3.86 12.7 7C12.7 10.14 10.14 12.7 7 12.7C5.48908 12.6974 4.0408 12.096 2.97241 11.0276C1.90403 9.9592 1.30264 8.51092 1.3 7C1.3 3.86 3.86 1.3 7 1.3ZM7 0C3.14 0 0 3.14 0 7C0 10.86 3.14 14 7 14C10.86 14 14 10.86 14 7C14 3.14 10.86 0 7 0ZM8 3H6V8H8V3ZM8 9H6V11H8V9Z"></path>
        </svg>
    },
    tip: {
      outerStyle: "border-emerald-500/20 bg-emerald-50/50 dark:border-emerald-500/30 dark:bg-emerald-500/10",
      innerStyle: "text-emerald-900 dark:text-emerald-200",
      calloutType: "tip",
      icon: <svg width="11" height="14" viewBox="0 0 11 14" fill="currentColor" xmlns="http://www.w3.org/2000/svg" className="text-emerald-600 dark:text-emerald-400/80 w-3.5 h-auto" aria-label="Tip">
          <path d="M3.12794 12.4232C3.12794 12.5954 3.1776 12.7634 3.27244 12.907L3.74114 13.6095C3.88471 13.8248 4.21067 14 4.46964 14H6.15606C6.41415 14 6.74017 13.825 6.88373 13.6095L7.3508 12.9073C7.43114 12.7859 7.49705 12.569 7.49705 12.4232L7.50055 11.3513H3.12521L3.12794 12.4232ZM5.31288 0C2.52414 0.00875889 0.5 2.26889 0.5 4.78826C0.5 6.00188 0.949566 7.10829 1.69119 7.95492C2.14321 8.47011 2.84901 9.54727 3.11919 10.4557C3.12005 10.4625 3.12175 10.4698 3.12261 10.4771H7.50342C7.50427 10.4698 7.50598 10.463 7.50684 10.4557C7.77688 9.54727 8.48281 8.47011 8.93484 7.95492C9.67728 7.13181 10.1258 6.02703 10.1258 4.78826C10.1258 2.15486 7.9709 0.000106649 5.31288 0ZM7.94902 7.11267C7.52078 7.60079 6.99082 8.37878 6.6077 9.18794H4.02051C3.63739 8.37878 3.10743 7.60079 2.67947 7.11294C2.11997 6.47551 1.8126 5.63599 1.8126 4.78826C1.8126 3.09829 3.12794 1.31944 5.28827 1.3126C7.2435 1.3126 8.81315 2.88226 8.81315 4.78826C8.81315 5.63599 8.50688 6.47551 7.94902 7.11267ZM4.87534 2.18767C3.66939 2.18767 2.68767 3.16939 2.68767 4.37534C2.68767 4.61719 2.88336 4.81288 3.12521 4.81288C3.36705 4.81288 3.56274 4.61599 3.56274 4.37534C3.56274 3.6515 4.1515 3.06274 4.87534 3.06274C5.11719 3.06274 5.31288 2.86727 5.31288 2.62548C5.31288 2.38369 5.11599 2.18767 4.87534 2.18767Z"></path>
        </svg>
    },
    caution: {
      outerStyle: "border-amber-500/20 bg-amber-50/50 dark:border-amber-500/30 dark:bg-amber-500/10",
      innerStyle: "text-amber-900 dark:text-amber-200",
      calloutType: "warning",
      icon: <svg className="flex-none w-5 h-5 text-amber-400 dark:text-amber-300/80" fill="none" viewBox="0 0 24 24" stroke="currentColor" stroke-width="2" aria-label="Warning">
          <path stroke-linecap="round" stroke-linejoin="round" d="M12 9v2m0 4h.01m-6.938 4h13.856c1.54 0 2.502-1.667 1.732-3L13.732 4c-.77-1.333-2.694-1.333-3.464 0L3.34 16c-.77 1.333.192 3 1.732 3z"></path>
        </svg>
    },
    danger: {
      outerStyle: "border-red-500/20 bg-red-50/50 dark:border-red-500/30 dark:bg-red-500/10",
      innerStyle: "text-red-900 dark:text-red-200",
      calloutType: "danger",
      icon: <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512" fill="currentColor" className="text-red-600 dark:text-red-400/80 w-4 h-4" aria-label="Danger">
          <path d="M17.1 292c-12.9-22.3-12.9-49.7 0-72L105.4 67.1c12.9-22.3 36.6-36 62.4-36l176.6 0c25.7 0 49.5 13.7 62.4 36L494.9 220c12.9 22.3 12.9 49.7 0 72L406.6 444.9c-12.9 22.3-36.6 36-62.4 36l-176.6 0c-25.7 0-49.5-13.7-62.4-36L17.1 292zm41.6-48c-4.3 7.4-4.3 16.6 0 24l88.3 152.9c4.3 7.4 12.2 12 20.8 12l176.6 0c8.6 0 16.5-4.6 20.8-12L453.4 268c4.3-7.4 4.3-16.6 0-24L365.1 91.1c-4.3-7.4-12.2-12-20.8-12l-176.6 0c-8.6 0-16.5 4.6-20.8 12L58.6 244zM256 128c13.3 0 24 10.7 24 24l0 112c0 13.3-10.7 24-24 24s-24-10.7-24-24l0-112c0-13.3 10.7-24 24-24zM224 352a32 32 0 1 1 64 0 32 32 0 1 1 -64 0z"></path>
        </svg>
    }
  };
  let variant = type;
  let gotInvalidVariant = false;
  if (!asideVariants.includes(type)) {
    gotInvalidVariant = true;
    variant = "danger";
  }
  const iconVariants = ["regular", "solid", "light", "thin", "sharp-solid", "duotone", "brands"];
  if (!iconVariants.includes(iconType)) {
    iconType = "regular";
  }
  return <>
      <div className={`callout my-4 px-5 py-4 overflow-hidden rounded-2xl flex gap-3 border ${asideComponents[variant].outerStyle}`} data-callout-type={asideComponents[variant].calloutType}>
        <div className="mt-0.5 w-4" data-component-part="callout-icon">
          {}
          {icon === "" ? asideComponents[variant].icon : <Icon icon={icon} iconType={iconType} size={14} />}
        </div>
        <div className={`text-sm prose min-w-0 w-full ${asideComponents[variant].innerStyle}`} data-component-part="callout-content">
          {gotInvalidVariant ? <p>
              <span className="font-bold">
                Invalid <code>type</code> passed!
              </span>
              <br />
              <span className="font-bold">Received: </span>
              {type}
              <br />
              <span className="font-bold">Expected one of: </span>
              {asideVariants.join(", ")}
            </p> : <>
              {title && <p className="font-bold">{title}</p>}
              {children}
            </>}
        </div>
      </div>
    </>;
};

Learn how to develop and build on TON coming from the Ethereum (EVM) ecosystem.

## Execution model

### Asynchronous blockchain

One of the biggest stepping stones to learn TON development is the asynchronous execution model. Messages sent by one contract take time to arrive at another, meaning that the resulting transactions for processing incoming messages will occur after the current transaction terminates.

So, compared to Ethereum, where you can have multiple processed messages and state changes on different contracts in the same atomic transaction, a TON transaction represents a state change only for one account and single message processing. That means that a signed, included-in-block unit is called a "transaction" in both chains; however, having the differences in execution models, it has a different impact.

Here is a table for comparison:

| Action description                                                                             | Ethereum                               | TON                              |
| :--------------------------------------------------------------------------------------------- | -------------------------------------- | -------------------------------- |
| Single message processing with state change on one contract                                    | Message call or "internal transaction" | Transaction                      |
| Number of state changes and messages on different accounts produced from initial contract call | Transaction                            | Chain of transactions or "trace" |

Let's explore a practical example, liquidity withdrawal on DEX.

On Ethereum, it will appear as a single atomic transaction with multiple contract calls inside it. You can see that this transaction has a single hash and is included in one block:

<img src="https://mintcdn.com/companyname-a7d5b98e-closes-94-guidebook-more/ByXCzEXZpULQraLK/resources/images/from-ethereum/burn-tx-eth.png?fit=max&auto=format&n=ByXCzEXZpULQraLK&q=85&s=8f1e1dd073b5d9a82f5552bb0359512d" alt="eth-burn" width="2754" height="1460" data-path="resources/images/from-ethereum/burn-tx-eth.png" />

The same operation on TON will differ, consisting of a sequence of more than 10 transactions. Each arrow on this image represents a distinct finalized transaction, with its own hash, inclusion block, and all the other properties:

<img src="https://mintcdn.com/companyname-a7d5b98e-closes-94-guidebook-more/ByXCzEXZpULQraLK/resources/images/from-ethereum/burn-tx-ton.png?fit=max&auto=format&n=ByXCzEXZpULQraLK&q=85&s=2a6fca355d09427e3d57340255dac281" alt="tvm-burn" width="2420" height="1514" data-path="resources/images/from-ethereum/burn-tx-ton.png" />

If you want to execute a *huge* transaction on Ethereum (or any other EVM-based blockchain), you will have certain limitations: [EVM call-depth](https://ethereum.org/developers/docs/evm/#evm-instructions) of 1024 nested calls and [block gas limit](https://ethereum.org/developers/docs/blocks/#block-size). With TON's asynchronous execution model, you can have a trace (chain of transactions) of whatever length you want, as long as you have fees to continue it. For example, [trace that resulted from this message](https://tonviewer.com/transaction/e887503f7dac857be80487e3ed0774db962379d1c153e6df7b9b5313c657ab94) consisted of more than 1.5+ million transactions, lasting more than 4000 blocks until its end!

### On-chain get methods

Another radical difference between the two chains is that TON has get methods, which allow data to be retrieved from the contracts without paying any fees. In TON, you *can't* synchronously retrieve data from another contract - you can't call a get method from another contract during the transaction.

If you wonder how we can make any DeFi protocol or complicated on-chain system work with these limitations, read an article about the on-chain [Request-Response pattern](/contract-dev/carry-value).

### Account model

There are two types of accounts in Ethereum: externally owned accounts (EOA in short) and contract accounts. EOAs are human-controlled entities, each represented by a private-public key pair. They are used to sign transactions and each has its own balance; they are commonly called "wallets" by the community.

In TON, there is no such separation; every valid address represents an on-chain account, each with its own state and balance, that could be changed through transactions (read more about accounts [here](/foundations/addresses/overview)). This means that "wallets" in TON are smart contracts that operate under the same rules as any other contract on the blockchain.

The TON wallet smart contract uses regular asymmetric cryptography to control message signing, ensuring that the user experience remains essentially unchanged. You can examine [Wallet Standard](/standard/wallets/comparison) implementation code and how it changed through ecosystem development.

### Limited contract storage

In Ethereum, you can store as much data as you want in a single contract. Unbounded maps and arrays are considered a standard practice, and you will probably see them in most of the contract examples. This is not the case with TON - every smart contract on TON blockchain has a storage size upper limit. That means that you can't implement ERC20-like fungible tokens in the same way as in an EVM chain, by using a single map inside one contract.

[The limit](/foundations/config) is 65536 unique cells per message or contract storage. Each cell is up to 1,023 bits, which sets a hard upper limit.

<Aside type="danger">
  Every map that is expected to grow more than **1000** values is dangerous! Note that in the TVM map, key access is asymptotically logarithmic, meaning that it will continuously cost you more gas to find keys as the map grows.
</Aside>

Instead, you should use [sharding](/foundations/shards).

You can read more about TON architecture design choices that have led to such differences [here](/standard/overview).

## Ecosystem

### Tooling

<Aside>
  This section will primarily focus on Typescript tooling since historically this language has been better adopted and well-established in TON.
</Aside>

Recommended programming language for smart contract development in TON is [Tolk](/languages/tolk). However, there are other established languages in the ecosystem; you can read more about them [here](/languages/tact).

Here is the ecosystem overview table.

| Use case                              | Popular Ethereum tool | TON counterpart                                                                                              |
| :------------------------------------ | --------------------- | ------------------------------------------------------------------------------------------------------------ |
| Blockchain interaction                | Ethers, Web3.js, Viem | [@ton/ton](https://www.npmjs.com/package/@ton/ton), [Asset-sdk](https://github.com/ton-community/assets-sdk) |
| Wallet connection protocol            | Walletconnect, Wagmi  | [TonConnect](https://github.com/ton-connect)                                                                 |
| Dev environment framework / scripting | Hardhat, Truffle      | [Blueprint](https://github.com/ton-org/blueprint)                                                            |
| Simulation engine                     | Revm & Reth           | [Sandbox](https://github.com/ton-org/sandbox)                                                                |

Another essential library to know about is [@ton/core](https://www.npmjs.com/package/@ton/core). This library handles low-level blockchain primitives (de-)serialization; you will probably need it together with any RPC-client or contract interaction library.

### Services

Most web3 developers also have their favorite set of products and services for easier on-chain development. This table showcases some of the use cases that existing TON services can cover.

| Use case                                | Ethereum service | TON service                                                          |
| --------------------------------------- | ---------------- | -------------------------------------------------------------------- |
| User-friendly explorer                  | Etherscan        | [Tonviewer](https://tonviewer.com/), [Tonscan](https://tonscan.org/) |
| Open-source dev explorer                | Blockscout       | [explorer.toncoin.org](https://explorer.toncoin.org/)                |
| Debugger                                | Remix Debugger   | [TxTracer](https://txtracer.ton.org/)                                |
| IDE                                     | Remix IDE        | [Web IDE](https://ide.ton.org/)                                      |
| Asm playground and compilation explorer | Evm.Codes        | [TxTracer](https://txtracer.ton.org/)                                |

If you are looking for commercial RPC and node providers, check our [Providers overview](/ecosystem/rpc/overview) section.

### Standards

This section showcases a match between some of the Ethereum standards and proposals (ERC and EIP) and their counterpart or similar proposals in TON (TEP).

<Aside>
  Due to significant differences in execution models, most of the standards in TON differ significantly in semantics and general approach compared to their Ethereum analogs.
</Aside>

| Description                             | Ethereum standard                       | TON Standard (TEP)                                                 |
| --------------------------------------- | --------------------------------------- | ------------------------------------------------------------------ |
| Fungible token standard                 | ERC-20                                  | [Jettons (TEP-0074)](/standard/tokens/jettons/overview)            |
| Non-fungible token standard             | ERC-721                                 | [NFT standard (TEP-0062)](/standard/tokens/nft/overview)           |
| Token metadata                          | ERC-4955 (Not exactly, but close match) | [Token Data Standard (TEP-0064)](/standard/tokens/metadata)        |
| NFT royalty standard                    | EIP-2981                                | [NFT Royalty Standard (TEP-0066)](/standard/tokens/nft/comparison) |
| DNS-like registry                       | ENS (EIP-137)                           | [DNS Standard (TEP-0081)](/services/dns)                           |
| Soulbound / account-bound token concept | EIP-4973                                | [SBT Standard (TEP-0085)](/standard/tokens/sbt/overview)           |
| Wallet connection protocol              | WalletConnect / EIP-1193                | [TonConnect (TEP-0115)](/ecosystem/ton-connect)                    |