Function Signature Requirements
Every proxy function that handles cross-chain calls must follow this exact pattern:myProxyFunction
, invokeWithCallback
, swap
, etc.), but it must accept two bytes arguments:
bytes calldata tacHeader
- Contains verified TON user informationbytes calldata arguments
- Your custom encoded parametersexternal
visibility - Functions must be externally callable_onlyCrossChainLayer
modifier - Security requirement
Parameter Encoding and Decoding
Simple Parameters
For basic data types, use straightforward encoding:Complex Parameters
For complex data with arrays or nested structures:Complete Implementation Walkthrough
Let’s build a complete proxy function step-by-step, showing external Dapp integration - the most common real-world pattern:- External Dapp contract integration (lines 11-13, 19-21, 32-38)
- Token approval for external contracts (line 33)
- Processing and getting results (lines 35-38)
- RoundTrip response pattern (lines 48-58)
- Proper fee handling for RoundTrip messages (lines 52-53)
- Use
_sendMessageV1
for ERC20 token bridging only - Use
_sendMessageV2
if you need to bridge both NFTs and ERC20 tokens back to TON - The CCL automatically handles token transfers to your proxy before calling your function
- Always include the
NFTAmount
import when using OutMessageV1