Skip to main content
T TON Adoption
RU
← Glossary
NODE/03 · Term

Get-method

Read-only function on a TON smart contract. Runs locally on a node, costs no gas, does not produce a transaction. The basis for almost every wallet UI and explorer query.

Aliases: getter, get_method, ton getter

A get-method is a special function on a TON smart contract that can be called from off-chain (a wallet UI, a dApp backend, an explorer) without producing a blockchain transaction. The node runs the method locally, returns the result, and charges nothing.

Why they exist

TON’s normal execution model is asynchronous and message-based: to make a contract do something, you send it a message. Each message produces a transaction with a gas cost.

That model is a poor fit for read-only queries. If a wallet had to send a message every time it wanted to display a user’s USDT balance, every wallet refresh would burn gas. So TVM exposes a separate, free, side-effect-free entry point: the get-method.

What they look like in code

In FunC:

int balance() method_id {
    return get_data().begin_parse().preload_uint(64);
}

In Tact:

get fun balance(): Int {
    return self.balance;
}

The method_id registers the function in a special table inside the contract’s bytecode. Off-chain callers reference get-methods either by name (which the node hashes to a method ID) or by raw method ID.

How they’re called

Wallets and dApps don’t call get-methods directly on validators. Instead they go through a lite-server — a public-facing TON node that accepts queries and runs the method locally. Common lite-server providers:

  • TON Center (toncenter.com)
  • TON API (tonapi.io)
  • TonScan / Tonviewer back-ends
  • Self-hosted nodes for high-volume infrastructure

A typical call sequence:

  1. dApp asks the lite-server for the contract’s current state cell.
  2. Lite-server runs the get-method against that state in a sandbox.
  3. Returns the result to the dApp.

Latency: usually under 100 ms. No on-chain footprint.

What they can and can’t do

Can:

  • Read storage variables (balances, owner, status flags).
  • Compute derived values (formatted balances, prices, counters).
  • Iterate over dictionaries and parse cell trees.

Cannot:

  • Persist any change to storage.
  • Send messages.
  • Have side effects across calls.

If the method tries to modify state, the change is silently discarded — get-method execution is sandboxed.

Standard get-methods

Many TON standards define mandatory get-methods so that wallets and explorers can introspect contracts:

  • Jettons (TEP-74): get_jetton_data (master), get_wallet_data (wallet), get_wallet_address (master).
  • NFTs (TEP-62): get_nft_data, get_collection_data, get_nft_address_by_index.
  • Wallet contracts: seqno, get_public_key.

If a contract implements these correctly, every wallet on TON can show its data without custom integration.

Practical notes

  • Gas-free does not mean cost-free for the lite-server operator. High-rate queries get rate-limited; production apps usually run their own node or pay for a service tier.
  • State staleness. A get-method runs against the latest known block; results can be a few seconds out of date if the lite-server is lagging.
  • Pure functions only. Two consecutive calls with the same state and arguments must return the same result. Don’t try to use system time inside a getter — it’s not reliably available.

Related terms