Portal-managed presignatures are optional. They are useful when you want Portal to store the encrypted client-side presignature payload so your application only needs to track presignature IDs and expiration times.
Prerequisites
Before starting, make sure you have:- Created a Portal client
- Created a wallet and have access to the
sharedata
Step 1: Create a Presignature
Call the presign endpoint with your share and choose whether the presignature should be client-stored or Portal-managed.Presignatures currently only support the
SECP256K1 curve (EVM, Bitcoin). ED25519 (Solana) support is coming soon.Option 1: Portal-Managed
To let Portal store the encrypted client presignature payload, setmanaged to true.
Request body:
Response:
data. Store the id and pass it as presignatureId when signing.
For presignature creation, idempotency currently applies only to Portal-managed presignatures. It is not currently available for client-stored presignatures.
Idempotency Behavior
Use a freshIdempotency-Key (typically a random UUID) per presign request. The key should only be reused when you are retrying the same request after a network failure or lost response. In that case, the API distinguishes a few outcomes:
Security Properties
Storing the presignature on Portal’s side does not let Portal sign on your behalf. The payload is encrypted inside the enclave with a key derived from your MPC share and the presignature ID. Your share never leaves the enclave, so Portal infrastructure only ever sees ciphertext. When you sign withpresignatureId, the enclave fetches the encrypted payload and decrypts it using the share from the signing request. If that share differs from the one used to create the presignature, decryption fails and the API returns 404.
Portal-managed presignatures are single-use and subject to the usual expiration. Once a presignature has been used to sign, it cannot be reused.
Option 2: Client-Stored
Omitmanaged (or set it to false) to create a client-stored presignature. The response includes an opaque data blob that you store and pass back when signing.
Response:
Store the
data value from the response — you will pass it as the presignature field in the next step. It is also recommended to store the id and expiresAt values for bookkeeping purposes. The id may be needed when communicating with Portal support.Step 2: Use the Presignature
Pass either:presignature: thedatavalue from a client-stored presignature responsepresignatureId: theidvalue from a Portal-managed presignature response
Raw Sign
Sign an arbitrary hex digest string with a presignature.
For a Portal-managed presignature, pass
presignatureId instead:
Sign (RPC-based)
Use a presignature with the RPC-based sign endpoint for blockchain transactions.
For a Portal-managed presignature, replace
presignature with presignatureId:
Send Assets
Use a presignature with the high-level send assets endpoint.
For a Portal-managed presignature, replace
presignature with presignatureId.
List and Delete Presignatures
Use the list endpoint to see active presignatures for the client API key. The response includes both Portal-managed and client-stored presignatures.204 No Content with an empty body. After deletion, the presignature can no longer be used for signing — for a client-stored presignature, the locally stored data blob for that ID becomes unusable.
Important Notes
Additional Resources
- Presignatures overview — General concepts and use cases
- Send tokens — Sending tokens without presignatures
- Sign Ethereum transactions — Standard EVM signing
- Concurrent transactions — Handling multiple transactions