Description

Explanation
Relates to MetaMask/core#5045

References
Institutional Snap RAPID

The majority of our custodians are still on ECA-1 (or have APIs with an equivalent functionality).

This presents a limitation because the keyring API does not support a workflow where the keyring does not return a signature for publication.

We propose to repurpose the existing asynchronous transaction workflow that was used for MMI. Accordingly, we would bring a small amount of MMI logic (currently code-fenced) into MetaMask, and decide on publication at an account level.

We use the existing beforePublish hook in metamask-controller to read this custodianPublishesTransaction option (set at account level by the institutional snap and tell the transaction controller not to publish based on it. As a side effect, this hook also sets the hash of the transaction and marks it as submitted.

Additionally, custodians can change some transaction parameters. In order to update the params before they are compared with the signature, the InstitutionalSnapController fetches these parameters from the snap.

Related issues

Fixes:

Manual testing steps

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Extension Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.