What the wallet holds, and what it never sends
A wallet holds a private key. The public key is derived from it on the secp256k1 curve, and the account address is derived from the public key by hashing — which is why an address is a destination rather than an identity you register anywhere. Nothing about account creation touches the network; an address that has never transacted is indistinguishable from one that does not exist.
The key never leaves. Signing is a local computation over a hash, and what crosses the network is the transaction plus a signature from which the signer's address can be recovered. This is the reason the ecosystem's whole security model reduces to key custody: there is no account recovery, because there is no account server.
What gets signed
The wallet assembles a transaction: destination, value, calldata, gas limit, fee parameters, the chain identifier, and the nonce. Since EIP-1559 the fee parameters are a maximum total fee per gas and a maximum priority fee — a tip to the block builder — with the protocol-set base fee taken from the difference and the remainder refunded, rather than a single flat gas price. The encoded transaction is hashed and the hash is signed.
Two of those fields are easy to omit in an answer and are exactly what an interviewer listens for. The chain identifier is covered by the signature, per EIP-155, so a transaction signed for one chain cannot be replayed on another chain that shares your address. And the nonce, which is where nearly all operational pain in this area comes from.
Nonces are a strict sequence, not a hint
Every account has a transaction count, and a transaction is only valid if its nonce equals that count exactly. Consequently transactions from one account execute in nonce order, no matter what order they were submitted in, and no matter what they pay.
account nonce on chain: 41
submitted: nonce 41 fee: low -> sits in mempool
nonce 42 fee: generous -> valid, but cannot execute before 41
nonce 43 fee: generous -> queued behind both
result: nothing from this account confirms until 41 does or is replaced.
That is the whole mechanism behind a stuck wallet, and it explains a support pattern people misdiagnose constantly: a user sends a second transaction with a higher fee to "get ahead" of the first, and simply queues a second transaction behind it. The fee market applies between accounts, not within one.
The two ways out are both replacements rather than cancellations. You re-sign the same nonce with a higher fee so a builder prefers it and it evicts the original, and if the original transaction is no longer wanted you re-sign that nonce as a zero-value transfer to yourself, which occupies the slot harmlessly. Clients will not accept a replacement unless the fee bump is meaningful rather than marginal, which is why a cancellation attempt at the same fee appears to do nothing. Nothing here is a guarantee: until the original is mined or dropped it may still confirm, so a cancellation is a race you are trying to win, not an operation that succeeds.
A gap is the other failure. If nonce 42 is broadcast and 41 never was — a common outcome when a signing service crashes between allocating a nonce and submitting — then 42 is valid but not executable, and nodes may drop it from the mempool entirely rather than hold it indefinitely. Backends that sign from a shared hot wallet therefore need nonce allocation to be a single serialised authority with durable state, not a per-process read of eth_getTransactionCount. Two workers reading the same count will sign two different transactions with the same nonce, and exactly one of them will exist afterwards.
Broadcasting is where you lose visibility
Submission hands the signed bytes to a node, which validates them cheaply, admits them to its mempool and gossips them to peers. From then on inclusion is someone else's decision. A transaction that has been accepted has an identifier but no outcome, and it can sit pending for as long as the fee is uncompetitive, be replaced, be dropped when a node reclaims mempool space, or be included in a block that a reorganisation later discards.
The consequence for anything you build is that the transaction hash is not a receipt. Confirmation means fetching the receipt, checking its status field for success rather than assuming it, and deciding how many blocks of depth — or on Ethereum, the finalised block tag — you require before you treat the effect as real. A receipt with status zero means the transaction executed, reverted, and still cost the sender gas, which is a state your accounting has to represent.
Signing a message is not authorising a transaction
The last distinction is the one that separates a candidate who has used a wallet from one who has built with it. A wallet can also sign arbitrary data, and such a signature moves nothing by itself: it proves the key holder assented to some bytes, and something else has to interpret them. That is how "sign in with your wallet" works and how gasless approvals work, where the user signs an authorisation and a relayer pays to submit it.
Because those bytes have no inherent meaning, presentation is the security problem. EIP-712 exists so a wallet can show the user a typed, named structure — a domain, a contract, an amount — rather than an opaque hash they cannot evaluate. The attacks in this area are almost all social: a signature request that looks like a login and is in fact an unlimited token approval. An answer that mentions this shows you understand that the user's confirmation dialogue is part of the threat model, not a UI detail.
Signing is local, ordering is per-account, and inclusion belongs to someone else. Every operational surprise in this flow comes from confusing which of those three you control.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).