The short answer: a signature can show that the required key approved specific transaction bytes. A successful sendTransaction response shows that an RPC service—the network endpoint your app asks to relay the transaction—received the signed transaction. Neither fact, by itself, proves that a requested SOL delegation is active or that rewards have started. The interface needs to observe the relevant on-chain state before it makes that stronger claim.
I. Product brief: a deliberately hypothetical flow
Imagine a teaching example called Fieldnote Wallet Desk, a web app with a “Stake SOL” action. It is not a real service, and no wallet, transaction or network is connected in this article. The user chooses an amount and validator, reviews the proposed action, and may reject the wallet request. The interface does not hold keys, sign on the user’s behalf or promise an immediate reward.
The product question is narrow: which words may the app show after each piece of evidence arrives? The answer depends on what the app actually observed, which account it queried, and whether the data is fresh enough to support the statement.
II. The Integration Contract Canvas
This version of the six-field canvas maps only this hypothetical flow. It is a thinking aid, not a customer contract, protocol specification or endpoint.
| Canvas field | Scenario entry | Boundary to keep visible |
|---|---|---|
| Who initiates | The user selects “Stake SOL” in the hypothetical web app. | A click is an intent to start; it is not a submitted transaction. |
| Who signs | The connected wallet reviews the transaction and may sign it. | The app never possesses or stores the user’s private key. |
| Who observes | The app’s network client can query a signature and the target stake account. | A response has a source, commitment level, timestamp and possible gaps. |
| What changes | Only a successfully processed instruction can change network state. | Delegation can move through activating and active states over epochs. |
| What can fail | The user can reject; signing can fail; submission can be delayed, rejected or expire; reads can be unavailable. | Do not turn “unknown” into “failed” or “complete”. |
| How to verify | Check transaction status, then read the intended stake account and its delegation state. | Use evidence for the exact account and action; show when a check is stale. |
III. Three receipts, three different claims
“Receipt” here means evidence available to the interface, not a single standardised receipt object. A robust flow stores enough context to associate each observation with the user’s action and to retry a check without repeating the transaction.
1. The wallet returned a signature
The wallet’s result can support “Signed by your wallet” if the app knows which transaction was signed and verifies the expected signer. It shows approval of particular message bytes, not that the network has received or executed them. If the wallet returns no result because the user closes it or the call times out, the app should not infer approval.
2. The RPC returned a transaction signature
Solana’s sendTransaction method relays the signed transaction and returns its first signature when the RPC accepts it. The official RPC description is explicit: this success does not guarantee the transaction was processed or confirmed. A useful next state is “Submitted — checking network status”, with the transaction signature available for inspection. The app should check status using the signature, decide what confirmation level it needs, and account for transactions that expire before processing.
3. A read shows the stake account state
After a suitable transaction status, fetch the transaction details and read the intended stake account. Confirm that the account and delegation match the action the user reviewed. Solana’s stake-account documentation describes an activating phase and an epoch-based warm-up; delegation does not become effective all at once. A confirmation of the transaction therefore cannot justify “earning has started”. Only a fresh observation that supports the exact wording may do so, and rewards still depend on later protocol state.
V. Native staking and liquid staking are different integration models
Native staking uses Solana stake accounts and their delegation lifecycle. Liquid staking adds a protocol layer that issues a token representing a position, with protocol-specific contracts, exchange mechanics, liquidity and other dependencies. The token’s market price and redemption route may differ from the native account’s status. An interface must name the actual model it integrates rather than present both as one “stake” button with identical consequences.
Native and liquid staking may look like the same action in a menu, but they work differently. Native staking uses a Solana stake account; liquid staking adds a protocol and a token whose terms depend on that provider. Check the actual product documentation before describing custody, liquidity or exit options.
This article does not rank validators, estimate yield or assess any specific liquid-staking protocol. Those claims require current product terms and primary protocol documentation.
VI. Copy review: replace promises with observable facts
The alternative wording below is intentionally tied to evidence. A product should adapt it to its own actual network client and account checks.
| Do not say | Safer alternative | Evidence needed |
|---|---|---|
| “Guaranteed profit starts now.” | “Your delegation is active.” | A fresh stake-account read shows active effective stake. Do not promise profit. |
| “You’re staking” immediately after signing. | “Your wallet signed the request. We have not checked the network yet.” | Wallet response, plus an explicit statement that network status is unknown. |
| “Stake complete” after sendTransaction returns. | “Transaction submitted. Confirmation is still pending.” | RPC acceptance and a subsequent transaction-status observation. |
| “The validator has your SOL.” | “The stake account is delegated to the selected validator.” | Verified stake-account delegation and matching validator vote account. |
| “Your funds are instantly withdrawable.” | “Deactivation can take time; check the current account state before withdrawing.” | Current delegation state, protocol rules and any product-specific exit path. |
Where data is stale, unavailable or inconsistent, say so. A timestamp and a “check again” action can be more useful than a green success badge.
VII. Empty states that explain what the app knows
“We can’t reach the network right now. Your last checked state was [time]. We haven’t confirmed this request.”
“You declined the signing request. No transaction was submitted by this flow.” Only say this if the wallet clearly returns a user-rejection result.
“The transaction has not reached the status we’re checking for yet. You can wait or open its signature.” Keep polling bounded and show when the last read occurred.
“We couldn’t read the stake account. Your transaction status and stake status are unverified.” Preserve the transaction signature if one exists.
A timeout does not prove failure. Avoid automatically resubmitting an action that may already have landed; first resolve the signature and account state. If the product cannot identify a transaction, say that the outcome is unknown and provide a safe support path only after a real contact channel exists.
VIII. A compact statement checklist
Before a status label ships, ask what data the interface has and whether the data is current, associated with the intended account, and strong enough for the sentence.
| UI statement | Data needed | Caution |
|---|---|---|
| “Request signed” | Wallet returned signature for the reviewed message. | Does not mean submission or execution. |
| “Submitted” | RPC returned transaction signature. | RPC acceptance is not confirmation. |
| “Confirmed” | Signature status at the selected commitment. | Does not prove delegation is active or rewards have begun. |
| “Delegation activating” | Fresh stake-account read shows activation in progress. | Timing varies by epoch and network state. |
| “Delegation active” | Fresh account read shows effective active delegation to the expected validator. | Do not imply guaranteed yield or a withdrawal timeline. |
| “Unable to verify” | Read failed, is stale, or does not match the expected account. | Keep the status unresolved; do not invent a successful transaction. |
The useful promise is not that an integration always succeeds. It is that the interface will distinguish what was asked, what was signed, what the network accepted and what the app has actually checked.
What can the interface safely say?
Choose the strongest evidence currently available. This example is explanatory only and has no wallet or network connection.
Sources and review date
Primary documentation reviewed on 26 October 2026. Protocol documentation can change; re-check before production use.
- Solana: Stake Accounts — authorities, account model, delegation and warm-up / cooldown.
- Solana RPC: sendTransaction — submission response does not guarantee processing or confirmation.
- Solana: Interacting with Solana — transaction-status checks and confirmation states.
- Solana: Signing in Production — browser-wallet signing and private-key boundaries.
- Anza: Wallet Adapter documentation — adapter APIs and wallet-signing integration surface.
- Marinade: Liquid staking — protocol-specific explanation of its liquid-staking token model; not a universal guarantee.
- Marinade: FAQ — protocol-specific native and liquid product distinctions.
All product names in the scenario are illustrative. No transaction was created or sent.