eth: Update v1 contract. by JoeGruffins · Pull Request #3488 · decred/dcrdex

JoeGruffins · 2026-01-22T08:23:55Z

JoeGruffins · 2026-01-22T08:25:04Z

Current changes are straight from chatgpt. I took out the part where it "fixed" letting anyone refund. Still looking it over not tested yet. Will put comments back in.

Rethinking if maybe we do only want the initiator to refund.

JoeGruffins · 2026-01-23T08:08:52Z

Has been run through claude a few times.

JoeGruffins · 2026-01-23T09:34:06Z

Appears to be working.

martonp · 2026-01-23T19:07:02Z

+        (bool ok,) = payable(recipient).call{value: total - fees}("");
+        require(ok, "AA payout failed");


We have another vulnerability over here. When redeeming using account abstraction, the gas fee is paid to the entrypoint in validateUserOp, but the swap is marked as complete in redeemAA. validateUserOp should only pass if redeemAA will definitely pass, but we have two cases in which validateUserOp can pass but redeemAA will fail, causing some funds to be removed from the contract and sent to the entrypoint without the swap being marked as complete. This can then be run over and over, causing all the funds in the contract to be sent to the entrypoint.

Making the participant be a smart contract that fails when funds are transfered to it. We can mitigate this by just removing the require(ok, "AA payout failed"); line.

Providing a callGasLimit in the user op that is too low. We can fix this by checking the callGasLimit in validateUserOp.

What keeps validateUserOp from being called by the entrypoint multiple times anyway?

Apparently the protocol only allows it to be called once per user action... ok

Addressed in the last force push. https://github.com/decred/dcrdex/compare/730b0f9ef23df438c823e7b5729a450e56c09b19..78f845ef4f9e948d2149d9b1a88296e41cbaf989

It's still requiring the payment to succeed.. the last line should be removed.

Now fixed in the last rebase?

JoeGruffins · 2026-01-26T04:40:16Z

mmm. Wonder if that's it.

5 fixes by claude

● Summary of Fixed Attack Vectors

All five attacks exploit the same pattern: validateUserOp succeeds and pays prefund from the contract's pooled
funds, but redeemAA fails, leaving the swap unredeemed and repeatable.

Invalid Secret Attack

Missing check: validateUserOp verified the signature but not the secret.

Attack: Submit UserOp with valid signature but wrong secret.

validateUserOp → passes, pays prefund
redeemAA → fails with "bad secret"
Repeat to drain funds

Fix: Added VALIDATE_INVALID_SECRET check (line 402-404)

Token Type Mismatch Attack

Missing check: validateUserOp allowed any token, but redeemAA only supports ETH.

Attack: Use an ERC20 token swap for AA redemption.

validateUserOp → passes, pays prefund
redeemAA → fails with "ETH only"
Repeat to drain funds

Fix: Added VALIDATE_TOKEN_NOT_ETH check (line 420)

Insufficient Call Gas Attack

Missing check: No validation that callGasLimit was sufficient for redeemAA execution.

Attack: Submit UserOp with artificially low callGasLimit.

validateUserOp → passes, pays prefund
redeemAA → runs out of gas, reverts
Repeat to drain funds

Fix: Added VALIDATE_INSUFFICIENT_CALL_GAS check (lines 431-433)

Same-Block Attack

Missing check: validateUserOp checked blockNum == 0 but not blockNum < block.number.

Attack: Initiate swap and submit redemption UserOp in the same block.

validateUserOp → blockNum = N, N != 0, passes, pays prefund
redeemAA → blockNum < block.number = N < N = false, fails
Repeat to drain funds

Fix: Added blockNum >= block.number to the redeemability check (line 412)

Empty Batch Attack

Missing check: validateUserOp didn't require reds.length > 0.

Attack: Submit UserOp with empty redemptions array (edge case, requires missingAccountFunds = 0).

validateUserOp → might pass with zero-value edge cases
redeemAA → fails with "bad batch size"

Fix: Added VALIDATE_BAD_BATCH_SIZE check (line 393)

Root Cause

The fundamental issue was that validateUserOp and redeemAA had asymmetric validation logic. Any condition that
passes validation but fails execution allows repeated prefund drainage from the contract's pooled swap funds.

JoeGruffins · 2026-01-27T07:48:46Z

isRedeemed would have returned true after refunded https://github.com/decred/dcrdex/compare/78f845ef4f9e948d2149d9b1a88296e41cbaf989..5f102b003b978664543f47478938ca7a28c14509

JoeGruffins · 2026-01-27T07:51:36Z

Another interesting attack vector but would have to be the same user attacking themselves so maybe ok? or we can change:

self attack

C-02 Prepayment

The ERC-4337 Flow

In account abstraction, the EntryPoint processes UserOps in two phases:

Validation phase: All validateUserOp() calls run first
Execution phase: All actual calls (redeemAA()) run after

How Prepayments Work in This Contract

In validateUserOp (lines 416-422):
if (i == 0) {
participant = r.v.participant;
token = r.token;
if (token != address(0)) return VALIDATE_TOKEN_NOT_ETH;
redeemPrepayments[contractKey(r.token, r.v)] = missingAccountFunds; // ← stored by first swap's key
}

In redeemAA (lines 491-497):
bytes32 payKey = contractKey(redemptions[0].token, redemptions[0].v);
uint256 fees = redeemPrepayments[payKey]; // ← retrieved by first swap's key
delete redeemPrepayments[payKey];
(bool ok,) = payable(recipient).call{value: total - fees}("");

The Bug Scenario

Two UserOps in the same bundle, both with swap A as their first redemption:
┌─────────────────────┬──────────┬──────────┐
│ │ UserOp1 │ UserOp2 │
├─────────────────────┼──────────┼──────────┤
│ Redemptions │ [A, B] │ [A, C] │
├─────────────────────┼──────────┼──────────┤
│ missingAccountFunds │ 0.01 ETH │ 0.05 ETH │
└─────────────────────┴──────────┴──────────┘
What happens:

validateUserOp(UserOp1):
- Swap A exists and is unredeemed ✓
- Stores redeemPrepayments[keyA] = 0.01 ETH
- Pays 0.01 ETH to EntryPoint
- Returns success
validateUserOp(UserOp2):
- Swap A still exists and unredeemed (no execution yet!) ✓
- Overwrites redeemPrepayments[keyA] = 0.05 ETH
- Pays 0.05 ETH to EntryPoint
- Returns success
redeemAA(UserOp1) executes:
- Redeems A and B successfully
- Reads fees = redeemPrepayments[keyA] → gets 0.05 ETH (wrong!)
- Deletes the entry
- Pays recipient total - 0.05 ETH instead of total - 0.01 ETH
- Recipient loses 0.04 ETH
redeemAA(UserOp2) executes:
- Tries to redeem A → reverts "already redeemed"
- UserOp2's 0.05 ETH prefund is consumed by EntryPoint for gas

Impact Assessment

Who can trigger this?

Both UserOps must have the same participant for swap A (signature verification)
So it's the same person submitting both
Requires a bundler to include both conflicting UserOps

Exploitability: Low

An attacker would be attacking themselves
A malicious bundler could grief users, but bundlers are typically trusted
A buggy client could accidentally do this

Severity: Medium (not Critical as ChatGPT claimed)

It's a correctness bug, not easily exploitable
Users could lose funds in edge cases

JoeGruffins · 2026-01-27T08:18:50Z

Should fix the last issue and probably a better scheme than the initial changes. https://github.com/decred/dcrdex/compare/5f102b003b978664543f47478938ca7a28c14509..bc991947035e85e6e4c9946f47002bfb6a0ebd23

JoeGruffins · 2026-01-28T02:26:40Z

Fixing a problem with using just secrets https://github.com/decred/dcrdex/compare/bc991947035e85e6e4c9946f47002bfb6a0ebd23..4c78b093a52603d060c31935fc4ed4e8612959ad

problem

● This confirms there's a real issue. Let me trace through the attack scenario:

Detailed Analysis of Issue #1: Prepayment Key Collision

The ERC-4337 Execution Model

The EntryPoint processes bundles in two phases:

Verification loop: Calls validateUserOp for ALL UserOps first
Execution loop: Then calls the account's function (e.g., redeemAA) for ALL UserOps

The Vulnerability

The prepayKey at lines 426 and 486 is derived only from the secrets:

bytes32 prepayKey = keccak256(abi.encodePacked(secrets));

Attack Scenario:

Assume two different swaps exist that happen to use the same secret (or an attacker intentionally sets this up as initiator):
┌──────┬─────────────┬────────┬──────────┐
│ Swap │ Participant │ Secret │ Value │
├──────┼─────────────┼────────┼──────────┤
│ A │ Alice │ S │ 10 ETH │
├──────┼─────────────┼────────┼──────────┤
│ B │ Bob │ S │ 0.01 ETH │
└──────┴─────────────┴────────┴──────────┘
If both submit UserOps in the same bundle:

validateUserOp(Alice's UserOp):
- prepayKey = keccak256(S)
- redeemPrepayments[prepayKey] = 0.001 ETH (Alice's gas fees)
- Pays 0.001 ETH prefund to EntryPoint
validateUserOp(Bob's UserOp):
- prepayKey = keccak256(S) ← SAME KEY!
- redeemPrepayments[prepayKey] = 0.005 ETH (Bob's gas fees) ← OVERWRITES
- Pays 0.005 ETH prefund to EntryPoint
redeemAA(Alice's UserOp):
- fees = redeemPrepayments[prepayKey] = 0.005 ETH ← WRONG (should be 0.001)
- delete redeemPrepayments[prepayKey]
- Alice receives: 10 ETH - 0.005 ETH = 9.995 ETH
- Alice LOST 0.004 ETH
redeemAA(Bob's UserOp):
- fees = redeemPrepayments[prepayKey] = 0 ← DELETED
- Bob receives: 0.01 ETH - 0 = 0.01 ETH
- Bob GAINED 0.005 ETH (his gas was paid by contract)

Exploitation Path

An attacker as initiator could:

Create a legitimate swap with victim as participant, high value, secret S
Create a malicious swap with attacker-controlled address as participant, low value, same secret S
Wait for victim to submit their UserOp (secrets visible in mempool)
Submit attacker's UserOp in the same bundle with higher gas fees

The victim pays the attacker's higher gas fees, and the attacker's redemption gets free gas.

Severity Reassessment: HIGH

This is exploitable when:

Attacker is the initiator (controls secretHash)
Victim uses redeemAA (account abstraction path)
Both UserOps land in the same bundle

JoeGruffins · 2026-01-28T02:47:58Z

I think I'm at the end of my ralph loop. Going with these changes unless someone else can find something.

JoeGruffins · 2026-01-28T02:56:34Z

Apparently encode is better than encodePacked here https://github.com/decred/dcrdex/compare/4c78b093a52603d060c31935fc4ed4e8612959ad..d181bc04855169b703249f62121d93d7f8381a31

martonp · 2026-02-07T18:11:06Z

+    // This accounts for: storage reads, storage writes, ETH transfer, and loop overhead.
+    uint256 internal constant MIN_CALL_GAS_PER_REDEMPTION = 15000;
+    // Base gas for redeemAA regardless of redemption count (function overhead, final transfer).
+    uint256 internal constant MIN_CALL_GAS_BASE = 50000;


Are these definitely big enough? We need a bit of a buffer as EVM costs may change a bit.

martonp · 2026-02-07T18:13:49Z

+        (bool ok,) = payable(recipient).call{value: total - fees}("");
+        require(ok, "AA payout failed");


It's still requiring the payment to succeed.. the last line should be removed.

JoeGruffins · 2026-02-09T02:55:10Z

Upping min gas and not erroring when redeeming at the end https://github.com/decred/dcrdex/compare/b492d93eb1e985380b9556f6db6d3acf1a2d23b0..79b7edd13161b17e4f20bd754bcbb59475bf37f1

JoeGruffins · 2026-02-09T03:21:54Z

I thought about adding the contract tests to github cli, but I guess its not necessary since it won't change much or without a big deal.

JoeGruffins · 2026-02-13T03:47:08Z

Explicitly checking refund record https://github.com/decred/dcrdex/compare/f0e18c5fa31f53f5169d711ee9056c59bb423a09..876ff9680e513ec37e72590642a1fb0a08180c06

JoeGruffins · 2026-02-13T04:03:34Z

fix aa redemption gas minimum https://github.com/decred/dcrdex/compare/876ff9680e513ec37e72590642a1fb0a08180c06..47590da3754c3d3ce3f0595f6a7b7567c67ca4bf

JoeGruffins · 2026-02-13T05:32:08Z

emitting the aaredeem failure https://github.com/decred/dcrdex/compare/d81f2923030fd74de6824d6766f937a022988bf2..06bdd17c4a7bc9609d7a13efb99a878dba7e4dc9

JoeGruffins · 2026-02-16T02:14:39Z

https://github.com/decred/dcrdex/compare/b72c2bd6222494dfc9e438716b2b1f8510b2f6f1..9b6811f8242d2786034a08d4f8a3bc2769a55757

Zero-secret fix:

Added require(r.secret != bytes32(0), "zero secret") in redeem (line 305), redeemAA (line 493), and a corresponding early-return check in validateUserOp (lines 405–409). This
prevents a redemption with bytes32(0) as the secret from resetting the swap record back to the uninitiated state.

Non-standard return codes fix:

Replaced the 10 custom error code constants (0–9) with just VALIDATE_SUCCESS = 0 and SIG_VALIDATION_FAILED = 1, per the ERC-4337 spec.
All failure paths in validateUserOp now return 1 instead of custom codes 2–9, preventing the EntryPoint from misinterpreting return values as aggregator contract addresses.
Updated the NatSpec to reflect the new return semantics.

I think we have to check secret hash is not the hash of secret 0 in init. I thought we were already doing this but I guess not?

JoeGruffins · 2026-02-16T02:58:47Z

https://github.com/decred/dcrdex/compare/07ed62c51e981905b494cdbf48928608ccd5bba4..dc99b0939d3d98007b4bfbfba2f125d05cf67342

Use ECDSA.tryRecover instead of ECDSA.recover (line 464)

recover reverts on malformed signatures (wrong length, empty), violating the ERC-4337 spec which expects validateUserOp to return SIG_VALIDATION_FAILED instead. Replaced with
tryRecover which returns an error code.

Prevent double-validation of the same swap within a bundle (lines 87–94, 429–447)

Added a validatedAt mapping that records the block number when each swap key passes validation. A second validateUserOp call for the same swap in the same block is rejected. Entries
auto-expire in the next block. This prevents an attack where two UserOps in the same EntryPoint bundle both pass validation and both pay prefund, but only the first execution
succeeds — draining contract funds.

Block unredeemable/unrefundable swaps at initiation (lines 71–74, 265–270)

Added checks in initiate to reject swaps that could never be redeemed or refunded:

v.initiator != address(0) — refund would burn funds to zero address
v.participant != address(0) — nobody can call redeem as address(0)
v.secretHash != bytes32(0) — no sha256 preimage produces zero
v.secretHash != ZERO_SECRET_HASH — only preimage is bytes32(0), which redeem rejects

Added the ZERO_SECRET_HASH constant (precomputed sha256(bytes32(0))).

JoeGruffins · 2026-02-16T02:59:15Z

The vulnerabilities just go on forever.

JoeGruffins · 2026-02-17T03:40:56Z

add nonReentrant to validateUserOp and adding more test. Forgot to rebuild the go bindings.

https://github.com/decred/dcrdex/compare/15f4c860593179ca2f78adb437ca246cca38b898..db5858db0d0b14a6837dc4659ec7ced3d205c276

JoeGruffins · 2026-02-17T05:14:15Z

Small bug where user can drain gas with a billion trades https://github.com/decred/dcrdex/compare/de959a58ee2b16738591b5735d880a50686f1eaa..65e2b0b2a8045f805fca3c6a73411e47cdf96f21

38 tests covering core swap lifecycle (initiate, redeem, refund), status/view functions, ERC-4337 account abstraction redeem via EntryPoint.handleOps, all 9 validateUserOp error codes, and AA security properties (reverting recipient drain protection, gas constant adequacy, prepayment key uniqueness).

Switch v1+ contract compilation from raw solc to Hardhat, which properly resolves npm dependency import paths (OZ v5, account-abstraction v0.7). Extract ABI and bytecode from Hardhat artifacts for abigen.

JoeGruffins · 2026-02-18T03:17:53Z

Updated the ERC-4337 to 0.7 because that has better L1 calculations for base, apparently

JoeGruffins force-pushed the chatgptcontractv1 branch 2 times, most recently from 356f6e0 to 5d5ae86 Compare January 23, 2026 08:00

JoeGruffins force-pushed the chatgptcontractv1 branch 2 times, most recently from 4cf9f65 to 730b0f9 Compare January 23, 2026 09:32

JoeGruffins marked this pull request as ready for review January 23, 2026 09:32

martonp reviewed Jan 23, 2026

View reviewed changes

JoeGruffins force-pushed the chatgptcontractv1 branch from 730b0f9 to 78f845e Compare January 26, 2026 04:36

JoeGruffins force-pushed the chatgptcontractv1 branch from 78f845e to 5f102b0 Compare January 27, 2026 07:48

JoeGruffins force-pushed the chatgptcontractv1 branch from 5f102b0 to bc99194 Compare January 27, 2026 08:18

JoeGruffins force-pushed the chatgptcontractv1 branch from bc99194 to 4c78b09 Compare January 28, 2026 02:24

JoeGruffins requested review from buck54321 and martonp January 28, 2026 02:48

JoeGruffins force-pushed the chatgptcontractv1 branch from 4c78b09 to d181bc0 Compare January 28, 2026 02:56

martonp reviewed Feb 7, 2026

View reviewed changes

JoeGruffins force-pushed the chatgptcontractv1 branch 2 times, most recently from b492d93 to 79b7edd Compare February 9, 2026 02:54

JoeGruffins force-pushed the chatgptcontractv1 branch 2 times, most recently from 371b1f3 to 79b7edd Compare February 9, 2026 03:20

JoeGruffins force-pushed the chatgptcontractv1 branch 2 times, most recently from f0e18c5 to 876ff96 Compare February 13, 2026 03:46

JoeGruffins force-pushed the chatgptcontractv1 branch from 876ff96 to 47590da Compare February 13, 2026 04:00

JoeGruffins force-pushed the chatgptcontractv1 branch 3 times, most recently from d81f292 to 06bdd17 Compare February 13, 2026 05:31

JoeGruffins force-pushed the chatgptcontractv1 branch 3 times, most recently from b72c2bd to 9b6811f Compare February 16, 2026 02:09

JoeGruffins force-pushed the chatgptcontractv1 branch 2 times, most recently from 07ed62c to dc99b09 Compare February 16, 2026 02:58

JoeGruffins force-pushed the chatgptcontractv1 branch 3 times, most recently from 15f4c86 to db5858d Compare February 17, 2026 03:37

JoeGruffins force-pushed the chatgptcontractv1 branch 2 times, most recently from de959a5 to 65e2b0b Compare February 17, 2026 05:12

JoeGruffins added 3 commits February 18, 2026 12:08

eth: Update v1 contract.

38dc811

eth: Update updatecontract.sh to use Hardhat.

8bf8811

Switch v1+ contract compilation from raw solc to Hardhat, which properly resolves npm dependency import paths (OZ v5, account-abstraction v0.7). Extract ABI and bytecode from Hardhat artifacts for abigen.

JoeGruffins force-pushed the chatgptcontractv1 branch from 65e2b0b to 8bf8811 Compare February 18, 2026 03:10

JoeGruffins merged commit a2d2595 into decred:master Feb 18, 2026
5 checks passed

		(bool ok,) = payable(recipient).call{value: total - fees}("");
		require(ok, "AA payout failed");

Conversation

JoeGruffins commented Jan 22, 2026

Uh oh!

JoeGruffins commented Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JoeGruffins commented Jan 23, 2026

Uh oh!

JoeGruffins commented Jan 23, 2026

Uh oh!

martonp Jan 23, 2026

Choose a reason for hiding this comment

Uh oh!

JoeGruffins Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JoeGruffins Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

JoeGruffins Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

martonp Feb 7, 2026

Choose a reason for hiding this comment

Uh oh!

JoeGruffins Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

JoeGruffins commented Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JoeGruffins commented Jan 27, 2026

Uh oh!

JoeGruffins commented Jan 27, 2026

Uh oh!

JoeGruffins commented Jan 27, 2026

Uh oh!

JoeGruffins commented Jan 28, 2026

Uh oh!

JoeGruffins commented Jan 28, 2026

Uh oh!

JoeGruffins commented Jan 28, 2026

Uh oh!

martonp Feb 7, 2026

Choose a reason for hiding this comment

Uh oh!

martonp Feb 7, 2026

Choose a reason for hiding this comment

Uh oh!

JoeGruffins commented Feb 9, 2026

Uh oh!

JoeGruffins commented Feb 9, 2026

Uh oh!

JoeGruffins commented Feb 13, 2026

Uh oh!

JoeGruffins commented Feb 13, 2026

Uh oh!

JoeGruffins commented Feb 13, 2026

Uh oh!

JoeGruffins commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JoeGruffins commented Feb 16, 2026

Uh oh!

JoeGruffins commented Feb 16, 2026

Uh oh!

JoeGruffins commented Feb 17, 2026

Uh oh!

JoeGruffins commented Feb 17, 2026

Uh oh!

JoeGruffins commented Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

JoeGruffins commented Jan 22, 2026 •

edited

Loading

JoeGruffins Jan 26, 2026 •

edited

Loading

JoeGruffins commented Jan 26, 2026 •

edited

Loading

JoeGruffins commented Feb 16, 2026 •

edited

Loading

JoeGruffins commented Feb 18, 2026 •

edited

Loading