Basic · LESSON 02 OF 06
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
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
A signature is scoped to a message
A wallet signature proves that a key approved particular bytes; it does not make the message safe or explain it in human language. A transaction signature authorizes its encoded transaction, while a message signature can authorize an application-specific statement. A trustworthy sign-in message should identify the application domain, the action, the intended wallet, a one-time nonce, and an expiry. A user should be able to reject it without losing course progress. Never copy a recovery phrase into a form, code sample, screenshot, support chat, or debugging log. For practice, inspect a fictional message and state exactly what it authorizes. Treat a signature with no readable purpose as an unresolved risk, not as routine account access.
FIELD NOTE 05
Distinguish connection, message signing, and transaction signing
The Solana Wallet Standard defines separate feature names for `solana:signIn`, `solana:signMessage`, `solana:signTransaction`, and `solana:signAndSendTransaction`. An application should detect the specific capability it needs and explain that action before calling the wallet; support for message signing does not imply support for transaction signing or submission. 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, message signing, transaction signing, and transaction submission as interchangeable evidence.
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.
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.
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
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.
- Reject the request; a lesson site does not need the recovery phrase to read a public address or request a wallet signature.
- Send one word at a time so the site cannot reconstruct it.
Reveal one best answer and its explanation
One best answer: Reject the request; a lesson site does not need the recovery phrase to read a public address or request a wallet signature.
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 ↗
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 online and require a free account. They are not included in this pack.
READ THE SOURCE
Go deeper in the official docs
Reviewed on 2026-09-28. Protocol documentation can change; check the linked page’s current version when you reconnect.