[NONEVM-3516] Develop a custom operation which would top up (all/filtered) contracts from CLD state #10253

[patricios-space]

NONEVM-3516

[krebernisak]

Looking pretty good!

[Copilot]

Pull request overview

This PR implements a new custom operation fund-contracts for the TON deployment framework that enables automated funding of CCIP and MCMS protocol contracts from the CLD (Chainlink Deployment) state. The operation supports two funding modes: TopUp (add only the difference to reach a target balance) and ExactAmount (transfer a fixed amount regardless of current balance), with flexible targeting of specific protocols and MCMS qualifiers.

Changes:

• Added FundContractsOp operation with flexible YAML/JSON input parsing using a generic OneOf unmarshaler pattern
• Implemented two funding modes (TopUp and ExactAmount) with automatic balance checking for TopUp mode
• Created a reusable OneOf generic type for parsing configuration values that can be either simple strings or objects with nested lists

Reviewed changes

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

Show a summary per file

File	Description
deployment/pkg/ops/ton/fund_contract.go	Core implementation of the fund-contracts operation with contract resolution, balance checking, and message preparation logic
deployment/pkg/ops/ton/fund_contract_test.go	Comprehensive unit tests covering input parsing, various target combinations, and error cases
deployment/pkg/ops/ton/oneof.go	Generic unmarshaler for flexible YAML/JSON parsing supporting both simple values and objects with items
deployment/pkg/ops/ton/fundmode_enumer.go	Generated enum marshaling code for FundMode (TopUp/ExactAmount)
deployment/pkg/ops/ton/targetprotocol_enumer.go	Generated enum marshaling code for TargetProtocol (CCIP/MCMS)
deployment/pkg/ops/index.go	Registered the new FundContractsOp in the operations registry
deployment/go.mod	Promoted gopkg.in/yaml.v3 from indirect to direct dependency for test usage

---

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

[krebernisak]

I really don't think an input type like this is a requirement to fund a few sets of contracts. It's more complex than it needs to be, and our tooling is already overly complex as is.

The way you describe it here it sounds like a map[string]any, not sure we need a special type

Also, why not just a simple []string input?

[krebernisak]

btw. we need to consider we already have the TON addr input resolver implemented, so funding addresses is as easy as:

 - 0035_via_mcms_test_transfer_value:
      payload:
        anySequenceIn:
          defs:
            - id: "ton/ops/send-messages"
              version: "0.1.0"
          inputs:
            - messages:
              - bounce: true
                dstAddr:
                  resolver: "codec.resolvers.address-ref-to-ton-addr"
                  data:
                    type: "RBACTimelock"
                    qualifier: "RMNMCMS"
                amount: "10000000" # 0.01 TON = 10000000 nanoTON
              - bounce: false
                dstAddr:
                  resolver: "codec.resolvers.address-ref-to-ton-addr"
                  data:
                    type: "Router"
                amount: "10000000" # 0.01 TON = 10000000 nanoTON
              plan: false # Will get executed immediately without going through MCMS
        options:
          chainSelector: 13879075125137744094  # TON Localnet

So we can basically just prepare funding configuration (above) and execute when we'd want to fund.

What exactly else would we need form this operation/PR?

[patricios-space]

Yes, this was built before an TON address resolver being available. We should still be able to define a target balance and let the operation do the math.

[patricios-space]

reworked the operation into a top-up resolver