ACCEPT and gas credit
The ACCEPT instruction changes the gas available to the TVM. For an incoming external message, this change also makes the contract pay for computation and allows the message to produce a transaction.
ACCEPT does not validate a message, guarantee successful execution, or commit contract state.
Tolk exposes the ACCEPT instruction as the acceptExternalMessage() function from the @stdlib/gas-payments module.
Contract balance at risk
Calling ACCEPT before authentication allows invalid external messages to charge the contract balance on testnet and mainnet. Check authentication and replay fields before ACCEPT, and test all failure paths on testnet before deployment.
External message flow
As described in GasLimits, an incoming external message starts with gas credit because it cannot carry Gram. This credit lets the contract inspect the message before agreeing to pay for its execution.
Process an external message in this order:
- Verify its signature or other authentication data.
- Reject expired or replayed messages.
- Call
ACCEPTorSETGASLIMIT. - Update and commit replay state before operations that can fail.
If execution ends before acceptance, TON records no transaction and discards state changes and actions. After acceptance, the contract pays for all compute gas, including gas spent from the initial credit.
See the external-message security guidance for Tolk examples.
ACCEPT and SETGASLIMIT
ACCEPT makes the maximum available gas payable by the contract. SETGASLIMIT accepts the message with a lower limit when its argument is below that maximum.
SETGASLIMIT throws an out-of-gas exception before changing the limit if execution has already consumed more gas than the requested limit. The GasLimits reference defines the exact updates made by both instructions.
Tolk exposes the SETGASLIMIT instruction as the setGasLimit(limit) function from the @stdlib/gas-payments module.
Failures after acceptance
Acceptance creates fee liability but does not guarantee success:
Possible outcomes after successful ACCEPT | Compute gas | State and actions |
|---|---|---|
| Compute phase succeeds as well | Charged | Final data and actions enter the action phase |
Compute phase fails without COMMIT | Charged | Discarded |
COMMIT precedes a later compute failure | Charged | Committed data and actions enter the action phase |
Commit the replay-state update before later operations and actions that are allowed to fail. In Tolk, commitContractDataAndActions() snapshots persistent data and the current action list.
Without a committed replay-state update, validators can deliver the same valid external message again. Each attempt that reaches ACCEPT can charge the contract.
The execution phases determine whether state changes and actions take effect. Incoming external messages cannot bounce because they have no on-chain sender — there is no one to receive the bounced message.
Internal messages
An internal message starts without gas credit and does not require explicit acceptance. ACCEPT raises its gas limit to the maximum available to the contract, which can spend balance held before the message arrived. SETGASLIMIT can apply a lower limit.
Neither ACCEPT nor SETGASLIMIT changes the bounce behavior of internal messages.