Opcode

Opcode in the TON context is a numeric identifier of an operation, placed at the very beginning of an incoming message body to a smart contract. The contract reads the first 32 bits of the body, compares them against a list of known values, and decides which function to execute: accept a jetton, mint an NFT, update a parameter, and so on.

Why it is needed

In TON, a smart contract has no fixed set of methods at the VM level. The contract receives an incoming message and must parse the body itself to figure out what is being asked of it. To make this uniform, the ecosystem agreed on a convention:

• The body of an internal message starts with a 32-bit unsigned opcode.
• It is followed by message fields whose layout depends on the opcode and is described either in a TEP or in the ABI of the specific contract.
• The contract implements a dispatcher: “if the opcode equals this value — it is a transfer, parse it as the corresponding structure.”

Without this convention, every contract would invent its own format and there would be no interoperability between them.

Standardized opcodes

Common operations — jetton transfer, jetton internal transfer, NFT transfer, NFT ownership notify, and so on — have fixed opcodes defined in TEPs. This means that all compatible contracts of the same type respond to the same numeric prefixes, and wallets and SDKs can interact with them without knowing the specific implementation.

For the actual numeric values of these opcodes, see the current TEPs (TEP-74 for jettons, TEP-62 for NFTs, and so on) — we deliberately do not duplicate them here to avoid drifting out of sync with the standard.

Custom opcodes

Beyond the standard ones, a contract can accept its own operations — for example “change parameter,” “start auction,” or “close position.” For these, the contract author picks any free values that do not collide with the standard ones. These opcodes are recorded in the contract ABI and must be known to anyone interacting with it.

Notable details

• Zero opcode (0x00000000) has a special meaning: a body starting with this prefix carries a text comment by convention. This is how, for example, TON transfers with a memo work — after the zero prefix follows a UTF-8 string.
• Bounce option. If a contract receives a message with an unknown opcode and cannot handle it, a properly written contract will bounce the original message back so the user does not lose funds.
• Security. If a contract dispatches opcodes without checking the sender, anyone could trigger a sensitive function unintentionally. Good implementations verify the sender address and message context inside every handler.

In practice

For a developer, the opcode is the first thing they define when designing a contract: the list of operations, their numeric values, and the field layout. For an integrator (exchange backend, wallet, indexer), the opcode is what signals the meaning of a transaction when parsing incoming messages.