Test adapter support tokens - #792
Conversation
… vv/token-registry-bindings-and-deployment
…ddress Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
fix typo Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
… vv/token-adapter
| // TODO: implement when TON token transfer support is added | ||
| return errors.ErrUnsupported | ||
| // Real jetton approval (e.g. minting an allowance / notifying the pool) is not | ||
| // yet implemented; no tokens actually move so there is nothing to approve yet. |
There was a problem hiding this comment.
This part should probably be sending the tokens to the shared wallet between router and user
vicentevieytes
changed the title
… vv/test-adapter-enable-token-transfer
| // Source token amounts plus the destination token address, grouped into a single | ||
| // ref to stay within the 4-ref-per-cell limit (matches TVM2AnyTokenTransfer in | ||
| // contracts/ccip/onramp/types.tolk). | ||
| TokenTransfer TVM2AnyTokenTransfer `tlb:"^"` |
There was a problem hiding this comment.
Changed from TokenAmounts to TVM2AnyTokenTransfer to have the DestTokenAddress in the event, which is needed by ConvertCCIPMessageSent (pkg/ccip/chainaccessor/event.go).
Alternatively, we could keep this struct unchanged and use TokenAmounts, and add a separate step where the off-chain queries the destination CrossChainAddress from the corresponding TokenPool.
I think EVM and Solana take this information straight from the event though so I went with this approach.
| // exactly the same message it will send to the productive TokenPool. | ||
| type MockTokenPool_InMessage = | ||
| | MockTokenPool_LockOrBurn | ||
| | TokenPool_ApplyChainUpdates; |
There was a problem hiding this comment.
We should get rid of this MockTokenPool and instead use one of the productive pools or a mock pool that uses the real tokenPool lib
|
|
||
| // Native TON attached to the transfer notification, used to pay fees + execution costs. | ||
| const FORWARD_TON_AMOUNT = toNano('1') | ||
| const FORWARD_TON_AMOUNT = toNano('10') |
There was a problem hiding this comment.
Adding a big overhead here to not get InsufficientFee or -14 errors. When the message flow is completely defined we can benchmark and estimate from scratch
| if bal, balErr := ton_tvm.CallGetterLatest(b.GetContext(), chain.Client, preMintWalletAddr, jettonwallet.GetWalletData); balErr == nil { | ||
| preMintBalance = bal | ||
| } | ||
| b.Logger.Infow("[DEBUG] pre-mint: recipient jetton balance BEFORE mint", |
There was a problem hiding this comment.
I'd remove these debug logs but keep the assertions
| if balanceErr != nil { | ||
| return sequences.OnChainOutput{}, fmt.Errorf("failed to read jetton balance for pre-mint recipient %s: %w", recipient.String(), balanceErr) | ||
| } | ||
| b.Logger.Infow("[DEBUG] pre-mint: recipient jetton balance AFTER mint", |
There was a problem hiding this comment.
same, remove the debug log
|
|
||
| // TODO: add TokenAmounts support for TON token transfers | ||
| return router.CCIPSend{ | ||
| tokenAmounts := make(common.SnakedCell[router.TokenAmount], 0, len(components.TokenAmounts)) |
There was a problem hiding this comment.
This change makes the BuildMessage function return two different types depending on wether this is arbitrary messaging (returns CCIPSend) or if it's a TokenTransfer (returns a TokenTransferMessage struct with the CCIPSend payload as forwardNotification)
Then SendMessage changes it's behavior depending on the type that's passed to it, and it either sends the message to the router or to it's wallet.
This would be simpler with the escrow account entrypoint:
- AuthorizeRouterToWithdraw sends the tokens to the escrow account
- SendMessage sends CCIPSend to the router, the router will later withdraw the messages when it needs them.
A quick follow up to this should be to change to this model IMO
1 participant
No description provided.