In a nutshell
The Blockradar Signing API lets you cryptographically sign plain text messages, structured data (typed data), and raw transactions using your wallet’s private keys. Sign messages to prove wallet ownership. Sign transactions built externally (e.g., Jupiter swaps on Solana) without exposing private keys, and optionally broadcast them on-chain.
The Blockradar Signing API lets you cryptographically sign plain text messages, structured data (typed data), and raw transactions using your wallet’s private keys. Sign messages to prove wallet ownership. Sign transactions built externally (e.g., Jupiter swaps on Solana) without exposing private keys, and optionally broadcast them on-chain.
Prerequisites
Before using the Signing API, ensure you have:1
API Key
Get your API key from the Blockradar Dashboard. Navigate to Developers to generate one.
2
Wallet Created
Create a master wallet from the Blockradar Dashboard. Navigate to Wallets and create one for your target blockchain. You’ll need the
walletId for signing operations.3
Environment
Choose between Testnet (for development) or Mainnet (for production). Wallets are isolated per environment.
How It Works
The Signing API produces a cryptographic signature that proves you control a specific wallet address. The signed output can be verified by any third party without accessing your private keys.Message Signing
Sign plain text messages to prove wallet ownership. Works on all supported blockchains: EVM, Tron, Solana, and Stellar.
Typed Data Signing
Sign structured data following the EIP-712 standard. Used for gasless approvals (EIP-2612 Permit) and authorized transfers (EIP-3009). EVM-only.
Transaction Signing
Sign raw transactions built externally. Build a swap on Jupiter, a contract call via ethers.js, or a TronWeb transfer, then send the unsigned tx and get it signed without exposing private keys.
Transaction Broadcast
Sign and broadcast a raw transaction in one step. Blockradar signs the transaction and submits it on-chain via a reliable queue with automatic retries.
Common use cases
- Third-party provider registration: Prove you own an address when onboarding with services like Iron, Circle, or other DeFi protocols
- Gasless token approvals: Sign EIP-2612 Permit messages to authorize token spending without an on-chain transaction
- Authorized transfers: Sign EIP-3009 TransferWithAuthorization messages for delegated transfers
- Off-chain attestations: Create verifiable proofs of intent or agreement tied to a wallet address
- External swap execution: Build a Jupiter swap on Solana, sign it with Blockradar, and broadcast it on-chain
- Custom contract interactions: Build any transaction externally and have Blockradar sign and/or submit it
Master Wallet vs Child Address
The Signing API is available at two levels:Master Wallet
Sign using the master wallet’s keys. Ideal for treasury-level operations and provider integrations.
Child Address
Sign using a specific child address’s keys. Use when the third party requires a signature from a deposit address.
Endpoints
Message Signing
Sign a plain text message with your wallet’s private key. The API signs the message, verifies the signature matches the wallet address, and returns both the signature and a transaction record.Supported Blockchains
Stellar message signing follows SEP-53, the Stellar standard for signing arbitrary messages. The signed payload is
SHA-256("Stellar Signed Message:\n" + message), signed with the account’s Ed25519 key, and the signature is base64-encoded. To verify it, apply the same prefix and hash before checking the signature against the signer’s public key. The Stellar CLI stellar message command and the SEP-53 helpers in the Stellar SDK do this for you. A raw Ed25519 signature over the unprefixed message will not verify.Request Parameters
Message Signing Example
EVM Response
Tron / Solana / Stellar Response
For Tron, Solana, and Stellar, thesignedTransaction object contains only the signature field (no r, s, v components):
Response Fields
Typed Data Signing (EVM Only)
Sign structured data following the EIP-712 standard. This is used for gasless approvals, delegated transfers, and other on-chain authorization flows that require a structured signature.Supported Standards
Request Parameters
EIP-2612 Permit Example
Typed Data Response
Domain Object Fields
Child Address Signing
Sign messages, typed data, transactions, or broadcast using a specific child address instead of the master wallet. All four signing operations are available for child addresses:Webhook Events
Signing operations trigger a webhook with the transaction record:Webhook Payload (Message or Typed Data Signing)
Webhook Payload (Transaction Signing)
For transaction signing, thesignedTransaction field is a string (not an object). The format depends on the chain.
Webhook Payload (Broadcast Success)
After the broadcast queue confirms the transaction on chain, you receive this webhook. Thehash field is updated to the on chain transaction hash and confirmed changes to true.
Webhook Payload (Broadcast Failed)
If the broadcast fails permanently after all retry attempts, you receive this webhook. Thestatus is FAILED and confirmed remains false.
Transaction Signing
Sign a raw, unsigned transaction built externally. You build the transaction using any SDK (ethers.js, TronWeb, Solana web3.js, Jupiter API), then send the serialized unsigned transaction to Blockradar for signing and/or broadcasting, without needing to build or manage your own infrastructure or blockchain nodes.Supported Blockchains and Formats
Request Parameters
Transaction Signing Example (Solana + Jupiter)
Transaction Signing Example (EVM)
Sign-Only Response (EVM)
Sign-Only Response (Solana)
Sign-Only Response (Tron)
For transaction signing,
signedTransaction is a string, not an object. This is different from message signing where it returns an object with signature components like r, s, v.signedTransaction Format by Chain
hash Field by Chain
Transaction Broadcast
Sign and broadcast a raw transaction in one step. Blockradar signs the transaction, then submits it on-chain via a reliable queue with automatic retries. The API returns immediately withPENDING status. You’ll receive a signed.success or signed.failed webhook when the on-chain result is confirmed.
Stellar Soroban Transactions
The signing endpoints accept Stellar Soroban transactions — a Stellar Asset Contract transfer or a custom contract invocation — in addition to classic transactions. Pass the same base64 transaction envelope XDR format; Blockradar detects Soroban transactions automatically and submits them via Soroban RPC instead of Horizon. Two Stellar rules to follow:- Simulate and assemble before signing. A Soroban transaction must be simulated against Soroban RPC and assembled with the simulation results (resource footprint and fees) before it is signed. Submitting an unassembled transaction fails on-chain.
- Rebuild on stale sequence. If the wallet’s sequence number has moved by submission time, the API returns an error stating the transaction is stale (
tx_bad_seq) and must be rebuilt and re-signed. Build a fresh transaction with the current sequence number and try again.
JavaScript
Request
Same parameters as transaction signing:Broadcast Example
Broadcast Response (Solana Example, immediate)
Broadcast Lifecycle
The transaction goes through these states:Complete Flow Example
Here’s a full implementation for signing a message and submitting the signature to a third-party provider:Error Responses
Wallet Not Found
Wallet Not Found
walletId does not exist or does not belong to your business.Address Not Found
Address Not Found
addressId does not exist or is not associated with the specified wallet.Unsupported Blockchain (Typed Data)
Unsupported Blockchain (Typed Data)
Chain ID Mismatch
Chain ID Mismatch
chainId in your typed data domain object does not match the wallet’s blockchain network.Signature Verification Failed
Signature Verification Failed
Invalid Transaction Format (Solana)
Invalid Transaction Format (Solana)
transaction field is not valid base64, or the decoded bytes are not a valid Solana VersionedTransaction.Invalid Transaction Format (EVM/Tron)
Invalid Transaction Format (EVM/Tron)
transaction field is not valid JSON. EVM and Tron transactions must be JSON-stringified objects.Invalid Transaction Format (Stellar)
Invalid Transaction Format (Stellar)
transaction field is not a valid base64-encoded Stellar transaction envelope XDR. Build the transaction with @stellar/stellar-sdk and pass transaction.toXDR().Best Practices
Security
- Use references: Track signing operations with unique reference IDs for audit trails and idempotency
- Verify the message: Before signing, confirm the message content matches what the third-party service expects
- Limit message length: Messages are capped at 4,096 characters. Keep messages concise and specific
Integration
- No gas fees: Signing operations are off-chain and do not require native token balance
- Immediate response: Signatures are generated synchronously. No polling or webhook waiting required for the signature itself
- Listen for webhooks: Use webhooks to maintain an audit trail of all signing events
Typed Data
- Match chain IDs: The
chainIdin your domain must match the wallet’s network. Use sandbox (testnet) chain IDs for testing and production (mainnet) chain IDs for live operations - Check the contract: The
verifyingContractmust be the contract that will verify the signature on-chain
Transaction Signing
- Build the transaction with the correct sender: The unsigned transaction must use the wallet or child address public key as the fee payer (Solana) or sender (EVM/Tron). If the key does not match, signing will fail.
- Solana blockhashes expire quickly: Solana blockhashes are valid for about 60 to 90 seconds. Build the transaction and call the signing endpoint promptly. If using broadcast, the queue retries will not help once the blockhash expires.
- EVM nonce management: Set the nonce correctly. If the nonce is already used, the broadcast will fail. Query the nonce from the chain immediately before building the transaction.
- Tron expiration: Tron transactions have a 24 hour expiration window set during building. This gives plenty of time for signing and broadcast.
- Stellar sequence and time bounds: Build the transaction with the wallet’s current account sequence number and valid time bounds. A stale sequence (
tx_bad_seq) or expired time bounds cause submission to fail. Build and sign promptly, and set time bounds generously if you plan to broadcast later. - Stellar Soroban transactions: Simulate and assemble the transaction before submitting it for signing — an unassembled Soroban transaction fails on-chain. If a stale sequence error is returned, rebuild with a fresh sequence and re-submit. If a broadcast times out awaiting confirmation, reconcile using the returned transaction hash instead of rebuilding, to avoid a double spend.
- Sign only vs broadcast: Use
/signing/transactionwhen you want to broadcast the transaction yourself or through another service. Use/signing/broadcastwhen you want Blockradar to handle submission with automatic retries.

