feat: close position wrapper

[kaze-cow]

Description

Summarize what this PR does and why in a single, clear sentence.
A reader should understand the purpose and scope of the change just from this line.

Context

Explain the motivation or problem this PR addresses.
Include links to any relevant documentation, tickets, or discussions.

Provide background that helps reviewers understand why the change is needed.
Highlight any important design decisions, dependencies, or related components.

Out of Scope

Specify what is not covered in this PR.
This helps reviewers focus on the intended scope and prevents scope creep.

Testing Instructions

Provide clear, step-by-step instructions for verifying this change locally.
Assume the reviewer has no prior context about your setup.

This section reinforces the scope of the PR by outlining what should be tested and what the expected outcomes are.

[claude]

Claude finished @kaze-cow's task —— View job

---

Code Review Complete

I've completed a comprehensive review of the ClosePositionWrapper implementation. Here's my analysis:

Summary

The CowEvcClosePositionWrapper is well-structured and follows the established patterns from CowEvcOpenPositionWrapper. However, there are critical logic issues in the repayment flow that need to be addressed before merging.

---

Critical Issues

1. Incorrect Repayment Asset Flow 🔴 (High Priority)

Location: helperRepay function (lines 233, 240)

Problem: The function attempts to pull repayment assets from the owner's wallet, but according to the documented flow (lines 14-18), the settlement should have already transferred these assets to THIS contract.

// Lines 233, 240 - Current implementation
uint256 repayAmount = asset.balanceOf(owner);  // ❌ Checking owner's balance
SafeERC20Lib.safeTransferFrom(asset, owner, address(this), repayAmount, address(0));  // ❌ Pulling from owner

Expected Flow:

1. Settlement executes (swaps collateral → repayment assets)
2. Repayment assets land in THIS contract (as swap receiver)
3. This contract repays the vault

Current Flow:

1. Settlement executes
2. Function tries to pull from owner's wallet
3. This creates a mismatch - assets are in the wrong place

Fix Required: The repayment assets should be checked and used from address(this), not owner:

uint256 repayAmount = asset.balanceOf(address(this));
// Transfer directly to vault without pulling from owner
asset.approve(vault, repayAmount);
IBorrowing(vault).repay(repayAmount, account);

Impact: This is a blocker - the current implementation won't work correctly as the settlement contract sends assets to the receiver specified in the order (which should be this wrapper contract), not to the owner's wallet.

---

2. Settlement Execution Order ⚠️ (Medium Priority)

Location: _wrap function, lines 272-277 vs lines 283-300

Problem: The settlement call (item 0) executes before the permit (item 1) in the non-pre-approved flow. This means the wrapper attempts to operate before it has authorization.

// Current order:
items[0] = Settlement call         // ❌ Executes first
items[1] = Permit authorization    // ❌ Executes second

Comparison with OpenPositionWrapper: The OpenPositionWrapper correctly places permit BEFORE the settlement:

// OpenPositionWrapper (correct):
items[0] = Permit authorization    // ✓ Executes first
items[1] = Settlement call         // ✓ Executes second

Fix Required: Reorder the batch items to match OpenPositionWrapper pattern.

Impact: This could cause authorization failures depending on what the settlement tries to do.

---

Documentation Issues

3. Missing Field Documentation 📝

Location: Line 136

The collateralAmount field lacks a description. Based on usage, it should be:

/**
 * @dev The amount of collateral vault shares to sell/withdraw for repayment
 */
uint256 collateralAmount;

---

Code Quality Issues

4. Duplicated Wrapper Data Parsing Logic 🔧

Location: _parseClosePositionParams (lines 150-168)

Problem: The manual calculation of consumed bytes (line 165) is duplicated between OpenPositionWrapper (224 bytes) and ClosePositionWrapper (256 bytes). This creates maintenance burden and is error-prone.

// ClosePositionWrapper
uint256 consumed = 256 + 64 + ((signature.length + 31) & ~uint256(31));

// OpenPositionWrapper  
uint256 consumed = 224 + 64 + ((signature.length + 31) & ~uint256(31));

Recommendation: Extract to a shared helper function in CowWrapperHelpers.sol or create a library to reduce duplication and make the codebase more maintainable.

---

Potential Precision Issues

5. Integer Division Precision Loss ⚠️

Location: Line 383

transferAmount = params.repayAmount * borrowPrice / collateralVaultPrice;

Problem: Integer division can cause precision loss, potentially leading to insufficient collateral transfers that could cause settlement failures.

Recommendation: Consider rounding up to ensure sufficient collateral:

transferAmount = (params.repayAmount * borrowPrice + collateralVaultPrice - 1) / collateralVaultPrice;

---

Positive Observations ✅

1. Excellent Test Coverage: Both integration tests (CowEvcClosePositionWrapper.t.sol) and comprehensive unit tests (CowEvcClosePositionWrapper.unit.t.sol) are well-written
2. Consistent Error Handling: Uses require() with custom errors as per coding standards
3. Good Use of Events: CowEvcPositionClosed event properly tracks all position closures
4. Pre-Approved Hash Support: Correctly implements the pre-approved hash pattern for EIP-7702 compatibility
5. Security: Proper authorization checks (Unauthorized errors, EVC context validation)
6. Subaccount Validation: Correctly validates that subaccounts are controlled by the owner (lines 373-376)

---

Test Quality Issues

6. Incorrect Test Calculation 🧪

Location: Test file, line 185

r.interactions[1][0] = getWithdrawInteraction(sellVaultToken, buyAmount * r.clearingPrices[1] / 1e18);

Problem: This doesn't account for vault share-to-asset conversion. For a KIND_BUY order, the withdrawal amount should factor in the vault's exchange rate, not just the price ratio.

---

Recommendations

Must Fix Before Merge:

1. ✅ Fix the repayment asset flow in helperRepay (Issue feat: euler working poc #1)
2. ✅ Reorder settlement and permit in _wrap (Issue feat: working security #2)

Should Address:

3. Add missing documentation for collateralAmount (Issue feat: use new wrapper from upstream #3)
4. Fix precision issue in subaccount transfer calculation (Issue feat: close position #5)
5. Fix test calculation for vault withdrawals (Issue feat: add wrapper #6)

Nice to Have:

6. Refactor duplicated wrapper data parsing logic (Issue feat: pull in required vendor dependencies #4)

---

Consistency Check vs OpenPositionWrapper

I compared the two wrappers and found these patterns:

Aspect	OpenPositionWrapper	ClosePositionWrapper	Status
Authorization flow	Permit → Operations	Settlement → Permit	❌ Inconsistent
EVC integration	✅ Correct	✅ Correct	✅ Good
Pre-approved hashes	✅ Supported	✅ Supported	✅ Good
Error handling	✅ require() style	✅ require() style	✅ Good
Subaccount handling	N/A (deposits to account)	✅ Validates ownership	✅ Good

---

The implementation is close to being production-ready, but the repayment flow issue is a critical blocker that must be resolved. Once Issues #1 and #2 are fixed, this will be a solid addition to the codebase.

[claude]

Logic Issue: This line reads the balance from owner but the comment on line 239 says funds will be pulled from the user. There's a mismatch here.

The balance check should be on address(this) since this is where the settlement contract sends the repayment assets after the swap. The CoW settlement should have already transferred the assets to this contract before helperRepay is called.

Consider:

uint256 repayAmount = asset.balanceOf(address(this));

Then transfer from address(this) to the vault instead of pulling from owner.

[claude]

Logic Issue: This attempts to pull funds from owner, but based on the documented flow, the repayment assets should already be in this contract from the settlement.

The settlement executes first (step 1 in _wrap), which swaps collateral → repayment assets. According to the contract comments (lines 17-18), the recipient of the swap should be THIS contract. Therefore, this line should not be pulling from owner.

If you need to pull from owner, the order receiver in the settlement should be set to owner, not this contract. Currently there's an inconsistency between the documented flow and implementation.

[claude]

Potential Integer Division Precision Loss: This calculation could lose precision due to integer division. Consider whether rounding should be in favor of transferring slightly more collateral to prevent settlement failures.

// Consider rounding up to ensure sufficient collateral
transferAmount = (params.repayAmount * borrowPrice + collateralVaultPrice - 1) / collateralVaultPrice;

[claude]

Missing Documentation: The collateralAmount field lacks a description. Based on usage, it appears to be the amount of collateral shares to sell. Please add:

/**
 * @dev The amount of collateral vault shares to sell/withdraw for repayment
 */

[claude]

Code Quality: The manual calculation of consumed bytes is error-prone and duplicates similar logic in OpenPositionWrapper. Consider extracting this to a shared helper function or library to reduce duplication and maintenance burden.

The calculation differs slightly between wrappers (256 vs 224 bytes for params), making it easy to introduce bugs when adding/removing fields.

[claude]

Test Issue: The withdraw interaction calculation appears incorrect. You're using buyAmount * r.clearingPrices[1] / 1e18 but this doesn't account for the vault share-to-asset conversion rate.

For a KIND_BUY order where you want to buy exactly buyAmount of repayment token, you need to calculate how many vault shares to sell based on the vault's conversion rate, not just the price ratio.

[claude]

Ordering Concern: The settlement call (item 0) executes before the permit (item 1) in the non-pre-approved flow. This means the settlement happens before the wrapper has permission to operate on behalf of the user.

Consider reordering so permit comes first:

1. Permit (if needed)
2. Settlement call

This matches the OpenPositionWrapper pattern where authorization happens before the core operations.