> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getpara.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Transaction Signing by Wallet Type

> Send the correct REST transaction or raw-byte payload for EVM, Cosmos, Solana, Stellar, and Sui wallets

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](/v3/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.

```typescript theme={null}
const { signedTransaction } = await para.signTransaction(evmWalletId, {
  transaction: {
    to: "0x1111111111111111111111111111111111111111",
    value: "1000000000000000",
    chainId: 11155111,
    type: 2,
    nonce: 0,
    gasLimit: "21000",
    maxFeePerGas: "30000000000",
    maxPriorityFeePerGas: "1000000000",
  },
});
```

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.

#### 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.

```typescript theme={null}
const { signature } = await para.signTypedData(evmWalletId, {
  typedData: {
    domain: {
      name: "MyDApp",
      version: "1",
      chainId: 11155111,
      verifyingContract: "0xCcCCccccCCCCcCCCCCCcCcCccCcCCCcCcccccccC",
    },
    types: {
      Mail: [
        { name: "from", type: "address" },
        { name: "to", type: "address" },
        { name: "contents", type: "string" },
      ],
    },
    primaryType: "Mail",
    message: {
      from: "0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B",
      to: "0xCcCCccccCCCCcCCCCCCcCcCccCcCCCcCcccccccC",
      contents: "Hello, world!",
    },
  },
});
```

Do not include `EIP712Domain` in `types`; Para derives it from the `domain` fields.

#### EIP-7702 authorization

EIP-7702 authorization signing is EVM-only.

```typescript theme={null}
const authorization = await para.signAuthorization(evmWalletId, {
  authorization: {
    address: "0x1234567890abcdef1234567890abcdef12345678",
    chainId: 1,
    nonce: 0,
  },
});
```

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`.

### 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()`.

```typescript theme={null}
const { signature } = await para.signRaw(cosmosWalletId, {
  data: cosmosSignBytesHex,
  walletType: "COSMOS",
});
```

<Warning>
  `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.
</Warning>

### Solana transaction

Pass a base64-encoded serialized Solana transaction. Both legacy `Transaction` and v0 `VersionedTransaction` formats are
accepted and auto-detected.

```typescript theme={null}
const { signedTransaction } = await para.signTransaction(solanaWalletId, {
  transaction: solanaTransactionBase64,
  network: "SOLANA_DEVNET",
  broadcast: false,
});
```

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.

```typescript theme={null}
const { signedTransaction } = await para.signTransaction(stellarWalletId, {
  transaction: stellarTransactionXdr,
  networkPassphrase: "Test SDF Network ; September 2015",
});
```

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`.

```bash theme={null}
curl -X POST "https://api.beta.getpara.com/v1/wallets/$SUI_WALLET_ID/sign-transaction" \
  -H "X-API-Key: $PARA_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"transaction\":\"$SUI_TRANSACTION_BASE64\"}"
```

Para returns the serialized Sui signature separately from the unchanged transaction bytes:

```json theme={null}
{
  "signature": "BASE64_SERIALIZED_SUI_SIGNATURE",
  "transaction": "BASE64_BCS_TRANSACTION_DATA"
}
```

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.

```typescript theme={null}
const { signature } = await para.signRaw(walletId, {
  data: digestHex,
  walletType: "STELLAR",
});
```

Passing `walletType` is optional, but it is a useful guard: Para rejects the request if it does not match the wallet
referenced by `walletId`.

<Warning>
  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.
</Warning>

For message payloads, see [Sign messages by wallet type](/v3/rest/signing). See
[Wallet lifecycle by wallet type](/v3/rest/wallet-lifecycle) to create each wallet type, or use the **Endpoints** section
in the REST API navigation for complete request and response schemas.