Skip to main content
Contract getters (or “get methods”) are declared using get fun xxx(). They typically return data extracted from storage.

The return type is inferred if omitted

Get methods follow the same behavior as functions and methods. However, specifying the type explicitly is considered good practice:

Prefer camelCase for custom names

  • get fun currentOwner() — recommended
  • get fun get_current_owner() — not recommended
Unless it’s required to match standard TEPs. For example, a jetton wallet, by convention, should expose a method get_wallet_data (because it was named so in early implementations). In such cases, get fun get_wallet_data is appropriate, even though it may not look very nice.

Use structures for complex replies

When a getter returns several values — introduce a structure and return it. It’s perfectly fine if a structure is used only once. Field names provide clear metadata for client wrappers and human readers.

Use lazy for storage loading

Prefer lazy loadStorage() over loadStorage(). Unreferenced fields are automatically skipped, resulting in smaller bytecode. See lazy loading.

Get methods may accept parameters

The parameter syntax is identical to that of regular functions:

Get methods are called off-chain

Read the Coming from Ethereum guide. Get methods are evaluated off‑chain by external tooling such as:
  • APIs
  • explorers
  • lite servers

Get methods operate via the stack, not serialization

Get methods accept parameters and return values via the TVM stack, since they are called off-chain. This is why a getter can return int (although it’s not serializable, unlike intN, see numbers). Returning a structure pushes its fields onto the stack as N separate values. Client libraries such as Blueprint parse get‑method responses using a tuple reader. Get methods do not store their names. They are identified by a method_id = crc16(name) | 0x10000 — to avoid storing extra strings on-chain. For low-level details, see get methods in TVM.