Initial Multichain API docs

[alexandratran]

Description

Initial Multichain API docs.

Issue(s) fixed

Fixes #1566

Preview

(Links updated Mar 5)

• Interact with multiple networks
• About the Multichain API
• Multichain API reference

Checklist

Complete this checklist before merging your PR:

• If this PR contains a major change to the documentation content, I have added an entry to the top of the "What's new?" page.
• The proposed changes have been reviewed and approved by a member of the documentation team.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
metamask-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 22, 2025 4:06am

[vandan]

For MetaMask, I do not believe we need to document the scenario where wallet_createSession is used with sessionIds.

[vandan]

Sorry to change this, but the multichain API will essentially be rolling directly to production (vs Flask). We will still need to describe it as "experimental" in the API reference though.
We could also reference the following MIPs, which will include a little more detail:
https://github.com/MetaMask/metamask-improvement-proposals/blob/main/MIPs/mip-5.md (Multichain API)
https://github.com/MetaMask/metamask-improvement-proposals/blob/main/MIPs/mip-6.md (Ethereum-specific use of the Multichain API)

[jiexi]

it's flask and beta soon i believe. @vandan

[alexandratran]

To clarify, should we remove the flask label and replace it with a note that the feature is experimental / a beta release?

[vandan]

Yes, let's remove the Flask label. We can just make a note that the APIs are considered experimental and may be subject to changes.

[jiexi]

Since we're on our way to hitting prod soon. Let's do no flask label, no beta label, just an experimental label. I think that's what Vandan is saying

[jiexi]

this is specifically for making eth_subscription events over wallet_notify easier to read. It will break if there are other wallet_notify events that are not eth_subscription. Perhaps we remove this block entirely, or make the guards more precise?

[alexandratran]

If we remove, would we be removing the entire message handling block?

// Set up message listener for events.
extensionPort.onMessage.addListener((msg) => {
  // Format wallet_notify events to be able to read them later.
  if (msg.data.method === "wallet_notify") {
    console.log("wallet_notify:", {
      scope: msg.data.params.scope,
      method: msg.data.params.notification.method,
      subscription: msg.data.params.notification.params.subscription,
      number: msg.data.params.notification.params.result.number
    })
    return;
  }
  console.log(msg.data)
})

Alternatively, we can specify that this example specifically makes eth_subscription events easier to read.

[jiexi]

// Set up message listener for events.
extensionPort.onMessage.addListener((msg) => {
  if (msg.data.method === "wallet_notify") {
    console.log("wallet_notify:", msg.data.params)
    return;
  }
  console.log(msg.data)
})

something like this?

my concern is that the following block will cause an exception if a wallet_notify event comes through that is not eth_subscription. Also given that this particular example is in the generic Multichain API examples, it may be nice for the listener example to also be ecosystem agnostic

  if (msg.data.method === "wallet_notify") {
    console.log("wallet_notify:", {
      scope: msg.data.params.scope,
      method: msg.data.params.notification.method,
      subscription: msg.data.params.notification.params.subscription,
      number: msg.data.params.notification.params.result.number
    })
    return;
  }

[jiexi]

@adonesky1 we technically don't enforce these yet

[adonesky1]

Yeah let's remove this

[alexandratran]

Should I remove the whole sessionProperties or just "caip154-mandatory": "true"?

[jiexi]

yeahh... hmm... let's remove sessionProperties entirely until we actually support it to avoid confusion. Thank you for clarifying!