Contracts
Contracts in Tact are similar to classes in popular object-oriented languages, except that their instances are deployed on the blockchain and they can’t be passed around like Structs and Messages.
Self-references
Contracts and traits have a built-in identifier self
, which is used for referring to their fields (persistent state variables and constants) and methods (internal functions):
Structure
Each contract can contain:
- Inherited traits
- Supported interfaces
- Persistent state variables
- Constructor function
init()
- Contract constants
- Getter functions
- Receiver functions
- Internal functions
Inherited traits, with
Contracts can inherit all the declarations and definitions from traits and override some of their default behaviours. In addition to that, every contract and trait implicitly inherits the special BaseTrait
trait.
To inherit a trait, specify its name after the keyword with
in contract’s declaration. To inherit multiple traits at once, specify their names in a comma-separated list with an optional trailing comma.
As traits are not allowed to have init()
function, a contract inheriting a trait with any persistent state variables declared must initialize them by providing its own init()
function.
If declared or defined in a trait, internal functions and constants can be marked as virtual or abstract and overridden in contracts inheriting from the trait.
Supported interfaces, @interface(…)
It’s hard to figure out what a contract does and what receivers and getters it has without looking at its source code. Sometimes the source is unavailable or inaccessible, and all that’s left is to try to disassemble the contract and introspect it that way, which is a very messy and error-prone approach with diminishing returns and no real reproducibility.
In order to resolve this issue, an OTP-001: Supported Interfaces was created. In accordance to it, Tact contracts can report the list of supported interfaces as a return value of a special supported_interfaces
getter. That getter is accessible off-chain using any TON Blockchain explorer — one just needs to specify supported_interfaces
as a method to execute and get a list of hexadecimal values in return.
These hexadecimal values are truncated to the first 128 bit of SHA-256 hashes of the original String
values of the supported interfaces. The first value in this list must be equal to in hexadecimal notation, which is the first half of the SHA-256 hash for "org.ton.introspection.v0"
. If the first value is wrong, you must stop trying to introspect the contract, as it doesn’t conform to the Supported Interfaces proposal.
To declare support of a certain interface, add one or more @interface("…")
attributes right before contract and trait declarations:
Tact has a small set of interfaces provided under specific conditions:
"org.ton.abi.ipfs.v0"
, in accordance to OTP-003: Self-ABI Reporting — opt-in viaipfsAbiGetter
config property"org.ton.deploy.lazy.v0"
, in accordance to OTP-005: Argument-addressable contracts"org.ton.debug.v0"
, but only if debug mode is enabled"org.ton.chain.any.v0"
if masterchain support is enabled, and"org.ton.chain.workchain.v0"
otherwise
Some traits in standard libraries define their interfaces too:
Ownable
trait specifies"org.ton.ownable"
OwnableTransferable
trait specifies"org.ton.ownable.transferable.v2"
Stoppable
trait specifies"org.ton.stoppable"
Resumable
trait specifies"org.ton.resumable"
To enable supported_interfaces
getter generation and use @interface()
attribute in your Tact contracts, modify a tact.config.json
file in the root of your project (or create it if it didn’t exist yet), and set the interfacesGetter
property to true
.
If you’re working on a Blueprint-based project, you can enable supported_interfaces
in the compilation configs of your contracts, which are located in a directory named wrappers/
:
In addition to that, tact.config.json
may still be used in Blueprint projects. In such cases values specified in tact.config.json
act as default unless modified in the wrappers/
.
Persistent state variables
Contracts can define state variables that persist between contract calls. Contracts in TON pay rent in proportion to the amount of persistent space they consume, so compact representations via serialization are encouraged.
State variables must have a default value or initialized in init()
function, that runs on deployment of the contract. The only exception is persistent state variables of type map<K, V>
since they are initialized empty by default.
Contract constants
Unlike variables, constants cannot change. Their values are calculated in compile-time and cannot change during execution.
There isn’t much difference between constants defined outside of a contract (global constants) and inside the contract (contract constants). Those defined outside can be used by other contracts in your project.
Constant initializations must be relatively simple and only rely on values known during compilation. If you add two numbers for example, the compiler will calculate the result during build and put the result in your compiled code.
You can read constants both in receivers and in getters.
Unlike contract variables, contract constants don’t consume space in persistent state. Their values are stored directly in the code Cell
of the contract.
Read more about constants on their dedicated page: Constants.
Constructor function init()
On deployment of the contract, the constructor function init()
is run.
If a contract has any persistent state variables without default values specified, it must initialize them in this function.
If a contract doesn’t have any persistent state variables, or they all have their default value specified, it may omit the init()
function declaration altogether. That’s because unless explicitly declared, the empty init()
function is present by default in all contracts.
The following is an example of a valid empty contract:
For your convenience, parameter list of init()
can have a trailing comma:
Getter functions
Getter functions are not accessible from other contracts and exported only to off-chain world.
Additionally, getters cannot modify the contract’s state variables, only read their values and use them in expressions.
Read more about them in their dedicated section: Getter functions
Receiver functions
Receiver functions in Tact can be one of the following three kinds:
receive()
, which receive internal messages (from other contracts).bounced()
, which are called when outgoing message from this contract has bounced back.external()
, which don’t have a sender and can be sent by anyone in the world.
Naming a parameter of the receiver function with an underscore _
makes its value considered unused and discarded. This is useful when you don’t need to inspect the message received and you only want it to convey a specific opcode:
Internal functions
These functions behave similarly to private methods in popular object-oriented languages — they’re internal to contracts and can be called by prefixing them with a special identifier self
. That’s why internal functions can sometimes be referred to as “contract methods”.
Internal functions can access the contract’s persistent state variables and constants.
They can only be called from receivers, getters and other internal functions, but not from other contracts or init()
.