Verify Again After Signing

This article has three layers:

1. Layer 1: The Intuition: Opening a sent letter to check it again
2. Layer 2: Real-World Use: Databases, payment reconciliation, blockchain transactions
3. Layer 3: Principles and engineering key points: which fields to compare, which differences are acceptable, and what to do when an inconsistency is found

Layer 1: The Intuition

1.1 Opening a sent letter to check it again

You ask a secretary to mail an important letter for you. The secretary seals it and sends it off. How do you know they sent exactly what you wrote?

If you could retrieve the sent letter from the post office to take a look, you could confirm it. Blockchain provides exactly this capability: all transactions are public, and anyone can read them using the transaction hash.

1.2 Why checking the interface before signing is not enough

Verification before signing checks "what is displayed on the interface"; verification after signing checks "what is actually on-chain."

Layer 2: Real-World Use

• Databases: Performing a read-after-write after an important write operation to confirm that what was written is indeed what was intended, especially in systems with multiple replicas or eventual consistency.
• Payment Reconciliation: Banks and payment companies reconcile their books against clearinghouse records transaction by transaction every day, investigating discrepancies immediately. This is the financial industry's version of "verify after signing."
• Blockchain Wallets:
  • After a transaction is broadcast, retrieve the transaction from the chain using the transaction hash and compare it field-by-field;
  • Retrieve it using two independent nodes to prevent a single node from lying (see "Multi-source Cross-verification").
• Software Release: Re-download the artifact from the online server after release and compare the hashes (see "The Bybit Incident and Frontend Integrity").

Layer 3: Principles and Engineering

3.1 Which fields to compare

Note item 4: During an ERC-20 transfer, to is the token contract, and the actual recipient is hidden inside the calldata. Comparing only to will miss the most critical tampering.

3.2 Which differences are acceptable

Wallets allow users to modify gas fees, so it is normal for maxFeePerGas, maxPriorityFeePerGas, and gasLimit to be inconsistent. However, an upper limit should be set: if the gas fee is modified to several times the intended amount, it should be treated as an anomaly (it could be an attack to "drain the balance via exorbitant fees," or simply user error, both of which warrant a warning).

3.3 What to do when an inconsistency is found

An inconsistency means at least one link in the signing chain is untrustworthy. You must act decisively:

1. Immediately mark this intended transaction as an anomaly;
2. End the current session and require re-authentication;
3. Issue a high-priority alert through independent channels (email, in-app notification);
4. Record it in the audit log (see "Hash Chain Audit Logs").

At this point, the transaction has likely already been put on-chain and cannot be recalled. The value of "verify after signing" is not in recovering this specific transaction, but in:

• Detecting a compromised link immediately to prevent the next transaction;
• Providing clear evidence for investigation.

3.4 Tracking the subsequent status of a transaction

After a transaction is broadcast, several other scenarios may occur, all of which must be tracked:

"Replaced" is particularly alarming: if the user did not perform an acceleration or cancellation, and another transaction appears with the same nonce, it is almost certain that the private key has been leaked.

3.5 It is complementary to "verification before signing"

Both are indispensable.

Summary