Prepared by Aaron @ Jupiter

Contents

Summary

Solana has a published off-chain message signing format (off-chain-message-signing.md and sRFC 38) but no wallet-standard feature exposes it. Today, a dapp that wants a Solana off-chain-signed message has no good option:

1. Construct the preamble + body itself and call solana:signMessage with the raw bytes: the wallet shows the user opaque bytes (or a best-effort UTF-8 render of bytes that begin with \xffsolana offchain followed by binary preamble fields). The user has no meaningful way to review what they're signing, exactly the UX problem the off-chain message spec was designed to solve.
2. Use a wallet-specific RPC: doesn't interop across wallets.
3. Wait: which is what's happening today, despite kit shipping a complete encoder/decoder in @solana/offchain-messages.

This issue proposes adding solana:signOffchainMessage as a first-class wallet-standard feature.

Why Not Extend solana:signMessage?

solana:signMessage already has an established contract (raw bytes in, signed verbatim), and is in use in production for various applications. Overloading it with off-chain-message semantics would:

• Silently change signature output for every existing dapp that uses it. Same input bytes, different signed payload (now wrapped in the off-chain preamble), different signature, breaking existing integrations.
• Give dapps no easy way to detect whether they're getting raw signing or off-chain-wrapped signing. The output shape (signedMessage, signature) is identical and requires byte inspection to tell the difference.
• Conflate two distinct trust-boundary decisions. Raw signMessage displays bytes; off-chain message signing requires the wallet to validate the spec preamble (domain prefix, version, signer membership, format constraints) and render the body as user-meaningful text. These are different obligations on the wallet and shouldn't share a feature name.

Wallet Standard's mechanism for capability evolution is namespaced features. Adding solana:signOffchainMessage lets:

• Dapps detect support: wallet.features['solana:signOffchainMessage'].
• Wallets advertise which spec versions they handle: supportedMessageVersions.
• The two signing modes coexist with explicit, auditable opt-in on both sides.
• Existing signMessage consumers stay untouched.

This mirrors EVM precedent: personal_sign (EIP-191) and eth_signTypedData_v4 (EIP-712) are distinct RPCs from raw eth_sign, not overloads of it, for exactly the same reasons.