Skip to main content
This example shows how the Portal Provider interacts with the MPC wallet and the blockchain. The params have a hardcoded address for the transaction of sending 1 wei 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. Here is a quick example of how you can make requests using Portal’s web3 provider:
Ensure you have set the gateway URL correctly with Infura or Alchemy when you initialize the portal class.

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:

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.

Signing Solana Transactions

We offer a portal.sendSol function to make the process of sending sol very simple.
We also offer methods to build your Solana (and Eth) transactions.
If you would like to construct your own more advanced transaction for solana then here is how you can do it. Add SolanaKt library to your project as it will help you build the transaction. (You can also use any other library of your choice.)
Then build a Solana request and send it using portal.request(chainId, PortalRequestMethod.sol_signAndSendTransaction, listOf(solanaRequest)

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 effectively unlocks your ability to use the Portal SDK with any chain that uses SECP256K1 or ED25519.

Enabling the Enclave Signer

Executing MPC operations requires computation on the client device. Depending on the CPU of the client device this can take variable amounts of time, leading to inconsistent signing times across users. To solve this, you can leverage the Enclave MPC API from your SDK to execute MPC operations server-side which leads to consistent (and often faster) signing speeds. This feature leverages the Enclave MPC API by sending the user’s key share to a Trusted Execution Environment (TEE) which runs the MPC code in a secure AWS Nitro Enclave with the same non-custodial guarantees as client-side MPC.
By enabling the useEnclaveMpcApi feature flag the client key share will be transmitted from the user device, but it is never stored.
TEEs in Nitro Enclaves work by encrypting memory and verifying execution. Encrypted memory means that all of the data being processed on the enclave can’t be accessed by anything other than the running application. Portal employees can’t even read the data on there! Verified execution means that a user can cryptographically verify that their request was handled in a secure enclave. When a user sends an API request to the enclave, Portal returns a set of signed “measurements” that can be verified by the enclave’s public key to ensure that the request was processed on an AWS Nitro Enclave. To learn more check out our blog post introducing the Enclave MPC API. Here’s how to enable it:
By setting useEnclaveMpcApi to true, the Portal instance will use the Enclave MPC API for signing transactions, ensuring faster computation and consistent performance across client devices.
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.