On this page
- A signed message is a proof of ownership. It is not sent to the network, so it cannot move funds and costs nothing.
- A signed transaction is a set of on-chain instructions. Read what it does before you approve, because it can move tokens.
- Fianto's wallet proof and portal sign-in are plain-text messages; payments, subscriptions, cancels and rent reclaims are transactions the wallet signs and Fianto sends.
What is the difference between signing a message and signing a transaction?
The difference is what happens to the signature afterwards. Both use the wallet's private key, the secret that only your wallet holds. A message signature is handed back to the website, which checks it against your public address to confirm you control that wallet, and that is the end of it. A transaction signature is attached to a transaction, a bundle of instructions such as "move 25 USDC from this account to that one", and the transaction is sent to Solana, where validators run it.
That is why only one of them costs anything. Phantom's developer documentation says: "Message signatures do not involve network fees and are a convenient way for apps to verify ownership of an address." A transaction that the network processes pays a fee in SOL, under $0.01 for the ones a Fianto customer signs.
How does the Wallet Standard name each signing request?
The Wallet Standard, the shared interface Solana wallets expose to websites, names each kind of signature as a separate feature. A site can only call the features a wallet lists. The descriptions below are quoted from the standard's feature definitions.
| Feature | What the standard says it does | Where Fianto uses it |
|---|---|---|
solana:signMessage | "Sign messages (arbitrary bytes) using the account's secret key." | Merchant wallet proof; customer portal sign-in |
solana:signTransaction | "Sign transactions using the account's secret key." | Checkout payments and subscriptions; portal Cancel, Reclaim rent and Re-authorise |
solana:signAndSendTransaction | "Sign transactions using the account's secret key and send them to the chain." | Never |
solana:signIn | "Sign In With Solana", based on Ethereum's EIP-4361 and CAIP-122; the site passes the fields and the wallet writes the message | Never: Fianto writes the sign-in text and the wallet signs it as a message |
Fianto asks wallets only to sign, and sends every transaction itself, because the server, unlike the page, still holds the signed transaction after the tab closes and can send it again until it lands. A wallet that can sign and send but not sign alone is refused at checkout with wallet_: "This wallet can only send payments itself, and we need it to sign the payment so that we can send it. Pay with a different Solana wallet." The other checkout errors are explained in why did my Solana payment fail.
What does a merchant sign to prove a receiving wallet?
A merchant proves a receiving wallet by signing a plain-text message during setup, not a transaction. Fianto's backend writes the text, the merchant's wallet signs it, and the backend checks the signature against the exact bytes it stored, never against text the browser sends back. This is the message, with the account's values in brackets:
fianto wants you to confirm this wallet receives payments for your account. Account: <your account email> Wallet: <the wallet address> Purpose: Onboarding Nonce: <32 random hex characters> Issued At: <time, ISO 8601> This is a message, not a transaction. Signing it costs nothing and moves nothing.
The nonce, a random value used once, stops an old signature from being replayed, and the message can be signed for five minutes after it is issued. The dashboard checks the Account and Wallet lines against the page before it opens your wallet. The same proof, with Purpose: Wallet change, is asked for when an approved merchant changes the receiving wallet, and a signature from the receiving wallet is one of the checks in the self-serve two-factor reset. The setup steps are on Set up your business in the docs.
What does a customer sign to open the subscription portal?
A customer signs in to the portal at fianto.xyz/my with a Sign In With Solana message, a standard text format for logging in with a wallet. Fianto writes it with this statement, word for word:
Sign in to fianto to see and manage your subscriptions. Signing in costs nothing and moves no funds.
The message also names the portal's domain, the wallet address, Solana mainnet, a nonce and an expiry five minutes after it is issued. The domain line is your check against a copy on a lookalike site: it should match the address bar. Some wallets check it too. Phantom's docs, describing its sign-in feature, say: "Phantom validates recognized Sign-In with Solana (SIWS) messages before displaying an approval prompt." A portal sign-in lasts up to one day.
Acme RPC
ProStops future payments. It stays active until the end of its current billing period.
Everything the portal changes is a transaction. Cancel, Reclaim rent and Re-authorise each ask your wallet to sign, Fianto sends it, and you pay the network fee. Cancelling runs to the end of the period you have paid for; the steps are in how to cancel a crypto subscription, and what the portal shows is on the customer portal page.
What does a customer sign to pay at checkout?
A customer paying at checkout signs one transaction that Fianto built, and its contents are short. For a one-off payment, it holds:
- Two compute-budget instructions, which set how much computation the transaction may use and the priority fee.
- A USDC transfer of the price from the customer's USDC account to the merchant's.
- A second USDC transfer of Fianto's fee to Fianto's treasury, only when the fee is above zero. There is no Fianto fee during the beta.
The customer's wallet pays the Solana fee and is the only signer. After signing, Fianto checks the signed transaction against what it built, down to every transfer's token, source, destination and amount, and refuses to send it if any of them differ. The checks are listed in crypto payment mistakes and how a signed checkout prevents them.
A subscription checkout is also one transaction, but it does more: it creates the subscription on chain with a cap per billing period and pays the first period. That approval is a delegation, permission for an approved party to collect within limits later, and it is why reading a subscription request matters more than reading a one-off payment. How the limits are enforced is in Solana token delegation explained.
One readable transaction per payment, sent by Fianto, checked before it leaves.
Read how Fianto stays non-custodialHow do you tell whether a signature request is safe?
A signature request is safe to approve when you know which site asked, what kind of signature it is, and what it does. If the wallet adds a warning, what wallet transaction warnings mean decodes it. A short routine before you press Approve:
- Check the site address in the browser bar, and the domain the wallet shows. A sign-in message for another domain is a red flag.
- Check the kind of request. Both of Fianto's messages are plain text that say what they are for. A message you cannot read tells you nothing about what you are agreeing to, so reject it unless you trust the site that asked.
- For a transaction, read the balance changes your wallet predicts. A payment should move the price, and the fee if there is one, and nothing else.
- Be wary of any transaction that changes who controls a token account or approves an unlimited amount. A Fianto one-off payment does neither.
- Reject when unsure. Rejecting signs nothing and sends nothing.
A message signature still has value to whoever receives it: a signed sign-in message can sign them in as you on the site it names. Sign messages only on sites you meant to visit, the same way you would type a password.