Wallets and signing

Wonder

1. Why does a Solana transaction carry an expiration date?
2. What exactly is being approved when a user signs a versioned transaction?
3. How can one transaction reference many more accounts than it lists in full?

Explore

1. Solana keys are ed25519 key pairs. Most wallets derive these from a BIP39 seed phrase using the derivation path m/44’/501’/0’/0’. This standard allows users to recover their entire identity across different compatible software, provided they retain the original twelve or twenty-four word mnemonic. The private key remains local; the public key serves on-chain as the account’s address.
2. A transaction lists specific instructions and the accounts those instructions touch. Crucially, it includes a recent blockhash. This hash acts as an expiration mechanism: if the transaction is not processed within about 150 blocks, roughly 60 to 90 seconds, the blockhash becomes stale and the network rejects the transaction. Durable nonces allow users to sign transactions that remain valid for longer periods by using a value stored in a special nonce account in place of a recent blockhash.
3. Signing approves every instruction contained in the transaction. A malicious payload can transfer token accounts or change their authority settings without explicit user awareness of those specific sub-instructions. Wallets like Phantom, Solflare, and Backpack simulate these transactions to provide human-readable previews. However, users can still approve harmful instructions through ‘blind signing,’ where the raw data is accepted without verification of its intent.
4. Versioned transactions introduce address lookup tables, allowing a single transaction to reference many accounts by index rather than listing every full address. This optimization reduces the byte size of complex operations that touch numerous token mints or positions. The trade-off is complexity; understanding the resolved addresses requires decoding the table indices against the current state of the referenced account.
5. Hardware wallets provide an isolated environment for signing, interfacing via USB or QR codes to protect keys from host system malware. However, security depends on the integrity of the host application that constructs and displays the transaction data. If the host is compromised, it can present malicious details while the user signs what appears legitimate. Verifying all parameters directly on the hardware device’s screen mitigates this specific attack vector.
6. To inspect a transaction’s structure, open a Solana block explorer and select any recent transaction involving a multi-step operation. Expand the ‘Instructions’ section to view each individual program call. Then, examine the ‘Accounts’ tab to see which accounts were read from or written to by each instruction. Cross-reference these with the raw data to understand how the simulation preview maps to the actual state changes.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• Solana Documentation: Transactions and Durable Nonces
• Phantom Developer Documentation: Signing and Simulation
• BIP39: Mnemonic Code for Generating Deterministic Keys
• Solana Documentation: Versioned Transactions and Address Lookup Tables