Sign a transaction
Want to implement your own style, but with all the functionality Portal offers? Use these functions to implement your own custom web3 UI for your users.
Last updated
Was this helpful?
Want to implement your own style, but with all the functionality Portal offers? Use these functions to implement your own custom web3 UI for your users.
Last updated
Was this helpful?
This example shows how the Portal Provider interacts with the blockchain.
The Provider has a address
of our MPC wallet. The Provider then proxies the request for balance to the configured RPC url and returns the result.
Below is an example of how to use Portal to send a USDC transaction on the Ethereum Sepolia testnet:
This example demonstrates how to use Portal's SDK to send a transaction on the Ethereum Sepolia testnet. The transaction involves sending 1 USDC to a specified recipient address. Here's a breakdown of the process:
Chain ID: The transaction is configured for the Ethereum Sepolia testnet using the CAIP-2 format (eip155:11155111
).
Transaction Parameters: The BuildTransactionParam
struct is used to define the transaction details:
to
: The recipient's address.
token
: The token to send (in this case, USDC
).
amount
: The amount of the token to send (e.g., 1
USDC).
Building the Transaction: The portal.buildEip155Transaction
method constructs the transaction object using the specified parameters.
Signing and Sending: The portal.request
method is used to sign and send the transaction. The method takes the chain ID, the eth_sendTransaction
method, and the transaction details as parameters.
Transaction Hash: Once the transaction is successfully sent, the transaction hash is returned and printed to the console.
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, you'll want to use the eth_estimateGas
RPC call and pass in your transaction as the parameter.
Here's a breakdown of the process:
Chain ID: The transaction is configured for the Ethereum Sepolia testnet using the CAIP-2 format (eip155:11155111
).
Sender Address: The portal.getAddress
method retrieves the user's wallet address for the specified chain.
Transaction Object: A transaction object is created with the following fields:
from
: The sender's address.
to
: The recipient's address.
value
: The amount of native token (ETH) to send, specified in WEI.
Gas Estimation: The portal.request
method is used to call the eth_estimateGas
method, which estimates the gas required for the transaction.
Result Handling: The estimated gas value is retrieved from the response and printed to the console.
To construct your own advanced transaction for solana simply follow that example:
This example demonstrates how to use Portal's SDK to send a transaction on the Solana Devnet. The transaction involves sending 1 USDC to a specified recipient address. Here's a breakdown of the process:
Chain ID: The transaction is configured for the Solana Devnet using the CAIP-2 format (solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1
).
Transaction Parameters: The BuildTransactionParam
struct is used to define the transaction details:
to
: The recipient's address.
token
: The token to send (in this case, USDC
).
amount
: The amount of the token to send (e.g., 1
USDC).
Building the Transaction: The portal.buildSolanaTransaction
method constructs the transaction object using the specified parameters.
Signing and Sending: The portal.request
method is used to sign and send the transaction. The method takes the chain ID, the sol_signAndSendTransaction
method, and the transaction details as parameters.
Transaction Hash: Once the transaction is successfully sent, the transaction hash is returned and printed to the console.
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
.
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.
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.
Related Documentation
However, there's many other PortalRequestMethod
s available for you to use, which .
To learn more check out our blog post introducing.