Skip to main content
Tier 1 provides wallet creation, key export, and low-level signing. Your app builds and broadcasts transactions using the chain’s SDK or RPC provider.
For the complete support model and current chain list, see the chain support overview.

Integration steps

  1. Create a wallet for the chain’s supported key type.
  2. Build the transaction or message with the chain’s SDK.
  3. Produce the payload that the chain expects the wallet to sign.
  4. Sign the payload with Privy’s low-level signing interface.
  5. Attach the signature and broadcast the transaction through the chain’s RPC provider.
Your app is responsible for chain-specific serialization, hashing, submission, and transaction tracking. Include any prefixes, suffixes, or domain separators required by the chain before signing.

Chain examples

Bitcoin (segwit)

Bitcoin (segwit) supports the ECDSA signing algorithm using the secp256k1 curve. Use Privy’s raw sign functionality to sign each input UTXO for your Bitcoin segwit transaction. For more details, see the Bitcoin signing guide.

Bitcoin (taproot)

Bitcoin (taproot) uses the Schnorr signing algorithm (BIP-340) with the secp256k1 curve. Privy automatically applies the BIP-341 key tweak when signing with a taproot wallet, producing signatures valid for key-path spends against the wallet’s P2TR output. For more details, see the Bitcoin signing guide.
Privy’s taproot support uses key-path spending only. The applied tweak assumes no custom Merkle roots or scripts, so script-path spends (e.g., custom Tapscript trees) are not supported.

Cosmos

Cosmos utilizes the ECDSA signing algorithm with the secp256k1 curve. Below is an implementation example for signing hashes on Cosmos:

Ton

All wallets on Ton are smart contract accounts, and Ed25519 keypairs are used to sign transactions on behalf of the smart contracts. When creating a wallet via Privy, Privy will generate the Ed25519 keypair and predetermine the address of the wallet contract, assuming that the wallet uses WalletContractV4 with a workchain of 0. Privy will not deploy the contract itself; that is the responsibility of the developer. If you’d like to deploy a different wallet contract with the same keypair, the address will be different, but the request to Privy’s API will remain the same.

Starknet

On Starknet, all wallets are smart contract accounts. The wallet address is the contract address, and therefore is derived from account-specific data—namely, the account class hash, the constructor data, and the public key returned from the Privy API. The address returned from the Privy API assumes the use of Ready’s v0.5.0 account class hash and the constructor call data, as shown below in the example. After creating a starknet wallet with Privy, STRK tokens must be sent to the address for the wallet. Then, the developer must deploy the account. If you wish to use a different account contract than Ready 0.5.0, we suggest maintaining the address-to-Privy-wallet mapping yourself at this time and ignoring the address returned from the Privy API.