CIP-81: Whitelist "Generalized Wrappers" as Solvers

Governance
,
1 
CIP-Number: 81
Title: Whitelist "Generalized Wrappers" as Solvers 
Author: @middleway.eth, @kaze
Status: Active
Created: 2025-12-04

Simple Summary

Establish the “Generalized Wrapper” architecture as a recognized method for protocol expansion and authorize the Core Team Multisig to whitelist the first set of these wrappers (specifically for the Euler Finance pilot implementation) as bond-exempt solvers.

Motivation

CoW Protocol aims to expand beyond simple token swaps into complex DeFi operations—transactions that require atomic execution of pre- and post-swap actions (e.g., flash loans, position management, or cross-protocol interactions). Currently, the protocol relies on individual solvers or hooks to handle these complexities, which limits scalability and standardization.

To address this, we have developed the “Generalized Wrapper” architecture. This is a standardized pattern where an immutable smart contract acts as an intermediary layer:

  1. A standard solver computes the optimal path and wins the auction.

  2. The solver submits the transaction to the Generalized Wrapper instead of directly to the Settlement contract.

  3. The Wrapper performs the necessary side effects (e.g., borrowing funds, managing allowances, wrapping execution in a specific context) and calls the Settlement contract to execute the swap.

This architecture decouples “execution logic” from “solver logic,” allowing the DAO to add complex new functionalities without requiring every solver to build custom integrations.

Euler Finance will serve as the pilot implementation of this architecture, proving the capability to handle advanced flows like atomic leveraged position management.

For the Settlement contract to accept calls from these Wrappers, their addresses must be whitelisted as “Solvers.” This CIP seeks governance approval to:

  1. Formally recognize Generalized Wrappers as a valid protocol extension.

  2. Grant the Core Team Multisig a limited mandate to whitelist the specific contracts required for the pilot implementation (Euler Finance) without requiring the standard solver bond.

  3. Establish clear solver rules for interacting with these wrappers.

Specification

  1. Whitelist Authority: The Core Team Multisig is authorized to whitelist the specific Generalized Wrapper contracts required for the pilot implementation (Euler Finance) and necessary staging instances using the addSolver function. Final contract deployment addresses will be posted after the finalization of the audit and production deployment.

  2. Bond Exemption: This CIP explicitly exempts these approved wrappers from the requirement of posting a solver bond.

  3. Solver Rules Change: Solvers will be required to execute any wrappers specified as part of a settled order’s appData (specifically, when isOmittable is set to false).

    • Opt-In Nature: Solvers may choose to ignore orders that include wrapper instructions.

    • Mandatory Integrity: If a solver chooses to execute such an order, it must be executed using the specified wrapper instructions. Stripping the wrapper or altering the execution context is a violation of solver rules and grounds for slashing.

Wrapper Acceptance Criteria

To ensure the safety of the protocol, any Generalized Wrapper (for this pilot or future proposals) must adhere to the following strict criteria:

  • Security & Determinism: The wrapper’s input verification (e.g., parseWrapperData) must be deterministic. It cannot depend on variable state like block.timestamp for verification logic.

  • Validation: The wrapper MUST verify that msg.sender is an authorized solver or the settlement contract to prevent unauthorized access.

  • Trust Assumptions: Wrappers must treat all input data as potentially mutable and untrusted. Critical invariants must be verified on-chain.

  • Arbitrary Calls: Wrappers MUST NOT allow arbitrary user-defined calls (e.g., user-specified to and data) unless routed through a safety intermediary (like HooksTrampoline) to prevent attacks on the Settlement contract.

  • Standardization: Wrappers SHOULD use the CowWrapper abstract contract to standardize checks and encoding.

  • Atomic Failure: The wrapper must ensure that if it is bypassed or fails to execute, the entire settlement fails. This prevents users from being left in partial states (e.g., funds withdrawn but not deposited).

  • Audit & Transparency: All wrappers must be open-source and subject to a smart contract audit by a competent firm.

  • Not Upgradable: The wrapper smart contract cannot DELEGATECALL into a target address that can be changed in the future.

Rationale

Architecture: Wrappers as “Solvers”

In the CoW Protocol architecture, the entity calling settle() must be authenticated. Since the transaction chain is Off-chain Solver -> Wrapper -> Settlement, the Wrapper becomes the msg.sender and must hold the “Solver” role.

Limited Mandate vs. Permanent Authority

While Generalized Wrappers are a broad architectural upgrade, we are not requesting a permanent, open-ended mandate for the Core Team to whitelist any wrapper.

Instead, we are requesting a one-time mandate specifically for the pilot implementation (Euler). This allows us to move forward efficiently while preserving the DAO’s oversight. Future wrappers will require their own governance approval or the development of a permissionless, bond-based whitelisting system.

Bond Exemption

Standard solvers require a bond to penalize misbehavior. Wrappers, however, are:

  1. Immutable Code: They perform deterministic logic and cannot “choose” to misbehave.

  2. Audited Utilities: They are infrastructure, not active participants.

  3. Keyless: There is no entity to slash. Therefore, requiring a bond is redundant.

Clarification on Solver Liability

  • Execution Liability: The off-chain solver is fully liable for the execution. If they execute a wrapper order, they guarantee the user’s limit price and slippage are respected. Violating the wrapper instructions makes the solver liable for any resulting loss.

  • Code Liability: Solvers are not liable for bugs intrinsic to the whitelisted Wrapper smart contract code itself. The DAO assumes this risk via the whitelisting process.

Execution Details

The execution will be performed by the Authorized Safe responsible for managing the solver whitelist on the GPv2AllowListAuthentication contract. Note: This execution does not go through the CoW DAO Safe directly.

Other Resources

5 Likes
2

Hi, I’m Kaze, a Smart Contract Developer from the core team and the engineer behind this proposal.

I just wanted to drop a quick note on how impactful Wrappers are likely to be and the importance of this proposal. This wrapper strategy comes from lessons learned while integrating with Aave. Integrations are one of the best ways to continue growing CoW, and we want to make sure that future integrations are even more streamlined. Since finishing the Aave project, we have identified ways in which we can improve the speed and cost of deployment. We can turn what has up til now been a multi-team lift requiring deep coordination between the entire core team, solvers, and Aave, and turn it into a much simpler affair. By reducing the effort to deploy new integrations, we can pursue even more lucrative projects both now and in the future.

Wrappers allow for integrations to be achieved within the Smart Contract team by shifting the task of building out the integration almost entirely onto an onchain contract. Once the wrapper is complete and approved, the integrator’s frontend only needs to be updated to use the appropriate wrapper code in their app data calls to our API. Solvers will be able to safely build upon the core team’s efforts without needing to take any manual action on their part.

For right now the wrappers will be used for integration with Euler, but we look forward to the versatility brought by having this consolidation. Broadly speaking, some ideas we have for future integration with the protocol that have already been drawn out are:

  • Permit2
  • Swap and Deposit (ex. in a pool or staking program)
  • Smart orders like TWAP
  • Possible OFAC compliance for solvers that need it

I appreciate the community’s consideration of this proposal.

3 Likes
3

Here at Euler, we are very excited about this integration. Swaps have always been an integral part of our lending product, and the ability to set up and close looped positions atomically has been a key UX differentiator since Euler’s beginnings. Our current swapping backend has evolved into a fully fledged meta-aggregator integrating 16 swap providers, including DEXes and DEX aggregators.

Nevertheless, we regularly receive user feedback about the missing CoW integration. Since swaps in Euler must occur as part of a larger transaction on the user’s account, it has, until now, been technically impossible to use CoW, where execution is delegated to external parties. This is why we are particularly happy to see the Generalized Wrappers concept and its application to the Euler integration. It is an ingenious piece of engineering that opens up a wide range of new use cases for CoW, and we are thrilled to be the pilot implementation.

4 Likes
4

I support this as well. These integrations are great for CoW Protocol and the generalized wrapper would make this (and future integrations) easier for solvers.

2 Likes
5

I voted FOR.

This is one of those votes where we see the protocol developing, and it’s quite promising, with many potential partnerships.
We see that AAVE has already partnered with the protocol within AAVE itself, and now CoW may also have a reverse integration.

Cp0x: Introduction as Delegate