Skip to main content
In a nutshell
The Blockradar Signing API lets you cryptographically sign plain text messages and structured data (typed data) using your wallet’s private keys. Signatures prove wallet ownership to third-party services without moving funds or paying network fees (gas).

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, and Solana.

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.

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

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

Request Parameters

Message Signing Example

EVM Response

Tron / Solana Response

For Tron and Solana, the signedTransaction 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.
Typed data signing is only available for EVM-compatible blockchains (Ethereum, Polygon, BSC, Base, Arbitrum, Optimism, Celo). Tron and Solana do not support EIP-712.

Supported Standards

Request Parameters

EIP-2612 Permit Example

Typed Data Response

Domain Object Fields

Chain ID validation
The chainId in your domain object must match the chain ID of the wallet’s blockchain network. If they don’t match, the API returns a 400 Chain ID mismatch error.

Child Address Signing

Sign messages or typed data using a specific child address instead of the master wallet:
Child address signing follows the same request and response format as master wallet signing. The only difference is the endpoint URL, which includes the addressId.

Webhook Events

Signing operations trigger a webhook with the transaction record:

Webhook Payload


Complete Flow Example

Here’s a full implementation for signing a message and submitting the signature to a third-party provider:

Error Responses

The walletId does not exist or does not belong to your business.
The addressId does not exist or is not associated with the specified wallet.
Typed data signing (EIP-712) is only available on EVM-compatible chains. Use message signing for Tron and Solana.
The chainId in your typed data domain object does not match the wallet’s blockchain network.
Internal round-trip verification failed. This indicates a system error — contact support.

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 chainId in 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 verifyingContract must be the contract that will verify the signature on-chain

API Reference

Master Wallet Endpoints

Child Address Endpoints