After processing
The contents of an internal message after it was processed are as follows:ihr_disabled— unused, always set totrue.bounce— whether the message is bounceable.bounced— whether the message has been bounced.src— address of the contract that sent the message.dest— address of the account that received the message.value— amount of Toncoin and extra-currency attached to the message.extra_flags— used with the new bounce format.fwd_fee— fee charged for forwarding the message.created_lt— logical time when the message was created.created_at— unix time when the message was created.
Before processing
When a contract sends a message, the requirements for the structure above are relaxed.StateInit field against the StateInitWithLibs type.
Deploy
It is possible to simultaneously send both the payload in thebody field and the StateInit in the init field to initialized the contract and process the payload in the same transaction.
Message value
The message may setvalue field that tells to transfer Toncoin and extra-currency to the recipient of the message. The actually transferred amount depends on the value of this field and a send mode.
Bounces
A bounce message is used to inform the sender that handling of their message failed. It is sent automatically to a sender when- there is enough Toncoin to send it left from handling the failed message,
- and the message is bounceable,
- and when either
- a message throws an error from the compute phase during message processing and state was not committed by
COMMITTVM instruction, - or a message throws an error in the action phase and mode
SendBounceIfActionFailis used.
- a message throws an error from the compute phase during message processing and state was not committed by
Default bounce
If thebounce flag is set to true, the message is bounceable. If the bounce conditions are met, the bounce message is produced from the failed message with the following transformation:
srcanddestfields are swapped.- The
bouncedflag is set totrueto tell it’s the bounce message. - The
bounceflag is set tofalseto prevent infinite loop of bouncing messages until no Toncoin is left to spend. bodyis replaced with the concatenation of 32 bits equal to one (0xffffffff) and the first 256 bits of the oldbody. The newbodyis stored in the message in-place, withleftof theEither.
src address of the original message.
New bounce format
The default bounce format has a flaw, that itsbody is too small to store even an internal address, and thus has limited usability for real-world applications. A new bounce format was introduced to address this issue.
Using the extra_flags field, it is possible to change how the new body will be constructed. All other transformations remain the same.
- If
(extra_flags & 1) = 1the new bounce format is enabled. The bounced message now contains the root cell of thebodyof the failed message, with all the refs removed from it.- If
(extra_flags & 2) = 2is also set, the bounced message contains the entirebodyof the original message, without removing any refs.
- If
extra_flags are reserved for future use.
When a message in new bounce format is bounced, the bounce message body has the following format (new_bounce_body):
original_body— the cell that contains the body of the original message. Ifextra_flags & 2then the whole body is returned; otherwise only the root without refs is included.original_info— the value, lt, and Unix time of the original message.bounced_by_phase:0- compute phase was skipped.exit_codedenotes the skip reason:exit_code = -1— no state (an account is uninit or frozen, and noStateInitis present in the message).exit_code = -2— bad state (an account is uninit or frozen, andStateInitin the message has the wrong hash).exit_code = -3— no gas.exit_code = -4— account is suspended.
1— compute phase failed.exit_codeis the value from the compute phase.2— action phase failed.exit_codeis the value from the action phase.
exit_code— 32-bit exit code, see above.compute_phase— exists if it was not skipped, i.e., whenbounced_by_phaseis not 0.gas_used— same asgas_usedofTrComputePhaseof the transaction.vm_steps— same asvm_stepsofTrComputePhaseof the transaction.
extra_flags as the original message. The rest of the bits are set to zero.