Skip to content

respond_ckd and get_pending_ckd_request take the contract-internal CKDRequest instead of the DTO #4255

Description

@gilcu3

Background

crates/contract/src/primitives/ckd.rs:10 defines a contract-internal CKDRequest that duplicates the DTO near_mpc_crypto_types::ckd::CKDRequest (crates/near-mpc-crypto-types/src/ckd.rs:78) field for field, and it is the one exposed by respond_ckd, get_pending_ckd_request and return_ck_and_clean_state_on_success (crates/contract/src/api/ckd.rs). The DTO is what everyone else already uses: call_args.rs:84/:101 and the node (crates/node/src/indexer.rs:140).

It survives only because pending_ckd_requests: LookupMap<CKDRequest, Vec<YieldIndex>> (crates/contract/src/lib.rs:58) needs Borsh, which the DTO does not derive. SignatureRequest (crates/near-mpc-crypto-types/src/sign.rs:112) solves this by deriving Borsh plus the abi-gated schema derives, serving as both wire type and state key.

Acceptance Criteria

  • The DTO CKDRequest derives BorshSerialize/BorshDeserialize and the abi-gated JsonSchema/BorshSchema, matching SignatureRequest.
  • The CKD entry points and pending_ckd_requests use the DTO; crates/contract/src/primitives/ckd.rs no longer defines its own CKDRequest (the pairing helpers stay).
  • The on-chain borsh layout of pending_ckd_requests is unchanged, so no migration is needed.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions