# Signing versus sending: the two prompts your wallet shows you

> Canonical: https://blazephoenix.xyz/learn/signing-vs-sending
> License: CC BY 4.0 (attribution + link) · © 2026 BlazePhoenix
> Updated: 2026-08-13

A wallet holds a key, not coins: a signature binds a specific message to a specific address and can move nothing by itself, yet a signed permission can later let someone else run the code that does. The article separates the sign-message prompt — free of chain fees, not free of consequence — from the send-transaction prompt, and names the four fields worth reading every time: chain, contract address, function, amount.

Start with something you can picture. Somewhere on a chain there is a list. Each row says an address and a number: this address holds this many tokens. That list lives inside the token contract, and it is public — anyone can read your row.

Your wallet does not hold your tokens. It holds a key: a very large secret number, from which your address is calculated. The list has your address on it, and only someone who knows the key can produce the proof needed to change your row. That is the whole arrangement.

The analogy people reach for is a bank card, and it breaks in the place that matters. A bank card is a claim on a bank that decides whether to honour it. Nobody decides here. If a valid proof arrives, the row changes; if your key is lost, nobody can restore your row, because there is no one whose job that is.

## What a signature actually is

A signature is a number computed from two inputs: your secret key, and the exact message being signed. Change one character of the message and the signature changes completely. Anyone can take the message, the signature and your address, and check that the three fit together — without ever learning your key. That check is what "proves it came from you" means.

So a signature does exactly one thing: it binds a specific message to a specific address. It does not move anything by itself. Tokens move only when a transaction runs code inside the token contract that rewrites two rows of that list.

Hold on to that sentence, because the rest of this article is about the gap it leaves open. A signature cannot move your tokens. It can, however, be the permission that lets somebody else run the code that does.

## The first prompt: sign this message

Some prompts ask you to sign text or structured data. No transaction is broadcast, nothing is written to the chain, and no chain fee is charged. Logging into a site by signing a random phrase is the honest version of this: the site checks the signature, learns you control the address, and that is all it gets.

Now the dishonest version. Because a signature binds any message, a site can ask you to sign a message that a contract will later accept as an instruction — for example, a signed permission for some address to spend your tokens, which the recipient submits in their own transaction, at their leisure, paying their own chain fee.

The lesson is precise, and it is the opposite of the usual advice. Signing is free of chain fees. It is not free of consequence. A prompt that costs nothing can still be the most expensive thing you do that day, and the fact that your wallet shows no amount does not mean no amount is involved.

## The second prompt: send this transaction

The other prompt asks you to sign a transaction: an instruction to run a specific function, on a specific contract, on a specific chain, with specific arguments. Once signed it is broadcast, and if it is included in a block, the code runs.

Four fields are worth reading every single time, and none of them require any technical skill to check. The chain: is it the chain you meant to be on? The contract address: is it the address you got from a source you trust, character for character? The function: is it the one you asked for? And the amount: is it the number you typed?

Name the limit here rather than later. Reading those four fields tells you what you are calling. It does not tell you what that code does. A correct-looking prompt pointed at a malicious contract looks exactly like a correct-looking prompt pointed at an honest one. That is why the address is the field that carries all the weight, and why the last article in this series is about checking addresses.

## The approval, in numbers

A token contract keeps a second list beside the balances. Each row of it says: this owner permits this spender to move up to this many tokens. That number is called an allowance, and it lives inside the token contract — not in your wallet, and not in the contract you are approving.

When you press Approve before a swap, you are writing one row of that second list. Nothing moves. Your balance is unchanged. You have written down a ceiling.

Work it through with real numbers. You hold 1,000 tokens and you approve a router for 1,000. The allowance row now reads 1,000. You then swap 100. The router calls the token contract to pull 100 from you, and two things change at once: your balance falls from 1,000 to 900, and the allowance falls from 1,000 to 900. Swap another 100 and both fall to 800. The allowance is spent down as it is used.

Now the case that surprises people. Many interfaces default to approving the largest number the token can represent, so that you never have to approve again. Most token implementations treat that maximum as "unlimited" and skip the subtraction, which means that after your swap the allowance still reads unlimited. You have granted a standing permission that outlives the trade, the session, and your interest in the protocol. It is not wrong to do this — it saves you a transaction every time — but it should be a decision, not a default you never saw.

## What the allowance can and cannot do

An allowance is a ceiling on one token, for one spender. Approving a router for token A gives it no access whatsoever to token B, to your native gas balance, or to anything else in your wallet. If a page tells you that connecting a wallet drains it, that is not how the list works: connecting shows a site your address, and nothing more.

What an allowance does grant is real, though. Within its ceiling, the spender can move those tokens at any time in the future, without asking you again. If the spender is a contract with a bug, or a contract that can be upgraded into a different contract later, the ceiling you wrote is the size of the exposure you accepted.

The practical response is to know that allowances can be read and rewritten. Any block explorer will show you the allowance a token contract holds for a given owner and spender, and setting an allowance back to zero is an ordinary transaction. The habit worth having is not "never approve" — you cannot trade without approving — it is "know which rows you have written".

## Where BZPX sits in all of this

One reason this article can be short is that the BZPX token is deliberately unremarkable. It is a standard ERC-20 with a fixed supply of 1,000,000,000 tokens: no fee taken on transfer, no rebasing that changes your balance while you sleep, and no hooks that run other code when you move it.

That matters for a beginner in a specific way. With a token that takes a fee on transfer, the amount that arrives is smaller than the amount sent, and every calculation you do by hand comes out wrong. With BZPX, if the list says 1,000 and you send 100, the receiving row goes up by exactly 100. The arithmetic in the rest of these articles is arithmetic you can trust to close.

And the fee the protocol itself charges on a swap is 28 basis points — 28 parts in 10,000, or 0.28% — written as a constant in the contract with no function anywhere that can change it. You will see that number derived and used in the next articles.

**Verify it yourself:** On any block explorer, open the token contract, choose the Read tab, and call allowance(owner, spender) with your address and the router address. The number it returns is the ceiling you granted. Call it again after a swap and compare.

Related: https://blazephoenix.xyz/learn/token-approvals-explained · https://blazephoenix.xyz/learn/what-is-a-crypto-wallet · https://blazephoenix.xyz/learn/what-is-a-seed-phrase · https://blazephoenix.xyz/learn/where-your-tokens-are-during-a-swap · https://blazephoenix.xyz/learn/check-it-yourself