Permit Frontrunning Remediation

Overview

Related Detector: Permit Frontrunning

A function that calls permit() and then acts on the resulting allowance can be griefed: an attacker copies the signed permit from the mempool and submits it first. The victim’s transaction then reverts inside permit() because the nonce is already consumed, blocking the intended operation even though the signature was valid. The remediation is to treat an already-applied permit as success, not failure.

Recommended Fix

Before (Vulnerable)

function depositWithPermit(uint256 amount, uint256 deadline, uint8 v, bytes32 r, bytes32 s) external {
    // If someone front-runs the permit, this reverts on the consumed nonce
    // and the whole deposit fails.
    token.permit(msg.sender, address(this), amount, deadline, v, r, s);
    token.transferFrom(msg.sender, address(this), amount);
}

After (Fixed — tolerate an already-set allowance)

function depositWithPermit(uint256 amount, uint256 deadline, uint8 v, bytes32 r, bytes32 s) external {
    // If the permit was already applied (front-run or replayed), proceed as long as
    // the allowance is sufficient. Only revert if the allowance is genuinely missing.
    if (token.allowance(msg.sender, address(this)) < amount) {
        try token.permit(msg.sender, address(this), amount, deadline, v, r, s) {} catch {}
    }
    require(token.allowance(msg.sender, address(this)) >= amount, "Permit failed");
    token.transferFrom(msg.sender, address(this), amount);
}

The operation now succeeds whether the permit was applied by the victim’s own transaction or by a front-runner — the attacker gains nothing by racing it.

Common Mistakes

Wrapping permit in try/catch but then not re-checking the allowance, so a truly invalid signature slips through.
Assuming front-running requires a private mempool exploit; any public pending transaction carrying a signature can be copied.
Reusing a permit deadline far in the future, widening the window in which a stale signature can be replayed.