ABI

ABI (Application Binary Interface) is a description of how external code talks to a smart contract: which messages it accepts, which get-methods it exposes, what their arguments and return types are. Wallets, dApps, and indexers use the ABI to build transactions and parse responses.

ABI on EVM vs TON

In Ethereum-compatible chains, ABI is a standardised JSON document emitted by the Solidity compiler. Every major library (ethers.js, web3.js, block explorers) consumes the same format, which makes it effectively a network-wide protocol.

TON works differently:

• There is no network-level ABI standard. TVM does not require contracts to publish an interface; only the compiled bytecode lives on chain.
• The ABI format depends on the contract language. Each toolchain emits its own description, and tooling tends to stay within its own ecosystem.
• Standard messages are codified at the protocol level instead. Common operations (Jetton transfer, NFT transfer, etc.) have fixed opcodes defined in TEPs, and any compatible contract must recognise them.

What different languages produce

• Tact emits a JSON ABI describing received messages (with opcodes and field schemas) plus a list of typed get-methods. Code generators turn this into TypeScript clients and similar bindings.
• Tolk offers a comparable ABI artefact as part of its toolchain.
• FunC is a low-level language and does not generate an ABI on its own. Authors document the interface manually — accepted opcodes, get-method signatures, message body layouts — and this hand-written spec serves as the contract’s ABI by convention.

How a dApp actually calls a contract

From the calling side, the ABI in TON splits into two layers:

1. Get-methods — read-only calls executed by a lite-server without a transaction. The caller supplies arguments and receives a TVM stack of return values. Knowing the method name (or numeric ID) and its stack signature is enough to invoke it.
2. Internal messages — write operations sent as transactions from a wallet to the contract. The message body begins with a 32-bit opcode prefix that the contract uses to dispatch to a handler, followed by typed fields laid out per the ABI.

In practice

When integrating a Tact or Tolk contract, you typically get an ABI file and an auto-generated TypeScript client. With a FunC contract you rely on the author’s hand-written spec and assemble messages directly using a TON SDK (ton-core, tonutils-go, etc.). For any standardised message — Jetton transfer, NFT transfer, NFT discovery — prefer SDK helpers over hand-rolled bodies: those formats are pinned by TEPs and identical across all compatible contracts.