Earn 12.92% APY staking with Solana Compass + help grow Solana's ecosystem

Stake natively or with our LST compassSOL to earn a market leading APY

Jupiter Brings Readable Ledger Signing to Limit Orders and DCA With Anza's

Solana ๐Ÿงญ Compass By Solana ๐Ÿงญ Compass

Jupiter now supports Anza's off-chain message signing standard v1 with

Jupiter Brings Readable Ledger Signing to Limit Orders and DCA With Anza's
A black hardware wallet showing a document-with-checkmark icon on its screen rests on a leather notebook over an antique map, beside a brass compass and sextant, with Jupiter, Anza, Ledger and Solana names on books to the right.

Jupiter JUP$0.331+0.5% has switched on support for Anza's version 1 off-chain message signing standard for Ledger hardware wallets, so Ledger owners placing limit orders and DCA (dollar-cost averaging) orders through Jupiter Wallet can read the message on the device screen before approving it. "Hardware wallets finally sign messages you can read," Jupiter wrote when it announced the launch on 30 September 2026, adding that it is "the first to support" the standard, for limit orders and DCA "in the Jupiter Wallet and on jup.ag", and that it is "live now with @Ledger via Jupiter Wallet."

Keep up to date with the Solana eco
Follow us on Google News

The standard itself is not new. Anza announced it as sRFC 38 in December 2025. What changed on 30 September is that a Solana app is now using it with Ledger in production. The "first" label is Jupiter's own claim; we found nothing contradicting it. Anza replied to the announcement within four minutes: "cheers to signing legibly!!"

Why Ledger users were blind signing Solana off-chain messages

Blind signing means approving something on a hardware wallet without seeing what it says, trusting the app that sent it. Under the original version 0 of Solana's off-chain message format, that was the only option for many messages. Anza's CLI documentation for version 0 lists UTF-8 messages as "blind sign only" on hardware wallets, and says a Ledger needs the "Allow blind sign" setting switched on, with "only the hash of the message" shown on screen. A hash is a short fingerprint of the data, so the user sees a string of characters instead of the order they are authorizing.

Anza's December 2025 thread introducing sRFC 38 put the cause in one line: version 0 "had a message format field that tried to predict what hardware wallets could render. That assumption broke across devices."

Jupiter's limit orders and DCA orders involve the wallet signing one of these off-chain messages, and Jupiter says that step now uses the new standard. Jupiter's post did not detail what the Ledger screen shows for each order type.

How Anza's off-chain message signing v1 (sRFC 38) works

An off-chain message is data a wallet signs to prove ownership or approve something without sending a transaction to the network. Version 1 strips the format down. According to Anza's specification, it drops three version 0 fields: the application domain, the message format flag and the length prefix. The message body is plain UTF-8 text with no built-in size cap, replacing version 0's 65,535-byte ceiling.

Every version 1 message still starts with a fixed 16-byte signing-domain prefix that marks it as an off-chain message. Signers must be unique and sorted in byte order, so the same message always produces the same bytes to sign regardless of which app builds it. The spec is explicit that whether a message can be displayed is up to the device: "Hardware-wallet signability and clear-signability are properties of the signing device, not of the message format." Version 0 remains supported for backwards compatibility.

On the Ledger side, the Solana signer documentation for Ledger's developer kit lists version 1 as the simplified sRFC 38 header and states that it "Requires Solana device app version 1.14+." If a device rejects the version 1 header, the kit falls back to version 0 and then to a legacy format, so a Ledger running an older Solana app does not get the version 1 message.

Jupiter Wallet adoption and the Solana wallet standard timeline

About nine months separate the standard's announcement from Jupiter's launch. Anza's December 2025 thread said "the spec is ready" and called on wallet providers to implement version 1. The solana:signOffchainMessage feature in Anza's wallet standard, the shared interface Solana apps use to talk to wallets, was merged on 17 June 2026 with support for version 1 only.

Jupiter's Ledger support runs through Jupiter Wallet, and it is the wallet's second upgrade in a week: on 28 September Jupiter added Solana Transaction V1 support to jup.ag swaps and Jupiter Wallet.

Solana Compass data puts Jupiter's reach in context: between about 192,000 and 226,000 wallets a day signed transactions with Jupiter's main swap-routing program from 23 to 29 September 2026.

The open question is how quickly other Solana wallets and apps follow. Jupiter's post names no other wallet or app on the standard yet, and a readable prompt protects only the users whose app and wallet both support it. For now, Jupiter's limit order and DCA users on Ledger are the first to get it.

Solana ๐Ÿงญ Compass
Solana ๐Ÿงญ Compass
@SolanaCompass

Solana Compass is an independent Solana analytics and staking platform, operating a validator on Solana mainnet since September 2021. Its network statistics and...


Comments

Please login to leave a comment.

Related tokens Open token โ†’

Solana tokens

Solana Token Markets

Explore all tokens โ†’