Omitting fund logic from network setup makes sense to me(if I am reading it right), but just a reminder that integration tests in core and chainlink-ton are relying on the deployer wallet to fund transmitters:

• https://github.com/smartcontractkit/chainlink/blob/331ae63b34071a820023405e3482ce2ea8d50ce9/deployment/utils/nodetestutils/fund.go#L33-L46
• https://github.com/smartcontractkit/chainlink-ton/blob/082db6f6514f467bbafd94454e8f56b95a395987/deployment/utils/chain.go#L155-L161

Sounds good, think we removed this as we discussed that the integration tests already funded the deployer wallet

The change from tonWallet.Address() to tonWallet.WalletAddress() lacks test coverage. The existing test in ctf_provider_test.go only checks that WalletAddress is not empty but doesn't verify the correct method is being called or that the address value is as expected.

@copilot This is not true, it's tested in rpc_provider_test.go line 276

Not related to this PR but I wonder if we need to apply this change to the rest of the codebase. Any context on bounceable address?

// Address - returns old (bounce) version of wallet address
// DEPRECATED: because of address reform, use WalletAddress,
// it will return UQ format
func (w *Wallet) Address() *address.Address {
	return w.addr
}

// WalletAddress - returns new standard non bounce address
func (w *Wallet) WalletAddress() *address.Address {
	return w.addr.Bounce(false)
}

I think we want to switch to the new WalletAddress() to have non-bounceable, but the underlying address data is identical, just the string rep could be different. Do you see any risk with this change ?

The code previously called tonWallet.Address() and now calls tonWallet.WalletAddress(). If these methods return different values or have different behaviors, this could break existing functionality. Verify that WalletAddress() returns the same address format as the previous Address() method.

The comment says 'invalid - missing URL' but an empty string is technically a valid Go string value. Consider clarifying that this is testing validation logic for an empty/missing URL configuration.

The comment describes this as a 'static estimate' but doesn't explain why 0.1 TON was chosen or what factors influence whether this amount is sufficient. Consider adding context about what operations this covers and approximate cost considerations.

The TON timelock converter initialization lacks test coverage. Consider adding a test case similar to the existing Sui test case at line 1136-1138 to verify the converter is created correctly for TON chains.

The error message for TON encoder type validation is more detailed than the equivalent error messages for EVM (line 1451), Solana (line 1460), Aptos (line 1468), and Sui (line 1481) chains, which only say 'invalid encoder type: %T'. Consider making error messages consistent across all chain families.

The TON executor creation in getExecutorWithChainOverride lacks test coverage. Add test cases to verify the executor is created correctly with the expected options, including the Amount field set to defaultTONExecutorAmount.

The TON timelock executor creation in getTimelockExecutorWithChainOverride lacks test coverage. Add test cases to verify the timelock executor is created correctly with the expected options, similar to other chain family test cases.

Variable 'chain' should be renamed to 'c' for consistency with the naming pattern used in the same function for other chain families (lines 1535, 1539, 1542, 1545).

The TON inspector creation in getInspectorFromChainSelector lacks test coverage. Add test cases to verify the inspector is created correctly for TON chains.