Sigvex
EVMRemediation2 min read

Write After Write Remediation

How to resolve a dead storage write: remove the redundant assignment or fix the slot/logic it was meant to update.

evmlogic-error

Write After Write Remediation

Overview

Related Detector: Write After Write

A storage slot written twice in the same execution with no read in between makes the first write dead: it costs gas and is immediately overwritten. Sometimes that is merely wasteful; often it is a symptom of a logic error — the developer meant to update a different slot, or expected the first value to be used before the second assignment. The remediation is to determine intent, then either delete the redundant write or correct the target.

Before (Vulnerable / buggy)

function configure(uint256 a, uint256 b) external {
    limit = a;   // dead: overwritten below with no read in between
    limit = b;   // did the author mean `floor = a; limit = b;`?
}

After (Fixed — resolve the intent)

// If both values matter, write the intended distinct slots:
function configure(uint256 a, uint256 b) external {
    floor = a;
    limit = b;
}

// If only the second was intended, drop the redundant write entirely:
function setLimit(uint256 b) external {
    limit = b;
}

Because a dead write is usually a logic bug rather than only a gas issue, confirm which variable each value was meant for before deleting anything.

Common Mistakes

  • Deleting the first write to save gas when the real bug was a wrong target slot, silently keeping the incorrect behaviour.
  • Overwriting a value that a modifier or internal call was supposed to read between the two writes.
  • Assuming the optimizer makes it harmless — the redundant SSTORE is often still emitted, and the logic error remains regardless.

References