Idempotency as a First-Class Primitive

In traditional web systems, idempotency is a convenience.
In crypto systems, it is survival.
When a client retries an HTTP request, the worst case is often a duplicated record.
When a client retries a blockchain transaction, the worst case is a duplicated broadcast.
Double spend.
Duplicate payment.
Broken accounting.
Blockchains are asynchronous systems.
Applications are synchronous expectations.
That mismatch creates danger.
A user clicks “Pay.”
The network times out.
The client retries.
Did the first transaction broadcast?
Did the node accept it?
Did it propagate?
Without structure, the application cannot know.
Idempotency changes the equation.
An idempotent transaction request is not just a call.
It is a uniquely identified intent.
If the same request is sent twice,
the system does not execute twice.
It returns the original result.
No duplicate broadcast.
No duplicate state mutation.
No silent inconsistency.
Idempotency is not an afterthought.
It must be embedded at the protocol boundary.
When the API layer understands intent through a unique key,
retries become safe.
Automation becomes reliable.
Machine-to-machine payments become possible.
Network instability stops being catastrophic.
Blockchains do not guarantee idempotency.
Nodes do not enforce it.
Infrastructure must.
A wallet proxy elevates idempotency
from implementation detail
to first-class primitive.
Reliability is not achieved by trusting the network.
It is achieved by designing around its uncertainty.