The risk a valid signature doesn’t cover

A familiar confirmation

Someone with a legitimate key reviews a transaction in a wallet or console, signs, and the network accepts it. Cryptographically, nothing failed. In the default path there is often no separate “request” step — the signed transaction is what runs.

And yet the operation should not have run that way — wrong destination, wrong person finishing alone, or an admin change that needed a second check and a wait.

Nothing here is a cryptographic failure. Every check that ran, passed. The problem is that the checks that ran weren’t the ones that mattered.

That pattern shows up in payments, in role and recovery changes, and when a script or agent submits a call outside the job it was given. The surface changes; the gap is the same.

Organizations need a second answer before sensitive work executes — who may act, under what conditions, and with what record. That is where a governed request path comes in: the signature still proves the key; the account can still require roles, approved targets, waits or a second approval before the operation becomes executable.

What a signature actually proves

A digital signature is a precise thing. It proves that whoever holds a particular private key authorized a particular message, and that the message wasn’t altered afterwards.

That is a lot. It is the foundation that lets anyone verify authorization without trusting an intermediary. Protecting keys — in hardware, with multiple parties, with careful ceremonies — remains essential.

But a signature is silent on almost everything an organization cares about when an operation runs:

Is this person (or agent) supposed to be making this kind of call?
Is the target one we have approved — a recipient, a contract, a function?
Should this person be able to finish alone, or does the policy require a second person?
Has the review we require actually happened — for this exact operation?

A key can sign anything it is asked to sign. Whether it should is a different question, and the signature doesn’t answer it.

What an organization’s policy needs to prove

Most organizations already have answers to those questions. They live in a policy, an approval matrix, a list of trusted counterparties, or simply in how a team works.

On-chain, those answers have to become checks that something actually performs. A useful way to frame them:

Authority — who may request this kind of operation, and who may approve it.
Destination — where value may go and which contracts may be called — and where they may not.
Conditions — waiting periods or additional approvals for sensitive operations, and no extra friction for routine ones.
Evidence — a record that ties who asked and who approved to what actually ran.

None of these replace the signature. They sit next to it. The signature says who; the policy says whether.

Today that usually means roles, approved destinations, waits, and a record of the path — not a per-transfer spend cap. An allowlist answers where; it does not bound how much. Amount or spend limits need a custom policy or a future contract surface.

Where a valid signature isn’t enough

A few patterns come up again and again:

The wrong target. A correctly signed call to an address or contract that was swapped, mistyped or never approved — a payment destination, a token, or an integration. The signer did nothing wrong cryptographically; the target was never checked against anything. This is what an on-chain allowlist is for — when it is configured and enforced where the operation runs.

One person where two were intended. Someone finishes an operation that, by the organization’s own rules, should have needed a second person. The wallet had no idea proposer and approver were supposed to be different people.

A bypassed approval. Sign-off happened in chat for one version of a call; a slightly different version was signed and sent. The approval and the operation were never connected.

An ill-timed admin change. A permission, owner or recovery path is changed at the wrong moment — during an incident, or by someone who held the access for an old reason. Without a wait or a second role on that path, it can take effect as soon as the signature lands.

In each case, adding more signers can help, but it doesn’t on its own express which operations need which checks.

Where enforcement lives

The question that matters most is not whether a rule exists, but where it is enforced.

In the interface. A dashboard can warn about an unknown address or require a second click. That helps — until someone uses a different client, a script or a direct contract call. The rule lives in one piece of software.

In a backend. A service can check policy before it forwards a call. That is stronger, but the service now has to be trusted, kept running and kept correct, and anything that goes around it isn’t checked.

On-chain, where the operation runs. When the account or contract itself evaluates the operation — is this role allowed, is this target permitted, are the waiting period and approvals met — the rule applies whichever interface submitted it. The check and the operation live in the same place.

Moving checks on-chain is not a cure-all. Roles, allowlists and waits can condition operations when they are configured and enforced correctly. They do not guarantee that private-key compromise has no consequences, prevent every malicious action, bound transfer amounts by themselves, or substitute for secure key management, monitoring and operational controls.

What it changes is the default: a valid signature becomes necessary, not sufficient.

A practical checklist

Pick one operation your team relies on — a transfer, a role change, a recovery step, a privileged app call — and ask:

Who may request it, and who may approve it? Are those different people, or could one person do both?
What may it touch? Approved recipients, contracts or functions — and what happens to a call outside that list?
What makes it sensitive? A destination, a type of change, or a step that should never be solo? Do those cases need a second approval or a waiting period — and do routine cases stay fast?
Where is each of those rules enforced? In a UI, in a backend, or where the operation executes?
What does the record show afterwards? Can you trace who asked, who approved and what ran, without relying on screenshots?
What happens with a different client? If someone submits the same operation from a script, do the same checks apply?

If the honest answer to the fourth question is “in a document” or “in our heads,” that is the place to start.

Review one workflow

You don’t need to redesign everything at once. Take the operation where a mistake would hurt most, write down who should be able to do what, and test both the expected case and the one you hope never happens.

If you would like a second pair of eyes on that first workflow, talk to us.