Allowed list

[gmesika-coti]

Hi Metamask Team
I would happy to hear about the review state of our snap. dApp is serve via snap.coti.io.
the snap lib is @coti-io/coti-snap

if there is anything we can do to help push this fwd, please let us know, Also have being in communication with Christian Montoya

Thank you!

[Montoya]

Sorry for the wait. It's in the review queue.

[gmesika-coti]

Hi @Montoya
Thank you for your reply, we fully appreciate the time taken to review this.

The reason user that signs the message sees this values is due to the fact he is signing his public key details displayed to bytes (mess of Unicode as described above)

Please let me know if the summary below explains and answer the inquiry.
Also , we have an upcoming version that sorts out the onboarding flow as a step by step including progress bar to have it clearly displayed to users.

Here is a summary of the flow as described in our documentation:
To enable a performant solution with strong privacy guarantees, COTI V2 utilizes a novel combination of well-established privacy-preserving technologies (PETs), with the main ingredient being a Garbling Protocol. A garbling protocol enables two or more parties to jointly compute a function while keeping both their inputs and intermediate variables private.

The gcEVM uses AES keys—unique and determenistic per user—for encrypting and decrypting private data. These keys are securely distributed through an RSA-based exchange process mediated by a precompiled smart contract soley for owner contract.

1. Generating RSA Keys
   Each user begins by generating an RSA key pair (public and private keys).
   RSA serves as the secure transport layer for AES key exchange.
2. Signing the RSA Public Key
   The user signs their RSA public key with their account’s ECDSA private key.
   This step proves ownership and prevents man-in-the-middle substitution of keys.
3. Retrieving the AES Key
   The user calls the GetUserKey function on the precompiled contract, providing:
   Their RSA public key
   The ECDSA signature
   The contract emits an event containing the AES key, encrypted with the user’s RSA public key.
   Only the user can decrypt this AES key using their RSA private key, ensuring end-to-end confidentiality.
4. Result
   Once decrypted, the AES key becomes the user’s persistent encryption key for:
   Encrypting inputs (via randomization + XOR operations)
   Decrypting outputs from gcEVM computations

[Mrtenz]

Hi @gmesika-coti, the unicode characters provide no way for users to verify what they are signing. Preferably, you show the deserialised message, or add some further details about what the user is signing. If you can't show a deserialised message, we feel like it should at the very least be shown as hexadecimal data, so the message is somewhat "verifiable".

[gmesika-coti]

Thank you for the review @Mrtenz
We fully understand the concern raised and checking how to mitigate it.
Having said that, we already have an updated version of the snap and the companion dApp on: https://metamask.coti.io
the updated one introduces a flow style of the onboard (please see picture below) that could be used to explain the user on what he sees in the transaction confirmation screen.
do you think that will be enough at least until we will provide a more friendly (hex) version later on? ( the hex version might require code changed in the node that is involving hard fork , under investigation)

Also , important to note that the version and dApp I mentioned here is not the one originally stated in the original review , is it possible to switch the review already to the updated one or should we open a new review case?

[FrederikBolding]

@gmesika-coti Just for clarity, we are asking that you change how the message being signed is displayed in the UI, no need to change the underlying protocol. We just want to make it more legible for the user. At least when the message itself is just raw bytes anyway.

Would that be possible to do ASAP?

[RafaBlockDev]

Hi @FrederikBolding @Mrtenz @Montoya

Thank you again for the detailed feedback...

To provide a bit more context:
In COTI's privacy architecture, each user performs a secure key exchange during onboarding. This involves generating an RSA key pair locally and then signing the RSA public key with their Metamask account (via ECDSA). This signature step ensures ownership of the key pair and prevents key substitution.

The RSA public key is DER-encoded binary data - not a text string - and it's passed directly to Metamask for signing. Both our SDK (@coti-io/coti-ethers) and the COTI blockchain (through our MPC precompiled contract) validate the exact byte sequence that was signed to ensure deterministic verification on-chain.

This process is described in the official COTI documentation:

• AES Keys — Generating and Signing RSA Keys

  “To begin, you must generate an RSA key pair, as RSA encryption is used to securely transmit AES keys. Next, sign the generated RSA public key using your account’s private key with the ECDSA signing scheme.”

• AES Keys — Retrieving the AES Key

  “After completing these steps, call the GetUserKey function on the network's precompiled contract. Pass your RSA public key and its signature as arguments. The precompiled contract will respond with your AES key, encrypted in a way that only your RSA private key could decrypt.”

• MPC Core Functions

  “function getUserKey(bytes calldata signedEK, bytes calldata signature) returns (bytes memory keyShare0, bytes memory keyShare1)”

After some internal testing, we've confirmed that unfortunately we cannot modify the payload format (for example, converting it to hex) before it's sent to Metamask. Here's why:

• The SDK and on-chain contract both verify the exact byte payload that was signed.
• Metamask signs the raw DER-encoded RSA public key (a Uint8Array), and the contract expects that exact byte sequence.
• If we convert it to a hex string or serialize it differently, Metamask signs the characters of the string, resulting in a different hash. This causes the on-chain validation to fail.
• The validation is enforced at the protocol level by the MPC_PRECOMPILED contract - a precompiled component (see reference) within the COTI node responsible for verifying the signed RSA public key and deterministically reconstructing the user’s AES key shares. This contract expects the exact same byte sequence that was signed off-chain by Metamask. Any alteration in the payload encoding (for example, converting binary data to a hex string) produces a different message digest, causing the ECDSA verification to fail inside the precompiled contract and resulting in a rejected key exchange.

In short, the unreadable characters in the confirmation screen occur because metamask interprets binary DER data as UTF-8 text. Unfortunately, we can't change this behavior without breaking signature validation.

As a possible mitigation, would it be acceptable if we introduced a UI update that adds an onboarding step before the Metamask signature prompt?

In that step, we could clearly inform the user that:

“You are signing your RSA public key as part of the secure key exchange process.”

This would make the intent clearer to the user, even if Metamask continues to show non-printable characters in the confirmation window.

Would such an approach be acceptable as an interim solution?

I've attached a video here that demonstrates the idea: https://streamable.com/ivinqh

[Montoya]

Hi @gmesika-coti. I have updated the allowlisting request to use the new dapp URL and the latest version of the Snap on npm. Just wanted to call out that in testing the new dapp, when I try to onboard with zero funds in my wallet, I get this error that shows up briefly and then disappears. It would be better to have the error stay up and then direct the user to fund their wallet so they can proceed with onboarding.

(Also, "the metamask" should be replaced with "MetaMask")

Screen.Recording.2025-10-23.at.3.19.50.PM.mov

[RafaBlockDev]

Sent: https://mainnet.cotiscan.io/tx/0xb44da21d49fb84c93635330ad0bcad81e4a10afc8a393ac0962e7403a1fca128

[Montoya]

Thank you! I was able to go through the onboarding flow successfully. One additional recommendation: this confirmation should really show the URL of the dapp making the request. You can get that information from the request in onRpcRequest, there's an origin parameter: https://docs.metamask.io/snaps/reference/entry-points/#onrpcrequest

That way the user knows which URL is creating the request.

[RafaBlockDev]

Okas

[gmesika-coti]

@Montoya thank you and the metmask team for the feedback and help here! any idea on when it will be allowed publicly?

[Montoya]

Hi @gmesika-coti @RafaBlockDev , the Snap has been allowlisted: https://snaps.metamask.io/snap/npm/coti-io/coti-snap/

Thank you for your patience and for your detailed answers to our questions!

[gmesika-coti]

Thank you for the help @Montoya @Mrtenz @mcmire @BjornGunnarsson !

Could we possibly ask to modify the category list of the snap , add Privacy as an option and categorize us there?