Signature
Four things that look alike and mean different things
What is it?
A signature is proof that an instruction comes from the holder of the key. The gesture that gives it is always the same: a window, a button, confirm.
What you permit by it is different every time. And because the window looks similar every time, you get used to confirming without reading. That is the costliest mistake in this whole field.
The four cases
| 01 · Connecting the wallet | A site may see which address you use and what sits publicly on it. Nothing is moved and nothing is permitted. Connecting alone never costs money. |
|---|---|
| 02 · Signing a message | You sign a text to prove you control the address - to log in, for instance. This also moves nothing, provided the text really is only a text. This is exactly where it pays to read what it says. |
| 03 · Granting an approval | The dangerous case. You permit a program to dispose of tokens in future - often unlimited in amount and unlimited in time. Nothing happens at the moment of approval. Something can happen at any time afterwards. |
| 04 · Sending a transaction | Now something actually moves. The amount is in the window, and once confirmed it is done. |
Why approval is the sore point
An approval works like a signature under a power of attorney - not like a payment.
Someone who lets a program dispose of their tokens has lost nothing at that moment. The balance is unchanged, it looks as though nothing happened. But the permission remains - weeks later, and even if you never visit the site again.
If it later turns out that the program has a flaw, or was built for this from the start, it can use the permission. The holder has nothing left to confirm. They have already agreed.
Where does a risk come from?
| Habit | Someone who has confirmed twenty times with nothing happening does not read the twenty-first time. |
|---|---|
| The display is not the content | What the interface shows need not be what is signed. If the interface is altered, the operation looks ordinary - and is not. |
| Approvals do not age | A permission once given usually does not expire by itself. It stays until it is expressly revoked. |
Why this matters for cover
Because the line between covered and not covered runs here - and it does so for almost every product.
Someone who loses money through a flaw in the protocol generally has the case cover exists for. Someone who granted an approval themselves that was then used often has an excluded case - because technically everything was permitted.
This distinction is in every wording, often under “exclusions”. It is the reason these four cases are set out here at such length.
Where this leads
-
The recipient of an approval is a program - and it can contain flaws.
-
What happens when that program has a flaw.