Skip to main content
Tier 2 adds transaction-aware signing. Privy decodes and validates supported transactions before signing, which enables transaction-level policy controls. Your app broadcasts signed transactions through the chain’s RPC provider.
For the complete support model and current chain list, see the chain support overview.

Integration steps

  1. Create a wallet for the target chain.
  2. Build and serialize a transaction with the chain’s SDK.
  3. Request a signature through the chain’s supported Privy signing interface.
  4. Attach the signature to the transaction.
  5. Broadcast the signed transaction through the chain’s RPC provider and track its status.
When configuring policies, use the transaction fields and policy methods supported by the chain’s signing interface.

Aptos example

Below is a complete example of how to create a wallet, build a transaction, sign it with Privy’s rawSign and broadcast it onchain. We use Aptos here, but the pattern is the same for all chains integrated through raw signing.
1

Create a wallet

2

Build the transaction

3

Sign with Privy

4

Broadcast the transaction

Chain-specific implementation examples

Sui

Sui supports multiple cryptographic schemes, with Privy’s implementation utilizing the Ed25519 curve and EdDSA signing algorithm. The following example demonstrates transaction signing for Sui, please note that the transaction bytes should be the full intentMessage: Privy’s “raw sign” endpoint supports policy evaluation for field_source of sui_transaction_command and sui_transfer_objects_command with bytes, encoding, and hash_function. Configure those decoded transaction rules with the signTransactionBytes policy method. Message signing policies are also supported using field_source of message with the signRawMessageBytes method when signing with hash. See example of Sui policies.
When an amount condition is configured on the sui_transfer_objects_command field_source, always configure the sui_transaction_command to allow MergeCoins, SplitCoins and TransferObjects only. Transactions containing commands like MakeMoveVec, MoveCall, Publish, or Upgrade are not supported for now.

Tron

Tron implements the ECDSA signing algorithm using the secp256k1 curve. Privy’s implementation returns 64-byte ECDSA signatures (r || s), while Tron requires 65-byte signatures that include a recovery ID (v) as the final byte. The recovery ID is essential because a 64-byte signature could correspond to two different addresses/private keys. The 65th byte, which can be either 0x1b or 0x1c (derived from 0 or 1 plus 27, following Ethereum standards), resolves this ambiguity. The following example demonstrates message signing and verification for Tron: Privy’s “raw sign” endpoint supports policy evaluation for TransferContract and TriggerSmartContract transactions with bytes, encoding, and hash_function. Configure those decoded transaction rules with the signTransactionBytes policy method. Use the signRawMessageBytes policy method for unparsed raw signing requests that evaluate only system conditions. For structured Tron RPC transaction requests, it’s preferable to configure tron_signTransaction or tron_sendTransaction policy rules instead. See example of Tron policies.

Stellar

Stellar implements the EdDSA signing algorithm using the Ed25519 curve. The following example demonstrates hash signing for Stellar transactions:

Aptos

Aptos is a Move VM chain which uses ed25519 keypairs for signing transactions. Below is an example of how to sign and send a transaction using Privy. See more developer docs here.

Near

With Privy, you can create Near-implicit accounts and sign over arbitrary data. Below is an example of how to create, sign, and send a Near transaction using Privy. (Note that Near requires accounts to be funded sending transactions.)

Movement

Movement is a Move VM chain that uses the Aptos chain standards. Below is an example of how to sign and send a transaction using Privy. See more developer docs here.