Solana Message Verifier — vérificateur de messages Solana

One curve, several framings

Solana accounts are Ed25519 keys: the address is the 32-byte public key in base58, and a signature is the 64-byte EdDSA signature of RFC 8032. Unlike Ethereum, Solana has no single rule for what a signed message looks like before it is signed, so the same text can produce several different signatures depending on the software. A signature that "does not verify" is very often a correct signature over a different framing of the message. The verifier therefore builds every framing it knows from your message and reports which one the signature covers.

What a wallet actually signs

• Raw bytes — the wallet-adapter signMessage method of Phantom, Solflare, Backpack and other wallets signs the message bytes exactly as the dapp passed them. This is by far the most common case, and the reason a message must be pasted character for character: one extra space or line break is a different message.
• Off-chain message v0, CLI layout — solana sign-offchain-message (the agave CLI) prepends the signing domain \xffsolana offchain, the version 0, a format byte and the length, so that a signed message can never be mistaken for a transaction.
• Off-chain message v0 with an application domain — the layout of the original off-chain message proposal adds a 32-byte application domain and the list of signers. The domain is not in the message text, so the verifier needs it from you to build this framing.
• Off-chain message v1 — the current proposal drops the application domain and the length, and lists the signers sorted and unique, so the same message always has the same bytes.

Versions 0 define three formats — restricted printable ASCII and UTF-8 up to 1,232 bytes (what a Ledger can display), and extended UTF-8 — which the verifier picks the way signers do. A serialized off-chain message pasted on its own (hex or base64, starting with the signing domain) is verified as raw bytes and checked against its own rules: version, format, length, signer order.

Signed envelopes

An off-chain message signed by several parties travels as an envelope: the number of signatures, the signatures, then the message. The verifier parses the message strictly, pairs each listed signer with its signature in order and reports each as valid, invalid or missing (an all-zero placeholder). The envelope is fully signed only when every required signer has a valid signature and the message conforms to its format.

Sign-In With Solana

Sign-In With Solana (the solana:signIn feature of the wallet standard) is the Solana counterpart of Sign-In With Ethereum: the wallet signs a human-readable text that starts with <domain> wants you to sign in with your Solana account: and carries the account, an optional statement, the URI, version, chain, nonce and timestamps. The verifier reads those fields and warns when the account in the text is not the key that signed. The check that matters most is yours to make: the domain must be the site you are on, because a phishing page can ask you to sign a sign-in message for another site — that is the phishing resistance the format is meant to provide.

Keys, keypairs and encodings

Public keys are accepted in base58 (the usual address form) or as 64 hex digits; signatures in base58, base64 or hex. Messages can be given as text or as hex, base64 or base58 bytes. Verification uses @noble/curves with RFC 8032's strict rules (no ZIP-215 leniency), and the RFC 8032 test vectors are among the examples.

A Solana keypair — the 64-byte file solana-keygen writes, or the base58 string wallets export — contains the private key in its first half. It looks like a signature, so the verifier checks whether the second half is the public key of the first and refuses it before anything is processed. Never paste a keypair into any website.

What runs locally

Everything: framing, parsing and every signature check run in your browser, and the page sends nothing anywhere. Share links carry the public key, message and signature in the URL fragment, which never reaches a server. For Ethereum messages use the Ethereum signature verifier or the SIWE verifier; for Nostr events, which are signed with Schnorr signatures over secp256k1 instead, the Nostr event verifier.