Skip to content

Conversation

@tt-cll
Copy link
Contributor

@tt-cll tt-cll commented Dec 23, 2025

No description provided.

Copilot AI review requested due to automatic review settings January 7, 2026 16:53
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR introduces a TON development environment implementation with comprehensive CCIP contract deployment and configuration capabilities. The primary focus is adding a new devenv-impl module that integrates TON blockchain support into the chainlink-ccip devenv infrastructure.

Key Changes:

  • Created new devenv-impl module implementing CCIP16TON interface for TON chain integration
  • Refactored deployment helpers to use type-safe Transactions wrapper instead of raw byte slices
  • Updated function naming for consistency (e.g., LoadMCMSOnchainStateLoadMCMSOnChainState)

Reviewed changes

Copilot reviewed 7 out of 8 changed files in this pull request and generated 4 comments.

Show a summary per file
File Description
devenv-impl/impl.go Core implementation of CCIP16TON interface with message sending, event monitoring, and chain operations
devenv-impl/utils.go Helper function to derive node addresses from key bundles
devenv-impl/ton.toml Configuration file defining TON blockchain and EVM test environments
devenv-impl/README.md Documentation for running the devenv implementation
deployment/ccip/helpers/utils.go New Transactions type wrapping serialized messages with type-safe operations
deployment/ccip/helpers/execute.go Updated to use new Transactions type
deployment/ccip/operation/*.go Refactored operations to return *Transactions instead of [][]byte
deployment/ccip/sequence/*.go Updated sequences to use Transactions type and append operations
deployment/state/state.go Renamed functions for consistency and added new loader for MCMS state
integration-tests/deployment/ccip/cs_deployer_test.go New test validating contract deployment and OCR3 configuration via deployer API
integration-tests/deployment/mcms/cs_deployer_test.go New test for MCMS deployment with idempotency verification
.github/workflows/test-smoke.yml New CI workflow for running TON smoke tests

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

)

// WaitOneExecEventBySeqNo wait and fetch strictly one ExecutionStateChanged event by sequence number and selector.
func (m *CCIP16TON) WaitOneExecEventBySeqNo(ctx context.Context, from, to, seq uint64, timeout time.Duration) (any, error) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we somehow structure this infra more and split up the three different components?

  1. ENV setup/spinup (infrastructure)
  2. Protocol deployments + configuration (product)
  3. Protocol interactions + tests (running a scenario)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah will give that a shot

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tried splitting into 3 files. offchain, onchain, and test_framework

return tonChain, nil
}

func CreateClient(ctx context.Context, url string) (*ton.APIClient, error) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code is also duplicated here, and probably in few other places: https://github.com/smartcontractkit/chainlink-ton/blob/main/staging-monitor/lib/ton/client.go#L92

@jadepark-dev can you support Terry here and try to figure out a single package in chainlink-ton which exposes an utility fn like this to connect a client, which can be reused in other modules (avoid duplication)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can try updating the staging-monitor ref to the deployment utils ref; the staging-monitor module already has a dependency on the deployment module. Whether that's the best place for it to live, we can figure out

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Scoped out a follow up ticket here: https://smartcontract-it.atlassian.net/browse/NONEVM-3451

Should live in the root chainlink-ton module so others can import.

env:
GH_TOKEN: ${{ steps.setup-github-token.outputs.access-token }}
# Deployment configuration
WORKFLOW_FILE: .github/workflows/test_smoke.yml
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, is this workflow TON-specific? I checked it out and has TON-specific steps like build TON contracts and other - why is that, what's the goal/structure here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're trying to follow a model proposed by https://docs.google.com/document/d/18ZgE45u7XkSSZgiKsxDKgoWeQSRIzaNPv8WbH-pyxig/edit?tab=t.0#heading=h.1f85iu2b3snb

The re-usable flow is not TON specific and any chain should be able to trigger the devenv flow. The reason we had to add the build for TON contracts is when we're trying to source "local" contracts. The other reason we need a ref to the triggering repo is that the env configs are going to live in that repo (e.g. the ton.toml we have defined for blockchains here) so the test runner needs a way to refer to that config.

The scaffolding has tradeoffs. If we define a re-usable flow in chainlink-ccip, it will end up needing to be refs to the calling repo so we can perform any chain specific setup required. If we don't have a re-usable flow and have each chain's repo implement their own action, we end up duplicating the ccip devenv setup steps

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the context!

is when we're trying to source "local" contracts

But the local contracts are here, as is other context. Can I use your reusable component here vs. triggering it there? Why this can't be an module we import hook into and run here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes that is certainly possible. I tried to get this working with workflow_call rather than workflow_dispatch earlier in development which would have been the action running here rather than chainlink-ccip. 5d7cb4f

https://github.com/smartcontractkit/chainlink-ton/actions/runs/20666861690/job/59340834271

The issue was that workflow is tightly coupled to other actions in chainlink-ccip so we would either have to duplicate actions (and secrets) across repos, or refactor the workflow to actually be standalone and capable of import. If you'd like, we can investigate it in a followup. It should be possible but will require some rework is all.

@tt-cll
Copy link
Contributor Author

tt-cll commented Jan 7, 2026

Copy link
Contributor

@huangzhen1997 huangzhen1997 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good, just needs to fix CI lint errors and update go.md graph (./modgraph > go.md)

return FundWalletsWithCtx(t.Context(), client, recipients, amounts)
}

func FundWalletsNoT(client ton.APIClientWrapped, recipients []*address.Address, amounts []tlb.Coins) error {
Copy link
Contributor

@huangzhen1997 huangzhen1997 Jan 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These "NoT" and "WithCtx" aren't idiomatic Go. We should just keep FundWallets that takes context, and you can pass context.Background() for offchain.go.

Then callers use:

  • Tests: FundWallets(t.Context(), ...)
  • Other: FundWallets(ctx or context.Background(), ...)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that's fair. I was trying to avoid too big of a blast radius with these changes, but there aren't that many calls it looks like

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it looks like the code in core uses this as is, which is causing the tests to fail. I'm going to revert back to the original change as I really don't want to incur a 3+ repo PR for this

{"ImportPath":"github.com/smartcontractkit/chainlink/deployment/ccip/changeset/testhelpers","Action":"build-output","Output":"../deployment/ccip/changeset/testhelpers/test_environment.go:505:22: cannot use t (variable of type *\"testing\".T) as \"context\".Context value in argument to utils.FundWallets: *\"testing\".T does not implement \"context\".Context (missing method Done)\n"}

@tt-cll
Copy link
Contributor Author

tt-cll commented Jan 8, 2026

return nil
}

func (m *CCIP16TON) PostDeployContractsForSelector(ctx context.Context, env *deployment.Environment, cls []*simple_node_set.Input, selector uint64, ccipHomeSelector uint64, crAddr string) error {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But where do we actually deploy? Where do we integrate the product level adapters we implemented in this devenv?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The neat thing is that because every chain implements the same API, we can share most of the deployment/configuration setup https://github.com/smartcontractkit/chainlink-ccip/blob/0be702ef3ff57ec1fd258e96151c1f5e4bb372fc/devenv/common/implcommon.go#L55. Every impl actually calls this shared function to deploy. The pre- and post- methods are just for things that might be chain specific, like price updates

@tt-cll tt-cll enabled auto-merge (squash) January 8, 2026 18:42
@tt-cll tt-cll merged commit 1189180 into main Jan 8, 2026
38 of 41 checks passed
@tt-cll tt-cll deleted the tt/devenv branch January 8, 2026 22:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants