Overview
CoW Protocol uses a permission-based authentication system to control who can execute settlements. This design ensures that only trusted, vetted solvers can interact with user orders, providing security during the protocol’s early stages while maintaining a path to decentralization.Authentication Architecture
GPv2Authentication Interface
The core authentication interface defines a single method:src/contracts/interfaces/GPv2Authentication.sol
This simple interface allows different authentication implementations to be used without changing the settlement contract.
GPv2AllowListAuthentication Contract
The default implementation uses an allowlist approach:src/contracts/GPv2AllowListAuthentication.sol
Role Hierarchy
Proxy Admin
Highest authority. Can upgrade the contract and change the manager. Typically a multisig or DAO.
Manager
Operational role. Can add/remove solvers from the allowlist. Handles day-to-day authorization.
Solver
Execution role. Can call
settle() to execute batch auctions. Must be explicitly authorized.Manager Operations
Setting the Manager
src/contracts/GPv2AllowListAuthentication.sol
Initializing the Manager
src/contracts/GPv2AllowListAuthentication.sol
The initializer pattern allows the contract to be deployed behind a proxy. It can only be called once.
Solver Management
Adding a Solver
src/contracts/GPv2AllowListAuthentication.sol
Removing a Solver
src/contracts/GPv2AllowListAuthentication.sol
Both
addSolver and removeSolver are idempotent - calling them multiple times has the same effect as calling once.Settlement Authorization
The settlement contract enforces solver authorization at the entry point:src/contracts/GPv2Settlement.sol
Events
Authentication operations emit events for monitoring:Manager Events
src/contracts/GPv2AllowListAuthentication.sol
Solver Events
src/contracts/GPv2AllowListAuthentication.sol
Settlement Event
src/contracts/GPv2Settlement.sol
Proxy Pattern & EIP-1967
The authentication contract uses the EIP-1967 proxy standard:src/contracts/GPv2AllowListAuthentication.sol
EIP-1967 defines a standard storage slot for the proxy admin address, enabling secure upgradeable contracts.
Security Considerations
Immutable Authenticator
The authenticator address in the settlement contract is immutable:src/contracts/GPv2Settlement.sol
Why Immutable?
Why Immutable?
Making the authenticator immutable prevents the settlement contract from being compromised by changing authentication logic after deployment. If the authentication system needs to change, a new settlement contract must be deployed.
Upgrade Path
Upgrade Path
The authentication contract itself can be behind a proxy, allowing the allowlist logic to be upgraded without redeploying the settlement contract. The manager system provides operational flexibility.
Multi-Signature Recommendations
StorageAccessible Mixin
src/contracts/GPv2AllowListAuthentication.sol
StorageAccessible mixin allows direct storage reads, useful for:
- Off-chain verification
- Integration with block explorers
- Debugging and monitoring
Initialization Pattern
src/contracts/GPv2AllowListAuthentication.sol
initializer modifier (from Initializable mixin) ensures:
- The function can only be called once
- It must be called before other operations
- Prevents re-initialization attacks on proxies
This pattern is crucial for upgradeable contracts deployed behind proxies, where constructor logic doesn’t work.
Checking Solver Status
Anyone can query if an address is an authorized solver:view function that doesn’t modify state or cost gas when called off-chain.
Decentralization Path
The authentication system is designed for progressive decentralization:Phase 1: Centralized Allowlist
A small manager-controlled allowlist ensures security during initial launch.Phase 2: DAO Governance
Transition manager role to a DAO, requiring governance votes for solver changes.Phase 3: Permissionless (Potential)
Replace authentication contract with bond-based or reputation-based system allowing permissionless solver participation.The immutable authenticator in the settlement contract means moving to a new authentication model requires deploying a new settlement contract. This trade-off prioritizes security over flexibility.
Access Control Summary
| Role | Can | Cannot |
|---|---|---|
| Proxy Admin | - Upgrade contract - Change manager - Emergency interventions | - Add/remove solvers directly - Execute settlements |
| Manager | - Add solvers - Remove solvers - Transfer manager role | - Upgrade contract - Execute settlements |
| Solver | - Call settle() - Call swap() - Execute trades | - Modify allowlist - Access restricted functions |
| User | - Sign orders - Cancel orders - Check solver status | - Execute settlements - Modify protocol state |
