Skip to main content
Presignatures let you front-load part of the MPC computation so that subsequent signing completes faster. For a general overview, see the Presignatures resource. This guide walks through creating a presignature and using it with the sign, raw sign, and send asset endpoints. The Enclave MPC API supports two presignature storage modes: 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:
  1. Created a Portal client
  2. Created a wallet and have access to the share data

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, set managed to true.
Headers: Request body: Response:
The response does not include 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 fresh Idempotency-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 with presignatureId, 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

Omit managed (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.
Request body: 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: the data value from a client-stored presignature response
  • presignatureId: the id value from a Portal-managed presignature response
These fields are mutually exclusive.

Raw Sign

Sign an arbitrary hex digest string with a presignature.
Presignatures are currently available for SECP256K1 only. The curve in the URL path (/v1/raw/sign/{curve}) must match the curve used when creating the presignature — passing presignature or presignatureId to /v1/raw/sign/ED25519 returns an error.
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.
Delete a presignature when you no longer need it:
On success, the API returns 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

  • Single-use: Each presignature can only be used once. After signing, you must create a new one.
  • Active limit: You can have up to 100 active presignatures per client. Set up a regular process to discard expired presignatures.
  • Curve matching: For raw sign, the presignature’s curve must match the URL path curve.
  • Expiration: Presignatures expire after their expiresAt timestamp. The default is 7 days; the maximum is 365 days.
  • Portal-managed signing: presignatureId only works for Portal-managed presignatures and requires the same MPC share used to create the presignature.

Additional Resources