For the complete support model and current chain list, see the chain support
overview.
Integration steps
- Create a wallet for the target chain.
- Build and serialize a transaction with the chain’s SDK.
- Request a signature through the chain’s supported Privy signing interface.
- Attach the signature to the transaction.
- Broadcast the signed transaction through the chain’s RPC provider and track its status.
Aptos example
Below is a complete example of how to create a wallet, build a transaction, sign it with Privy’srawSign 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 forfield_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 forTransferContract 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.

