Background
We have many different places that call methods in the MPC contract - devnet, e2e test, sandbox tests and in the node.
Each one of these places follows slightly different conventions, which means that a developer working in the repo needs to know all of these different patterns.
It has the additional downside of requiring pretty substantial refactors in case the API changes. We already have the contract-intreface crate as a single source of truth for the contract API, but we should add function extend it to prepare function call arguments.
User Story
As a dev, I prefer a consistent code base over one that has many different patterns to achieve the same thing.
Acceptance Criteria
Extend contract-interface to be a single source of truth for creating function calls to the contract. Hide the functionality behind a feature-flag to avoid unnecessary contract-bloat.
Resources & Additional Notes
No response
Background
We have many different places that call methods in the MPC contract - devnet, e2e test, sandbox tests and in the node.
Each one of these places follows slightly different conventions, which means that a developer working in the repo needs to know all of these different patterns.
It has the additional downside of requiring pretty substantial refactors in case the API changes. We already have the contract-intreface crate as a single source of truth for the contract API, but we should add function extend it to prepare function call arguments.
User Story
As a dev, I prefer a consistent code base over one that has many different patterns to achieve the same thing.
Acceptance Criteria
Extend contract-interface to be a single source of truth for creating function calls to the contract. Hide the functionality behind a feature-flag to avoid unnecessary contract-bloat.
Resources & Additional Notes
No response