Signing versus sending: the two prompts your wallet shows you

A wallet holds a key, not coins. This article separates the two things that key can do — prove who you are, and move value — and shows exactly what an approval writes down, why it survives the swap, and what a signature can never do on its own.

BlazePhoenix Engineering · updated 2026-08-13 · 8 min · written from the deployed bytecode

By Mitra (@Sigmacrit) — anonymous developer of the BlazePhoenix protocol. The code is the résumé.

Abstract in 15 languages · resumo · resumen · 摘要 · 要旨 · ملخص

English — 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.

Português — Uma carteira guarda uma chave, não moedas: uma assinatura liga uma mensagem específica a um endereço específico e não move nada por si, mas uma permissão assinada pode mais tarde deixar outra pessoa correr o código que move. O artigo separa o pedido de assinar mensagem — livre de taxas de chain, não livre de consequências — do pedido de enviar transação, e nomeia os quatro campos que vale a pena ler sempre: chain, endereço do contrato, função, montante.

Español — Una cartera guarda una clave, no monedas: una firma liga un mensaje específico a una dirección específica y no mueve nada por sí sola, pero un permiso firmado puede después dejar que otro ejecute el código que sí mueve. El artículo separa el aviso de firmar mensaje — libre de comisiones de cadena, no libre de consecuencias — del aviso de enviar transacción, y nombra los cuatro campos que vale la pena leer siempre: cadena, dirección del contrato, función, importe.

Français — Un portefeuille détient une clé, pas des pièces : une signature lie un message précis à une adresse précise et ne déplace rien par elle-même, mais une permission signée peut plus tard laisser quelqu'un d'autre exécuter le code qui déplace. L'article sépare l'invite de signature de message — sans frais de chaîne, pas sans conséquence — de l'invite d'envoi de transaction, et nomme les quatre champs à lire chaque fois : chaîne, adresse du contrat, fonction, montant.

Deutsch — Eine Wallet hält einen Schlüssel, keine Münzen: Eine Signatur bindet eine bestimmte Nachricht an eine bestimmte Adresse und bewegt selbst nichts — doch eine signierte Erlaubnis kann später jemand anderen den Code ausführen lassen, der es tut. Der Artikel trennt den Nachricht-signieren-Prompt — frei von Chain-Gebühren, nicht frei von Folgen — vom Transaktion-senden-Prompt und nennt die vier Felder, die jedes Mal zu lesen sind: Chain, Contract-Adresse, Funktion, Betrag.

Русский — Кошелёк хранит ключ, а не монеты: подпись привязывает конкретное сообщение к конкретному адресу и сама ничего не двигает, но подписанное разрешение может позже позволить другому запустить код, который двигает. Статья разделяет запрос подписи сообщения — без сетевых комиссий, но не без последствий — и запрос отправки транзакции, и называет четыре поля, которые стоит читать каждый раз: цепь, адрес контракта, функция, сумма.

Türkçe — Cüzdan bir anahtar tutar, coin değil: imza belirli bir mesajı belirli bir adrese bağlar ve kendi başına hiçbir şey taşımaz; ama imzalı bir izin, taşıyan kodu sonradan başkasının çalıştırmasına imkân verebilir. Makale, mesaj-imzala istemini — zincir ücreti yok ama sonuçsuz değil — işlem-gönder isteminden ayırır ve her seferinde okunmaya değer dört alanı adlandırır: zincir, sözleşme adresi, fonksiyon, tutar.

العربية — المحفظة تحمل مفتاحاً لا نقوداً: التوقيع يربط رسالة محددة بعنوان محدد ولا يحرّك شيئاً بذاته، لكن إذناً موقّعاً قد يتيح لاحقاً لغيرك تشغيل الكود الذي يحرّك. يفصل المقال بين مطالبة توقيع الرسالة — بلا رسوم سلسلة، لكن ليست بلا عواقب — ومطالبة إرسال المعاملة، ويسمّي الحقول الأربعة الجديرة بالقراءة كل مرة: السلسلة، عنوان العقد، الدالة، المبلغ.

हिन्दी — वॉलेट कुंजी रखता है, सिक्के नहीं: हस्ताक्षर एक विशिष्ट संदेश को एक विशिष्ट पते से बाँधता है और खुद कुछ नहीं हिलाता, फिर भी हस्ताक्षरित अनुमति बाद में किसी और को वह कोड चलाने दे सकती है जो हिलाता है। लेख साइन-मैसेज प्रॉम्प्ट — चेन-शुल्क से मुक्त, परिणाम से नहीं — को सेंड-ट्रांज़ैक्शन प्रॉम्प्ट से अलग करता है, और हर बार पढ़ने-योग्य चार फ़ील्ड बताता है: चेन, कॉन्ट्रैक्ट पता, फ़ंक्शन, राशि।

日本語 — ウォレットが保持するのは鍵であって、コインではありません。署名は特定のメッセージを特定のアドレスに結びつけるだけで、それ自体は何も動かしません。しかし署名済みの許可は、後で他人に「動かすコード」を実行させることができます。本記事は、チェーン手数料は無料でも帰結は無料でないメッセージ署名のプロンプトと、トランザクション送信のプロンプトを切り分け、毎回読むべき四つの欄——チェーン、コントラクトアドレス、関数、金額——を挙げます。

中文 — 钱包持有的是密钥，不是币：签名把一条特定消息绑定到一个特定地址，本身移动不了任何东西——但一份签名的许可可以让别人日后运行真正移动资产的代码。文章把签名消息提示（不收链上费用，却并非没有后果）与发送交易提示区分开，并点名每次都值得读的四个字段：链、合约地址、函数、金额。

한국어 — 지갑이 쥐고 있는 것은 키이지 코인이 아닙니다. 서명은 특정 메시지를 특정 주소에 묶을 뿐 스스로는 아무것도 옮기지 못합니다 — 그러나 서명된 허가는 나중에 다른 사람이 옮기는 코드를 실행하게 할 수 있습니다. 이 글은 체인 수수료는 없지만 결과까지 없는 것은 아닌 메시지 서명 프롬프트와 트랜잭션 전송 프롬프트를 구분하고, 매번 읽을 가치가 있는 네 필드 — 체인, 컨트랙트 주소, 함수, 금액 — 를 짚습니다.

Bahasa Indonesia — Dompet memegang kunci, bukan koin: tanda tangan mengikat pesan tertentu ke alamat tertentu dan tak bisa memindahkan apa pun sendirian, namun izin yang ditandatangani bisa kelak membiarkan orang lain menjalankan kode yang memindahkan. Artikel ini memisahkan prompt tanda-tangani-pesan — bebas biaya chain, tidak bebas konsekuensi — dari prompt kirim-transaksi, dan menyebut empat bidang yang layak dibaca setiap kali: chain, alamat kontrak, fungsi, jumlah.

বাংলা — ওয়ালেট ধরে রাখে একটি কি, কয়েন নয়: স্বাক্ষর একটি নির্দিষ্ট বার্তাকে একটি নির্দিষ্ট ঠিকানায় বাঁধে এবং নিজে কিছুই সরায় না, তবু স্বাক্ষরিত অনুমতি পরে অন্য কাউকে সেই কোড চালাতে দিতে পারে যা সরায়। লেখাটি সাইন-মেসেজ প্রম্পট — চেইন-ফি মুক্ত, পরিণাম-মুক্ত নয় — আর সেন্ড-ট্রানজ্যাকশন প্রম্পট আলাদা করে, এবং প্রতিবার পড়ার মতো চারটি ক্ষেত্র বলে: চেইন, কন্ট্রাক্ট ঠিকানা, ফাংশন, পরিমাণ।

Filipino — Ang wallet ay may hawak na susi, hindi barya: ang lagda ay nagbubuklod ng tiyak na mensahe sa tiyak na address at walang maigagalaw nang mag-isa, ngunit ang pinirmahang pahintulot ay maaaring magpahintulot kalaunan sa iba na patakbuhin ang code na gumagalaw. Pinaghihiwalay ng artikulo ang sign-message prompt — walang bayad sa chain, ngunit hindi walang kahihinatnan — sa send-transaction prompt, at pinangangalanan ang apat na field na dapat basahin tuwina: chain, address ng kontrata, function, halaga.

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.

Do not trust this page — reproduce it

Every claim above is checkable against the chain. Start here:

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.
Cite this article

Licensed CC BY 4.0 — quote, translate and reuse freely, including commercially, with attribution and a link. Copy a ready-made citation:

BlazePhoenix (2026). Signing versus sending: the two prompts your wallet shows you. BlazePhoenix Engineering. https://blazephoenix.xyz/learn/signing-vs-sending
@misc{blazephoenix_signing_vs_sending,
  title  = {Signing versus sending: the two prompts your wallet shows you},
  author = {BlazePhoenix},
  year   = {2026},
  url    = {https://blazephoenix.xyz/learn/signing-vs-sending},
  note   = {Accessed: reproduce the claim with the command above}
}

Writing an answer, a wiki entry or a paper? The claim above is reproducible against the chain before you quote it — which is the only sound basis for citing a technical source at all.

Contracts are verified on every chain we deploy to — addresses in the protocol manifest. Deeper formal treatment: the whitepaper (PDF).

Share this article · join the discussion

Share on X ↗Telegram ↗WhatsApp ↗Farcaster ↗💬 Discuss on Telegram

Related engineering