Skip to main content
Use POST /v1/wallets/{walletId}/sign-transaction for EVM, Solana, Stellar, and Sui transaction payloads. The wallet ID selects the parser. Cosmos does not support this route, so send the exact chain-specific bytes to sign-raw instead. The examples use ParaRestClient. The object passed to each SDK method is the JSON body for the matching REST route. See REST SDK to initialize the client.

Sign transactions

EVM transaction

Pass an unsigned transaction object. REST supports ordinary legacy type 0 and EIP-1559 type 2 transactions.
Set top-level broadcast: true to submit the signed transaction and create a transaction-history record. EVM also supports signTypedData() for EIP-712 and signAuthorization() for EIP-7702. Both REST adapters cover message, transaction, and typed-data signing. Only the Viem REST adapter exposes signAuthorization(); ethers callers use the core client’s para.signAuthorization() method.

Estimate transfer fees

Call POST /v1/wallets/{walletId}/estimate-fee with the same to, value, chainId, and optional tokenAddress you plan to transfer. EVM responses include feeOptions.normal and feeOptions.urgent. The top-level transaction and funding fields match normal. Both options use the same quote timestamp and block. quote below is the parsed JSON response from a direct HTTP estimate-fee request; transferRequest contains the same transfer parameters. The current @getpara/rest-sdk EstimateFeeResponse type does not yet expose feeOptions, execution budgets, or quote metadata. To select an option, copy its type, gasLimit, and matching fee fields into your transfer request:
selected-fees.ts
The transfer endpoint does not accept a fee-option name. Omitted fees use a fresh recommendation at submission; supplied fee overrides do not expire or refresh automatically. Selecting a quote does not bypass permission checks or policy approval. urgent increases the normal EIP-1559 priority fee by 25%, rounded up, and adds that increase to the maximum fee cap. A zero tip stays zero. For legacy transactions, it increases gasPrice by 25%, rounded up. It does not guarantee inclusion or a confirmation time. gasLimit counts gas units and includes a 20% buffer. Each option’s maxExecutionFeeWei is the execution-gas ceiling: gasLimit × maxFeePerGas for type 2, or gasLimit × gasPrice for type 0. Actual gas usage can be lower, and type 2 can pay less than its fee cap. estimatedFee displays the normal ceiling in the native currency’s standard units. For a native transfer, maxExecutionCostWei adds the requested transfer value to maxExecutionFeeWei. For an ERC-20 transfer, it equals maxExecutionFeeWei; fund the native currency for gas and hold the token amount separately. Read these decimal wei strings with BigInt to avoid rounding. The ceilings exclude separate chain charges, such as L1 data and operator fees on OP Stack chains. See OP Stack transaction fees. quotedAt records when Para read the RPC fee data and latest block; blockNumber identifies that provider block. Use the ISO timestamp and decimal block number to assess the quote’s age. Refresh before signing, especially after a delay or a change in base fees. The quote does not reserve fees or have a guaranteed validity TTL. See the fee-estimate API reference for the response fields.

EIP-712 typed data

EIP-712 is EVM-only. Pass the structured domain, types, primary type, and message directly. Para builds and signs the EIP-712 digest.
Do not include EIP712Domain in types; Para derives it from the domain fields.

EIP-7702 authorization

EIP-7702 authorization signing is EVM-only.
The response includes r, s, yParity, and the combined signature. yParity is 0 or 1, rather than the legacy EVM v value of 27 or 28. contractAddress is accepted as an alias for address. Signing does not apply the authorization on-chain. Once a transaction applies it, the delegation persists until another authorization replaces or clears it. It does not expire after one transaction, and an execution revert does not undo an applied delegation. See Gas sponsorship for Para’s managed transfer flow.

Cosmos transaction

The chain-specific sign-transaction route does not support Cosmos Direct or Amino sign documents. Construct the exact bytes required by the target Cosmos signing flow, encode them as hex, and send them through signRaw().
sign-raw does not add a Cosmos prefix, serialize a sign document, or hash the supplied bytes. Your backend produces the exact hex bytes that the target chain expects Para to sign.

Solana transaction

Pass a base64-encoded serialized Solana transaction. Both legacy Transaction and v0 VersionedTransaction formats are accepted and auto-detected.
Set broadcast: true when Para should submit the transaction and create a transaction-history record. In beta, SOLANA_DEVNET is the supported broadcast network.

Stellar transaction

Pass a base64-encoded Stellar transaction envelope in XDR format and the exact network passphrase used to build it.
Para adds the wallet’s signature to the envelope and returns signed XDR. Stellar transaction signing is sign-only; broadcast: true is not supported.

Sui transaction

Pass a base64-encoded BCS serialization of Sui TransactionData.
Para returns the serialized Sui signature separately from the unchanged transaction bytes:
Sui transaction signing is sign-only. broadcast: true is not supported. networkPassphrase is ignored for Sui. The REST SDK can submit the route through para.signTransaction(), but its generic response type models signedTransaction. Use the raw HTTP response when TypeScript code needs typed access to Sui’s separate signature and transaction fields.

Sign exact bytes

Use signRaw() or POST /v1/wallets/{walletId}/sign-raw when your backend owns chain-specific serialization and hashing. The input is hex, and Para signs those exact bytes without adding a prefix or hash.
Passing walletType is optional, but it is a useful guard: Para rejects the request if it does not match the wallet referenced by walletId.
REST signing is available only while the wallet remains API-key-managed. After the user claims the wallet, sign through a user-facing Para SDK and the user’s authenticated session instead.
For message payloads, see Sign messages by wallet type. See Wallet lifecycle by wallet type to create each wallet type, or use the Endpoints section in the REST API navigation for complete request and response schemas.