forwardPayload to provide custom data for the transaction recipient. This is a convention, not a language feature.
Jetton payload schema
By definition, the TL-B format is(Either Cell ^Cell): one bit plus the corresponding data depending on the bit:
- bit 0 indicates inline payload: all subsequent bits and references;
- bit 1 indicates ref payload: the next reference.
- Some allow empty data, no bits at all, which is invalid because at least one bit must exist. An empty payload should be encoded as bit 0 – empty inline payload.
- Some do not verify that no extra data remains after bit 1.
- Error codes vary across implementations.
Canonical payload typing
TL-B(Either X Y) is a union type X | Y in Tolk. This can be defined as:
- consumes more gas due to runtime branching (
IFbit 0); - does not verify that no extra data remains after bit 1.
Payload typing cases
The approach to representing a jettonforwardPayload depends on the intended usage and validation requirements.
Proxy data without validation
To proxy any data as-is, useRemainingBitsAndRefs:
Canonical union with validation
To validate a canonical unionRemainingBitsAndRefs | cell, ensure that no extra data remains after a ref payload:
Validation with slices
If gas consumption is critical but validation is required, avoid allocating unions on the stack. Instead, validate a slice and keep it for further serialization:Custom error codes
To throw custom error codes instead of an error with exit code 9, callingloadMaybeRef() is discouraged.
Dynamic assignment
Keeping a remainder reduces gas usage and enables validation, but it is less convenient when a payload must be assigned dynamically. The remainder is a plainslice containing an encoded union. For example, creating a ref payload from a cell requires manual construction.
RemainingBitsAndRefs | cell remains convenient for assignment but may incur additional gas costs.