refactor: establish contract-interfac/call_args.rs as source of truth

[kevindeforth]

resolves #3728

ci blocked by #3730

[kevindeforth]

note: this method never required a failure path.

[claude]

Pull request overview

Consolidates all NEAR MPC contract function-call argument types into a single call_args module inside near-mpc-contract-interface, gated behind a new call-args feature. The Chain*Args mirrors that used to live in crates/node/src/indexer/types.rs (and the misplaced SubmitParticipantInfoArgs in types/attestation.rs) are removed, and all producers (mpc-node, tee-context) now build these DTOs through derive_more::Constructor new methods. Node-internal → wire conversions are moved into new IntoContractInterfaceType impls plus two extension traits (SignatureRespondArgsExt, VerifyForeignTransactionRespondArgsExt).

Changes:

• New crates/near-mpc-contract-interface/src/call_args.rs module hosting SignatureRespondArgs, CKDRespondArgs, VerifyForeignTransactionRespondArgs, GetPending*Args, GetAttestationArgs, Vote*Args, Start*Args, RegisterForeignChainConfigArgs, SubmitParticipantInfoArgs, ConcludeNodeMigrationArgs.
• Deletes the duplicate Chain* request/args structs in crates/node/src/indexer/types.rs; keeps the marker trait ChainRespondArgs and moves brute_force_recovery_id to a free function.
• Adds Serialize, Deserialize to near_mpc_crypto_types::ckd::CKDRequest so it can be used as a wire DTO directly.
• Moves the new_ecdsa/new_eddsa/new_ckd/VerifyForeignTx constructors onto extension traits; drops the vestigial Result on the CKD constructor (was never fallible).
• Feature-gates the new module (call-args feature) so contract/build targets that don't need serde-serializable arg types don't pull them in.

Reviewed changes

Per-file summary

File	Description
crates/near-mpc-contract-interface/Cargo.toml	Declare new call-args feature.
crates/near-mpc-contract-interface/src/call_args.rs	New module: consolidated arg types with derive_more::Constructor.
crates/near-mpc-contract-interface/src/lib.rs	Expose call_args behind feature flag; stop re-exporting SubmitParticipantInfoArgs from types::attestation.
crates/near-mpc-contract-interface/src/types/attestation.rs	Remove SubmitParticipantInfoArgs definition.
crates/near-mpc-crypto-types/src/ckd.rs	Add Serialize, Deserialize derives to CKDRequest.
crates/node/Cargo.toml	Enable call-args feature.
crates/node/src/coordinator.rs	Use contract_args::RegisterForeignChainConfigArgs::new.
crates/node/src/indexer.rs	Switch view-call arg types to contract_args::*.
crates/node/src/indexer/fake.rs	Use contract_args::* in fake indexer channels.
crates/node/src/indexer/types.rs	Drop local Chain* structs; add SignatureRespondArgsExt / VerifyForeignTransactionRespondArgsExt; extract brute_force_recovery_id as free fn.
crates/node/src/key_events.rs	Replace Chain*Args with contract_args::*Args::new.
crates/node/src/migration_service/onboarding.rs	Replace ConcludeNodeMigrationArgs.
crates/node/src/mpc_client.rs	Call from_ecdsa/from_eddsa and the new CKD/verify constructors.
crates/node/src/requests/debug.rs, requests/queue.rs	Update generic parameters to new types.
crates/node/src/tee/remote_attestation.rs	Use contract_args::SubmitParticipantInfoArgs::new.
crates/node/src/trait_extensions/convert_to_contract_dto.rs	Add IntoContractInterfaceType impls for SignatureRequest and CKDRequest.
crates/tee-context/Cargo.toml, src/lib.rs	Enable call-args, migrate SubmitParticipantInfoArgs.

Findings

Wire compatibility looks preserved: every renamed struct keeps the same serde field names (request, response, key_event_id, foreign_chain_configuration, proposed_participant_attestation, tls_public_key, etc.), and the contract entry points continue to accept the same JSON. The one API-shape change I could find — dropping the (never-triggered) Result around the CKD constructor — has already been called out by the author in-thread.

Non-blocking (nits):

• crates/node/src/indexer/types.rs:119 — Doc comment reads "SignatueRespond arguments" (missing r).
• crates/near-mpc-contract-interface/src/call_args.rs:1 — Module docstring says "signer contract function calls", but the module now also hosts governance / resharing / migration args (SubmitParticipantInfoArgs, ConcludeNodeMigrationArgs, RegisterForeignChainConfigArgs, Vote*Args, Start*Args). Consider dropping "signer" or rewording to just "MPC contract function calls".
• crates/near-mpc-contract-interface/src/call_args.rs:10-26 — The response fields on SignatureRespondArgs / CKDRespondArgs / VerifyForeignTransactionRespondArgs were previously private (only settable through a validated constructor). They are now pub and reachable via derive_more::Constructor::new, which removes the compile-time barrier against constructing a mismatched (request, response) pair. Not a security issue (the contract re-verifies), but if the intent was to preserve the encapsulation, the trivial new from derive_more could be replaced with an inherent new that keeps response private. Otherwise, leaving as-is is fine and matches the "DTO with public fields" convention used elsewhere in this crate.
• crates/near-mpc-contract-interface/Cargo.toml:9 — The one-line # Helper to build mpc contract function call arguments comment paraphrases the feature name; per docs/engineering-standards.md §"Write helpful code comments" this can be removed or elevated to explain why it's opt-in (e.g. "kept off by default so the contract build doesn't pull serde-only helpers").

✅ Approved

[pbeza]

LGTM.

---

FWIW, re this and this PR: I had a short session with Claude to research how other teams handle this, since it seemed like a common problem. I found there’s a #[near_kit::contract] macro that generates typed call builders from a trait. Since these structs (SignatureRespondArgs, CKDRespondArgs, VotePkArgs, SubmitParticipantInfoArgs, etc.) now live in one place here, I think they're exactly the input the macro would need:

#[near_kit::contract]
pub trait MpcSigner {
    #[call]
    fn respond(&mut self, args: SignatureRespondArgs);
    #[call]
    fn respond_ckd(&mut self, args: CKDRespondArgs);
    // ...vote_pk, submit_participant_info, etc.
}

NEAR Intents already does this for their Wallet contract, reused as-is by both their production relayer and sandbox tests (client, sandbox reuse).

Just flagging it before the next layer (call construction / CallContract; #3727) gets built by hand, in case it saves us that work.

[Copilot]

Pull request overview

This PR centralizes the NEAR MPC contract function call argument DTOs in near-mpc-contract-interface (behind a new call-args feature), and updates node/TEE code to consume those types as the single source of truth, aligning with issue #3728.

Changes:

• Introduced near-mpc-contract-interface::call_args (feature-gated via call-args) to host contract call argument types.
• Refactored mpc-node and tee-context to construct and send contract call args using contract_interface::call_args::* instead of node-local Chain*Args.
• Added serde derives where needed (e.g., CKDRequest) to support JSON encoding of moved call argument types.

Reviewed changes

Copilot reviewed 19 out of 19 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
crates/tee-context/src/lib.rs	Switches attestation submission args construction to contract_interface::call_args.
crates/tee-context/Cargo.toml	Enables near-mpc-contract-interface call-args feature for tee-context.
crates/node/src/trait_extensions/convert_to_contract_dto.rs	Adds conversions from node-internal request types to contract-interface DTO request types.
crates/node/src/tee/remote_attestation.rs	Uses contract_args::SubmitParticipantInfoArgs instead of node-local args type.
crates/node/src/requests/queue.rs	Updates tests to use contract_args::*RespondArgs types.
crates/node/src/requests/debug.rs	Updates tests to use contract_args::*RespondArgs types.
crates/node/src/mpc_client.rs	Uses contract_args::*RespondArgs constructors/extension traits for on-chain responses.
crates/node/src/migration_service/onboarding.rs	Uses contract_args::ConcludeNodeMigrationArgs for migration conclude tx.
crates/node/src/key_events.rs	Uses contract_args::* for key-event related contract call args.
crates/node/src/indexer/types.rs	Removes node-local Chain*Args DTOs; rebinds ChainSendTransactionRequest variants to contract_args DTOs and factors out recovery-id logic.
crates/node/src/indexer/fake.rs	Updates fake indexer plumbing to send/receive contract_args response args types.
crates/node/src/indexer.rs	Uses contract_args::*GetPending*Args and GetAttestationArgs for view calls.
crates/node/Cargo.toml	Enables near-mpc-contract-interface call-args feature for node.
crates/near-mpc-crypto-types/src/ckd.rs	Adds Serialize/Deserialize to CKDRequest so it can be used in JSON call args.
crates/near-mpc-contract-interface/src/types/attestation.rs	Removes SubmitParticipantInfoArgs from types (it’s now in call_args).
crates/near-mpc-contract-interface/src/lib.rs	Exposes call_args module behind call-args feature; stops re-exporting removed args from types.
crates/near-mpc-contract-interface/src/call_args.rs	Adds the new centralized contract call argument DTO module.
crates/near-mpc-contract-interface/Cargo.toml	Introduces the call-args feature flag.

---

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

[kevindeforth]

I found there’s a #[near_kit::contract] macro that generates typed call builders from a trait. Since these structs (SignatureRespondArgs, CKDRespondArgs, VotePkArgs, SubmitParticipantInfoArgs, etc.) now live in one place here, I think they're exactly the input the macro would need:

Oh, that's very cool! I need to check if we can make this work with all the other stuff we use. Do you know how stable near_kit is at this point?

[pbeza]

I found there’s a #[near_kit::contract] macro that generates typed call builders from a trait. Since these structs (SignatureRespondArgs, CKDRespondArgs, VotePkArgs, SubmitParticipantInfoArgs, etc.) now live in one place here, I think they're exactly the input the macro would need:

Oh, that's very cool! I need to check if we can make this work with all the other stuff we use. Do you know how stable near_kit is at this point?

Not totally sure, but if NEAR Intents is using it, and that’s apparently one of NEAR’s core products, I’d guess it’s stable enough. Also looks like they’ve been releasing pretty regularly for the last ~5 months: https://crates.io/crates/near-kit/versions. We can ask Ricky, who seems to be near-kit’s release manager (cc @r-near).