Skip to main content
This example screen displays how the Portal Provider interacts with the MPC wallet and the blockchain. The Provider has an input box to set a toAddress for the transaction of sending 0.001 ETH from our MPC wallet. The Provider then receives a signed transaction from our mobile MPC library and submits that to chain using the configured RPC url.
Ensure you have set the gateway URL correctly with Infura or Alchemy when you initialize the Portal class.

Improving signing performance

You can reduce latency for EVM and other SECP256K1 signing by enabling presignatures. The SDK will then pre-compute part of the MPC signing flow in the background and use that data when the user signs, without any change to your code. Enable it via the usePresignatures feature flag when creating your Portal instance. See Feature flags for details.

Idempotency keys

Starting from SDK version 5.2.0, you can make eth_sendTransaction, sol_signAndSendTransaction or sol_signAndConfirmTransaction safe to retry after a timeout by passing an idempotencyKey in RequestOptions. Portal broadcasts a key at most once while it remembers the key (at least 24 hours), so a retry with the same key and the same transaction within that time cannot send the transaction twice. See Idempotency keys for generating keys, retrying, and handling a rejected retry.

Signing a User Operation

If your client uses Account Abstraction, you can sign an ERC-4337 User Operation using the eth_signUserOperation method. This signs the User Operation without submitting it on-chain, returning the signature directly.
User Operation Parameters: You can also pass a signature approval memo and control gas sponsorship:

Signing a Solana Transaction

You can use our provider just like you do with Ethereum with Solana. Simply specify the method and the chainId for Solana. This example uses solana/web3.js to construct a transaction object to sign and pass to the multi-chain provider.

Solana Provider Methods

  • sol_signMessage
  • sol_signTransaction
  • sol_signAndSendTransaction
  • sol_signAndConfirmTransaction

Raw sign

You can now utilize our SDK to generate raw signatures that are generated using the underlying key share without adding any chain specific formatting to the signature. This lets you produce SECP256K1 or ED25519 raw signatures. The namespace of the chain ID you pass selects the curve. Starting from SDK version 5.2.0, only the namespaces in the table below are supported. A chain ID without a namespace is treated as eip155. Starting from SDK version 5.2.0, any other namespace, such as xrpl: or sui:, throws an Error before the approval step and before anything is signed. The same applies to portal.rawSign and to the other signing methods of portal.request. See rawSign for details.
Changed in 5.2.0. Earlier versions selected the ED25519 key for every namespace other than eip155 and bip122. Starting from 5.2.0:
  • tron: signs with the SECP256K1 key behind the client’s Tron address.
  • Any namespace not listed above throws. If you passed one to get an ED25519 signature, pass a solana: or stellar: chain ID instead.

Estimating Gas

By default, Portal will estimate and populate the gas property in a transaction object if the property is undefined. To estimate the gas value manually use the eth_estimateGas RPC call and pass in your transaction as the parameter.
And now you are signing transactions with Portal! 🚀 Next, we’ll explore how to simulate a transaction so that you can create smoother experiences for your users.