Basic · LESSON 02 OF 08
2. Wallets, keys, and safe signing
By the end, you can distinguish wallet connection, scoped message login, transaction signing, and submission, and review unsafe requests.
Read the workflow
The application sends a message or transaction request to the wallet. The learner first checks the domain, network, requested action, destination, program, and fee information available in the prompt. At the decision point, rejecting closes the prompt and produces no signature. Approving lets the wallet sign the exact message or transaction bytes shown; signing does not itself prove transaction submission or confirmation. Wallet connection is separate from a signed login challenge, and neither path proves legal identity.
- REQUEST
- REVIEW
- REJECT
- APPROVE
Read a text version: Choose a readable wallet sign-in format
The server creates and stores a one-time challenge naming the application, domain, wallet, action, and nonce. The application detects wallet features and versions. SIWS 1.1 can request a readable off-chain message; if SIWS is unavailable, the account may support direct off-chain message version one, with raw message signing as a clearly explained fallback. The server checks the expected challenge and wallet, verifies the exact signed content and signature, validates expiry, and consumes the nonce once before creating a session. Message-based sign-in does not submit a Solana transaction or pay a network fee, and a signature alone is not a session.
- Server creates a one-time, domain-bound challenge.
- Detect supported wallet signing format and version.
- Prefer signOffchainMessage for Sign In With Solana v1.
- Use OffchainMessage v1 or useOffchainMessage v1 only as the supported fallback.
- Server check exact signed content and consume nonce once.
FIELD NOTE 01
Addresses and secrets
A public address identifies an account and can be shared to receive assets. A private key authorizes signatures. A recovery phrase can recreate multiple keys. Neither a course, a certificate service, nor a support representative needs your recovery phrase. Password recovery for this academy concerns your academy login only.
FIELD NOTE 02
Connection is not a blank cheque
Connecting a wallet usually lets an application read the public address the wallet shares and may keep a wallet-connection session for later requests. That connection is not automatically an authenticated website login, proof of legal identity, or approval of a transaction. A wallet-based login needs a separate signed challenge that the server checks. Transaction or message signing is another explicit wallet action, and submission and chain confirmation happen later. A familiar website or connected address does not make an unexpected request safe.
FIELD NOTE 03
A rehearsal with no funds
Use a separate practice wallet. Inspect the requested action without approving it, then cancel. A certificate claim should describe a credential mint, its network, its destination, and fees. If it unexpectedly requests a token transfer, delegation, or secret phrase, stop and investigate.
FIELD NOTE 04
Distinguish connection, off-chain messages, and transactions
The Solana Wallet Standard exposes separate capabilities: `solana:signIn` (wallet-level), `solana:signOffchainMessage` (account-level), raw `solana:signMessage`, `solana:signTransaction`, and `solana:signAndSendTransaction`. Detect both the capability and supported version before requesting an operation; off-chain message v1 and raw message signing do not imply transaction signing or submission. Solana’s off-chain message v1 wraps UTF-8 text in a fixed domain that cannot be mistaken for a transaction and names required signers, so it offers a readable sign-in prompt where supported. Solana Kit can represent a connected read-only wallet whose signer is null; that account cannot authorize a transaction through the signer interface. A signed message proves that a key authorized particular bytes, but the application defines what those bytes mean. A transaction signature authorizes the exact transaction message, including its instructions and accounts. Never treat connection, off-chain or raw message signatures, transaction signing, and transaction submission as interchangeable evidence.
FIELD NOTE 05
Choose a readable sign-in format and verify it on the server
For wallet login, prefer Sign In With Solana (SIWS) whenever the wallet exposes `solana:signIn`. SIWS feature version 1.1.0 can request `useOffchainMessage: { messageVersion: 1 }`; detect the version before using that option. If SIWS is unavailable but the account supports `solana:signOffchainMessage` v1, sign a readable, server-issued challenge in that format. Otherwise use `solana:signMessage` to sign the exact challenge bytes. Do not make a no-op transaction the default sign-in path. Generate and store the challenge on the server; verify that the signed content matches the expected domain, wallet, action, and chain, validate any expiry, verify the exact signature, and consume the single-use nonce once. Reject expired or replayed responses. A valid message signature establishes control of a key for that challenge, not legal identity or transaction approval, and it does not create a server session until verification succeeds.
FIELD NOTE 06
Use scoped sign-in and verify it on the server
For wallet-based login, use Sign In With Solana (SIWS) when the wallet supports its signIn capability. A SIWS request can bind a readable statement to a domain, address, chain, one-time nonce, and time limits. Generate the challenge on the server, check that the returned signed message matches the expected domain, address, and chain, verify its signature on the server, and consume the nonce once; reject expired or replayed responses. Some wallets may not support SIWS, so feature-detect it and choose a clearly explained fallback. Even a valid sign-in signature proves control of a key for that scoped challenge, not a legal identity or approval of a blockchain transaction.
FIELD NOTE 07
Review the complete transaction before approving
Read the wallet’s network and action summary, then compare it with the course page. Identify the fee payer, destination or new asset owner, issuer or collection, and instructions the wallet can display. If a prompt is unreadable, requests unrelated token movement, or names an unexpected program, reject it and inspect the request through a trusted route. After approval, verify the resulting transaction on the same cluster; a wallet toast is not independent proof of final state. The academy must never ask learners to paste a seed phrase, private key, or wallet export into a lesson, support form, or mint endpoint.
FIELD NOTE 08
Handle a rejected or uncertain prompt without guessing
If you reject a wallet prompt, stop and confirm the application did not start another request. If you approved a transaction but the page times out, do not treat the timeout as proof that nothing happened. Keep the public signature and cluster, then check transaction status and resulting account state before starting another action. Treat an unresolved result as unknown and use a documented recovery path; never let an application silently reopen the signing prompt. Support may need a public address or transaction signature, but never a recovery phrase, private key, or wallet export.
FIELD NOTE 09
Practice recovery without exposing a real secret
Use a disposable practice wallet only when an exercise truly needs one, and keep meaningful assets elsewhere. Write down the wallet vendor’s official recovery route before you need it; never follow an unexpected direct message that claims to restore an account. A password reset for the academy restores the academy login, not the wallet. Losing a self-custody recovery method can mean losing access to assets, while a public address remains visible on chain. The course should make those two outcomes clear and should not claim that a non-transferable badge can be moved to a replacement wallet. Learners can complete every reading and exam without connecting a wallet; minting is a separate, voluntary action.
FIELD NOTE 10
Separate signing, submission, and fee outcomes
A transaction signature approves the serialized message; it does not prove that the transaction was submitted, executed, or committed. Once submitted, validators check signatures and blockhash lifetime, charge the fee payer, execute instructions, and commit state only if execution succeeds. A failed transaction rolls back instruction state changes but still incurs its fee. If a page times out after the wallet returns a signature, retain the signature and cluster, inspect status and resulting state, and resolve the first attempt before signing again. Before an optional credential mint, review the selected cluster, fee payer, destinations, instructions, and wallet-displayed cost. The learner may decline; a page calling a mint free does not change the wallet’s actual fee or storage preview.
MAKE THE CONNECTION
A detail worth keeping
Transactions are instructions, not friendly prose. Wallets may summarize them differently, and explorers make independent interpretations. When a preview cannot explain a requested authority change, treat that uncertainty as a reason to pause.
Work through an example
Separate the academy login from a browser wallet. A login lets you resume lessons; it never gives the site signing rights. The learner owns the wallet prompt and can close it without losing course progress.
Draw two outcomes after reviewing a fictional wallet request: rejecting closes it without a signature; approving signs only the exact message or transaction bytes presented. Then distinguish wallet connection, signed wallet login, transaction submission, and chain confirmation. Use no real wallet, address, or funds.
GUIDED PRACTICE · BASIC
Do the work, one step at a time
Use fictional addresses and disposable test data. Do not enter a recovery phrase or private key. Unless a lesson explicitly says “read-only Devnet,” use paper or a local test and do not connect to a public network.
- Read a fictional wallet connection and identify the public address it shares; do not treat it as a signed login.
- Review a fictional sign-in request for its domain, chain, action, nonce, and expiry.
- Trace the reject branch: close the prompt without a signature or network submission.
- Trace the approve branch: identify the exact message or transaction bytes being signed.
- Explain why signing, transaction submission, and cluster confirmation are separate evidence.
- Compare a fictional wallet connection, sign-in challenge, message signature, and transaction request; name the capability in each case.
- Review the cluster, fee payer, destination, instructions, and displayed cost for an optional test credential mint; reject unrelated actions.
- After a page timeout, keep the public signature and cluster, inspect the first result, and resolve uncertainty before retrying.
Before you move on, check your reasoning
- Label the secret, address, signature, and login in a simple diagram.
- Describe why a message signature also deserves review.
- Write a two-sentence response to a pretend recovery-phrase request.
OPEN SELF-CHECK · UNGRADED
Pause and test your reasoning
Practice 1 of 3
A site asks you to paste a recovery phrase to “verify” a wallet before a lesson. What should you do?
- Paste it only after checking the site uses HTTPS.
- Send one word at a time so the site cannot reconstruct it.
- Reject it; never enter a recovery phrase.
Reveal the answer and explanation
One best answer: Reject it; never enter a recovery phrase.
A recovery phrase can recreate wallet signing authority. HTTPS does not make disclosure safe, and neither wallet connection nor a signed message requires sharing the phrase with an application. Stop and use a trusted wallet interface.
Sources: Sign In With Solana ↗ · Solana Wallet Standard Extension ↗
Practice 2 of 3
A wallet exposes `solana:signOffchainMessage` version 1 but not `solana:signIn`. What does this feature let the site request, and what must happen before it creates a session?
- Request the server's off-chain challenge, verify its exact content and signer, and consume its nonce once before login.
- The connected address plus its advertised wallet feature already creates a login session, so challenge verification and a one-time nonce are unnecessary.
- The application can submit transaction instructions because an off-chain message signature also approves the connected wallet's on-chain actions.
Reveal the answer and explanation
One best answer: Request the server's off-chain challenge, verify its exact content and signer, and consume its nonce once before login.
Off-chain message signing authorizes message bytes, not a transaction or a session by itself. The server must verify the returned bytes and signature against its stored challenge and wallet, validate expiry, and consume the nonce once before creating the session.
Sources: Sign In With Solana ↗ · Solana Wallet Standard Extension ↗ · Sign Messages and Authenticate Users ↗
Practice 3 of 3
A wallet displays a transaction signature immediately after you approve it. What has not yet been proven?
- The fee is always refunded.
- Confirmation and successful execution still require checking.
- A signature alone guarantees finality.
Reveal the answer and explanation
One best answer: Confirmation and successful execution still require checking.
Signing produces authorization for particular message bytes. Submission, execution, and confirmation are separate events that require later cluster evidence. Treat each returned result as evidence about only its own stage.
Sources: Transactions ↗ · Partial Signing ↗
This practice is not scored, saved, or part of a certificate. Account-based lesson checkpoints and level exams remain separate.
Scored checkpoints and level exams are available online through a free account. They are not included in this pack.
Optional lab files
These files are included with the pack. Follow the safety and toolchain notes in the lesson before running a lab; a Devnet read requires an internet connection.
READ THE SOURCE
Go deeper in the official docs
Reviewed on 2026-10-03. Protocol documentation can change; check the linked page’s current version when you reconnect.