Signez des messages, des données typées et des transactions brutes avec les clés de votre portefeuille
En bref
L’API de Signature Blockradar vous permet de signer cryptographiquement des messages texte, des données structurées (données typées) et des transactions brutes à l’aide des clés privées de votre portefeuille. Signez des messages pour prouver la propriété du portefeuille. Signez des transactions construites en externe (par ex., des swaps Jupiter sur Solana) sans exposer vos clés privées, et diffusez-les optionnellement sur la chaîne.
Créez un portefeuille principal depuis le Tableau de bord Blockradar. Accédez à Wallets et créez-en un pour la blockchain souhaitée. Vous aurez besoin du walletId pour les opérations de signature.
3
Environnement
Choisissez entre Testnet (pour le développement) ou Mainnet (pour la production). Les portefeuilles sont isolés par environnement.
L’API de Signature produit une signature cryptographique qui prouve que vous contrôlez une adresse de portefeuille spécifique. Le résultat signé peut être vérifié par n’importe quel tiers sans accéder à vos clés privées.
Signature de message
Signez des messages texte pour prouver la propriété du portefeuille. Fonctionne sur toutes les blockchains prises en charge : EVM, Tron et Solana.
Signature de données typées
Signez des données structurées selon le standard EIP-712. Utilisé pour les approbations sans gas (EIP-2612 Permit) et les transferts autorisés (EIP-3009). EVM uniquement.
Signature de transaction
Signez des transactions brutes construites en externe. Construisez un swap sur Jupiter, un appel de contrat via ethers.js ou un transfert TronWeb, puis envoyez la transaction non signée pour la faire signer sans exposer vos clés privées.
Broadcast de transaction
Signez et diffusez une transaction brute en une seule étape. Blockradar signe la transaction et la soumet sur la chaîne via une file d’attente fiable avec des tentatives automatiques.
Inscription auprès d’un fournisseur tiers : prouvez que vous possédez une adresse lors de l’intégration avec des services comme Iron, Circle ou d’autres protocoles DeFi
Approbations de tokens sans gas : signez des messages EIP-2612 Permit pour autoriser la dépense de tokens sans transaction on-chain
Transferts autorisés : signez des messages EIP-3009 TransferWithAuthorization pour des transferts délégués
Attestations hors chaîne : créez des preuves vérifiables d’intention ou d’accord liées à une adresse de portefeuille
Exécution de swaps externes : construisez un swap Jupiter sur Solana, signez-le avec Blockradar et diffusez-le sur la chaîne
Interactions personnalisées avec des contrats : construisez n’importe quelle transaction en externe et laissez Blockradar la signer et/ou la soumettre
Signez un message texte avec la clé privée de votre portefeuille. L’API signe le message, vérifie que la signature correspond à l’adresse du portefeuille et renvoie à la fois la signature et un enregistrement de transaction.
Signez des données structurées selon le standard EIP-712. Ceci est utilisé pour les approbations sans gas, les transferts délégués et d’autres flux d’autorisation on-chain nécessitant une signature structurée.
La signature de données typées est uniquement disponible pour les blockchains compatibles EVM (Ethereum, Polygon, BSC, Base, Arbitrum, Optimism, Celo). Tron et Solana ne prennent pas en charge EIP-712.
Le nom du domaine de signature (par ex., le nom du token ou de la dApp)
version
string
Oui
La version du domaine
chainId
number
Oui
L’identifiant de la chaîne. Doit correspondre au réseau blockchain du portefeuille.
verifyingContract
string
Oui
L’adresse du contrat qui vérifiera la signature
salt
string
Non
Sel de domaine optionnel pour EIP-712 v4
Validation du Chain ID
Le chainId dans votre objet domaine doit correspondre à l’identifiant de chaîne du réseau blockchain du portefeuille. S’ils ne correspondent pas, l’API renvoie une erreur 400 Chain ID mismatch.
Signez des messages, des données typées, des transactions ou effectuez un broadcast en utilisant une adresse enfant spécifique au lieu du portefeuille principal. Les quatre opérations de signature sont disponibles pour les adresses enfant :
curl --request POST \ --url https://api.blockradar.co/v1/wallets/{walletId}/addresses/{addressId}/signing/message \ --header 'Content-Type: application/json' \ --header 'x-api-key: <api-key>' \ --data '{ "message": "Verify ownership of deposit address for provider onboarding.", "reference": "address-verify-001" }'
La signature avec une adresse enfant suit le même format de requête et de réponse que la signature avec le portefeuille principal. La seule différence est l’URL du point de terminaison, qui inclut le addressId.
Les opérations de signature déclenchent un webhook avec l’enregistrement de transaction :
Événement
Description
signed.success
Signature complétée avec succès. Pour la signature de message, données typées ou transaction, cet événement est déclenché immédiatement. Pour le broadcast, il est déclenché après la confirmation sur la chaîne.
signed.failed
Le broadcast de la transaction a échoué après l’épuisement de toutes les tentatives. S’applique uniquement au endpoint /broadcast.
Après que la file de broadcast confirme la transaction sur la chaîne, vous recevez ce webhook. Le champ hash est mis à jour avec le hash de transaction on-chain et confirmed passe à true.
Signez une transaction brute non signée construite en externe. Vous construisez la transaction à l’aide de n’importe quel SDK (ethers.js, TronWeb, Solana web3.js, Jupiter API), puis vous envoyez la transaction non signée sérialisée à Blockradar. Blockradar la signe avec la clé privée du portefeuille et renvoie la transaction signée sans jamais exposer la clé à votre application.
Pour la signature de transaction, signedTransaction est une chaîne, et non un objet. Ceci diffère de la signature de message qui renvoie un objet avec les composants de signature comme r, s, v.
Signez et diffusez une transaction brute en une seule étape. Blockradar signe la transaction, puis la soumet sur la chaîne via une file d’attente fiable avec des tentatives automatiques. L’API renvoie immédiatement un statut PENDING. Vous recevrez un webhook signed.success ou signed.failed lorsque le résultat on-chain sera confirmé.
Le broadcast nécessite des fonds testnet/mainnet dans le portefeuille pour payer les frais de gas. La transaction doit être valide et non expirée (les blockhashes Solana expirent en environ 90 secondes).
Transaction signée, broadcast en file d’attente. Vous recevez ce statut dans la réponse HTTP.
SUCCESS
Transaction confirmée sur la chaîne. Le webhook signed.success est envoyé.
FAILED
Le broadcast a échoué après l’épuisement de toutes les tentatives. Le webhook signed.failed est envoyé.
La file de broadcast effectue jusqu’à 10 tentatives avec des intervalles de 5 minutes. Pour Solana, si le blockhash expire, les tentatives supplémentaires ne seront pas efficaces. Vous devrez reconstruire la transaction avec un blockhash récent.
{ "message": "Wallet not found", "statusCode": 404}
Le walletId n’existe pas ou n’appartient pas à votre entreprise.
Adresse non trouvée
{ "message": "Address not found", "statusCode": 404}
Le addressId n’existe pas ou n’est pas associé au portefeuille spécifié.
Blockchain non prise en charge (données typées)
{ "message": "Typed data signing is only supported for EVM blockchains", "statusCode": 400}
La signature de données typées (EIP-712) est uniquement disponible sur les chaînes compatibles EVM. Utilisez la signature de message pour Tron et Solana.
Incompatibilité du Chain ID
{ "message": "Chain ID mismatch", "statusCode": 400}
Le chainId dans votre objet domaine de données typées ne correspond pas au réseau blockchain du portefeuille.
Pas de frais de gas : les opérations de signature sont hors chaîne et ne nécessitent pas de solde en tokens natifs
Réponse immédiate : les signatures sont générées de manière synchrone. Aucun polling ou attente de webhook n’est nécessaire pour la signature elle-même
Écoutez les webhooks : utilisez les webhooks pour maintenir une piste d’audit de tous les événements de signature
Faites correspondre les Chain IDs : le chainId dans votre domaine doit correspondre au réseau du portefeuille. Utilisez les Chain IDs sandbox (testnet) pour les tests et les Chain IDs de production (mainnet) pour les opérations en direct
Vérifiez le contrat : le verifyingContract doit être le contrat qui vérifiera la signature on-chain
Construisez la transaction avec le bon expéditeur : la transaction non signée doit utiliser la clé publique du portefeuille ou de l’adresse enfant comme payeur de frais (Solana) ou expéditeur (EVM/Tron). Si la clé ne correspond pas, la signature échouera.
Les blockhashes Solana expirent rapidement : les blockhashes Solana sont valides pendant environ 60 à 90 secondes. Construisez la transaction et appelez le endpoint de signature rapidement. En cas de broadcast, les tentatives de la file d’attente ne seront pas efficaces une fois le blockhash expiré.
Gestion du nonce EVM : définissez le nonce correctement. Si le nonce est déjà utilisé, le broadcast échouera. Interrogez le nonce depuis la chaîne juste avant de construire la transaction.
Expiration Tron : les transactions Tron ont une fenêtre d’expiration de 24 heures définie lors de la construction. Cela laisse amplement le temps pour la signature et le broadcast.
Signature seule vs broadcast : utilisez /signing/transaction lorsque vous souhaitez diffuser la transaction vous-même ou via un autre service. Utilisez /signing/broadcast lorsque vous souhaitez que Blockradar gère la soumission avec des tentatives automatiques.