Signing messages
How to sign a message from a Ledger Enterprise Account without moving funds, which message standards each network uses, and how to prove control of an address for an audit.
Role: Operators.
Signing a message proves control of an address without moving anything. Counterparties, exchanges and applications use it to confirm that an address is yours.
A message signature is a Request, governed by its own Rule. An Account that can send cannot necessarily sign messages: an Administrator has to add a Message Signing Rule. See Creating and editing Accounts.
Message signing is available on Bitcoin Accounts and on Ethereum and EVM Accounts. The Messages tab appears on an Account when a Message Signing Rule on it lets you sign messages. The tab lists the signed messages, with their Date, Type, Message, signature and Status.
Signing
On the Account page, open the menu next to Send.
Select Sign message.
Check the Address. On a Bitcoin Account with Dynamic addresses, enter the address to sign with.
On an Ethereum or EVM Account, select the Message standard.
Enter the message, or paste the typed data.
Select Review.
Confirm the details on your Ledger device.
Like any Request, it then collects the approvals its Rule requires.
On Ethereum and EVM Accounts, and on Bitcoin Accounts with a Static address, the Address is the Account address and you cannot change it. When the Account has no signed message yet, the Messages tab also shows a Sign message button.
Message standards
EIP-191
Personal message (EIP-191)
Ethereum and EVM networks
EIP-712
Typed data (EIP-712)
Ethereum and EVM networks
BIP-137
BIP-137
Bitcoin and similar networks
Bitcoin Accounts always use BIP-137, so the form shows no Message standard choice.
EIP-191 and BIP-137 take plain text, or a hex string. A message made only of hex characters, with or without 0x, is signed as raw bytes, not as text. For example, "cafe" is signed as two bytes. Any other message is signed as UTF-8 text. The form does not show which reading it used. A hex string must have an even number of characters.
EIP-712 takes a JSON payload of typed data, in the Typed data (JSON) field. If you paste a valid EIP-712 payload into the message field, the standard changes to Typed data (EIP-712). The form checks that the JSON is valid and that it has the basic EIP-712 structure. A payload that fails the full check is rejected at signing. The Request details show the Domain, the Primary type and the Message fields separately, with Show raw JSON.
That structure is the point of EIP-712. The device can display the fields individually, rather than a single opaque string.
Proving control of an address
An auditor or a counterparty can ask you to prove that you control an address, for example in a proof-of-reserve audit. They send a message. You sign it with the address and return the signature.
The form signs the message exactly as you enter it, with its spaces and line breaks. Paste the message as you received it.
Sign the message from the address that the auditor names. See Signing.
When the Request is approved, open the Messages tab of the Account.
Select the signed message.
Copy the Signed address, the message and the signature.
Send them to the auditor, with the message standard.
The signature shows as Signature (Base64) for BIP-137, and as Signature (Hex) for EIP-191 and EIP-712. If an EIP-191 or BIP-137 message is made only of hex characters, tell the auditor that it was signed as raw bytes.
How many signatures an Account needs
Each signature covers one address.
Ethereum or EVM Account
One. Its token Accounts use the same address
Bitcoin Account with a Static address
One, with the static address
Bitcoin Account with Dynamic addresses
One for each address that holds funds
A Dynamic Bitcoin Account holds its funds on many addresses. The UTXOs tab of the Account shows the Address of each unspent output. Sign once for each different address in that list. Each signature is a separate Request, with its own approvals.
An API user can create the same Requests over the API. See the API documentation.
What can go wrong
Message can't be empty
No message was entered
Typed data can't be empty
No EIP-712 payload was entered
Hex string must have an even number of characters
A hex message is malformed
Message exceeds maximum length
The message is above the 32 KiB that the interface accepts, or the EIP-712 JSON is above 65,536 characters
Typed data must be a valid JSON document
The EIP-712 payload is not valid JSON
This JSON is not an EIP-712 typed data payload
The JSON is valid, but not in EIP-712 shape
No matching rule found
No Message Signing Rule covers you on this Account
Related
Last updated