☝️

Original issue gnosis/gp-v2-contracts#340 by @nlordell

Original issue gnosis/gp-v2-contracts#796 by @nlordell

Currently, the withdraw script creates a list of traded tokens (which is persisted to disk) and then queries them 1 by 1 (capped at a maximum of 200) to decide which ones of them to dump and convert (based on some min-value threshold).

Given current ETH and the distribution of tokens in the settlement contract it usually only makes sense to withdraw a few tokens with large balances. However, this may require running the script multiple times (8x at the current traded token list) in order to cover all traded tokens.

Maybe we can use an external service to quickly give us an overview of tokens held in the settlement contract ordered by $ value to speed up the script and make it complete in one pass.

I didn't do much research yet on which services offer such an API. Maybe the zerion portfolio API could be a good starting point

Original issue gnosis/gp-v2-contracts#930 by @fleupold

Problem

Solvers can theoretically submit solutions outside of the competition (simply calling settle with a bunch of signed orders). The way this is prevented is by requiring large bonds being put up by solvers in order to get allow listed. Those bonds pose a barrier to entry for the protocol. In the current state, they cannot be easily reduced without adding additional risk to the system.

The potential damage can be broadly differentiated into two parts

1. Economic damage to the protocol (withdrawal of token balances stored in the settlement contract, e.g. by incurring high slippage, setting a bad allowance, or simply transferring out funds)
2. Economic damage to the user (settling orders out of competition at limit price, omission of pre/post interactions, etc).

While 1. is fairly contained and can be mitigated by frequently withdrawing internal buffers, 2. poses a much bigger risk to the protocol and is the main reason high bonds are required.

Suggested solution

Have the off-chain auction provide a signature attesting that a specific solver has indeed won the settlement they are trying to settle. The signature would attest to the following things:

1. Which solver has won the competition
2. Which order uids are expected to be executed and at what clearing prices (exact match, ie the solver is not allowed to add more orders)
3. Any pre/post interactions those orders are expected to yield (the solver may add additional pre and post interactions)

We would then have an intermediary contract intercept a solver's settle call, verify that their solution is indeed in line with the attestation committed to by the auctioneer and in this case forward the settle call to the main settlement contract. The intermediary contract would be associated with a full bond and allow-listed in the main settlement contract. Solvers would still require to post some amount of bond (cf. risk 1 above), but the bond could be significantly smaller and in a separate allow-list. in the future there could be many such intermediary contracts (one per bonding pool).

This would allow smaller capitalised solvers participate in the auction.

Acceptance Criteria

• Smart contract built with foundry and extensive test suite
• Implements the following logic:
  • Expose a method that accepts a solution and signature
  • Checks msg.sender is registered
  • Furthermore, computes commitment by hashing
    • msg.sender
    • auction id
    • included order uids and executions (buy/sell amounts)
    • a subset of interactions
  • Ecrecovers signer from signature using the commitment and asserts it matches the configured auctioneer
  • Forwards provided solution into the GPv2Settlement contract's settle call

We created a PR on the FE for the Goerli network implementation but seems like we need to do some stuff on the BE side and then to add the Goerli addresses to this file https://github.com/cowprotocol/contracts/blob/main/networks.json such as GPv2Settlement and GPv2VaultRelayer etc...

So in total we would need the following things

https://barn.api.cow.fi/goerli/api
https://api.cow.fi/goerli/api
https://safe-transaction.goerli.gnosis.io (is this already working?)
https://safe-relay.goerli.gnosis.io/api/v1/gas-station/ (is this already working?)

GP_SETTLEMENT_CONTRACT_ADDRESS
GP_VAULT_RELAYER
V_COW_CONTRACT_ADDRESS
COW_CONTRACT_ADDRESS
GNO address

For locked GNO
MERKLE_DROP_CONTRACT_ADDRESSES
TOKEN_DISTRO_CONTRACT_ADDRESSES

The changes from #57 broke support for running the script on networks that aren't mainnet.
At this point in time, this feature is mostly useful when testing the script.

The error is unclear to the user, namely something like There is no valid ERC20 token at address 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2, where the address is a mainnet token.

Using account 0xA03be496e67Ec29bC62F01a428683D7F9c204930
Script failed execution but no irreversible operations were performed
Error: There is no valid ERC20 token at address 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2
    at Array.<anonymous> (/home/fedgiac/code/cow/contracts/src/tasks/selfSell.ts:301:17)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Promise.all (index 1)
    at async promiseAllWithRateLimit (/home/fedgiac/code/cow/contracts/src/tasks/ts/rate_limits.ts:76:11)
    at async getOrders (/home/fedgiac/code/cow/contracts/src/tasks/selfSell.ts:421:5)
    at async prepareOrders (/home/fedgiac/code/cow/contracts/src/tasks/selfSell.ts:610:16)
    at async selfSell (/home/fedgiac/code/cow/contracts/src/tasks/selfSell.ts:787:36)
    at async SimpleTaskDefinition.action (/home/fedgiac/code/cow/contracts/src/tasks/selfSell.ts:981:9)
    at async Environment._runTaskDefinition (/home/fedgiac/code/cow/contracts/node_modules/hardhat/src/internal/core/runtime-environment.ts:330:14)
    at async Environment.run (/home/fedgiac/code/cow/contracts/node_modules/hardhat/src/internal/core/runtime-environment.ts:163:14)
An unexpected error occurred:

Error: There is no valid ERC20 token at address 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2
    at Array.<anonymous> (/home/fedgiac/code/cow/contracts/src/tasks/selfSell.ts:301:17)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Promise.all (index 1)
    at async promiseAllWithRateLimit (/home/fedgiac/code/cow/contracts/src/tasks/ts/rate_limits.ts:76:11)
    at async getOrders (/home/fedgiac/code/cow/contracts/src/tasks/selfSell.ts:421:5)
    at async prepareOrders (/home/fedgiac/code/cow/contracts/src/tasks/selfSell.ts:610:16)
    at async selfSell (/home/fedgiac/code/cow/contracts/src/tasks/selfSell.ts:787:36)
    at async SimpleTaskDefinition.action (/home/fedgiac/code/cow/contracts/src/tasks/selfSell.ts:981:9)
    at async Environment._runTaskDefinition (/home/fedgiac/code/cow/contracts/node_modules/hardhat/src/internal/core/runtime-environment.ts:330:14)
    at async Environment.run (/home/fedgiac/code/cow/contracts/node_modules/hardhat/src/internal/core/runtime-environment.ts:163:14)

I had a token in my token list that is unsupported so creating an order failed. This caused the whole script to exit. I would be better if we logged a warning while continuing with the other tokens.

An unexpected error occurred:13...

Error: Calling "https://barn.api.cow.fi/mainnet/api/v1/quote {"method":"post","headers":{"Content-Type":"application/json"},"body":"{\"sellToken\":\"0x1C4853Ec0d55e420002c5eFaBc7Ed8e0bA7A4121\",\"buyToken\":\"0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2\",\"validTo\":1664288868,\"appData\":\"0x2947be33ebfa25686ec204857135dd1c676f35d6c252eb066fffaf9b493a01b4\",\"partiallyFillable\":false,\"from\":\"0x84E5c8518c248DE590D5302fD7C32d2Ae6B0123c\",\"kind\":\"sell\",\"sellAmountBeforeFee\":\"89617252764471\"}"} failed with 400: {"errorType":"UnsupportedToken","description":"Token address 0x1c4853ec0d55e420002c5efabc7ed8e0ba7a4121"}
    at call (/home/e/contracts/src/ts/api.ts:142:30)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async getQuote (/home/e/contracts/src/tasks/dump.ts:349:25)
    at async Array.<anonymous> (/home/e/contracts/src/tasks/dump.ts:285:23)
    at async Promise.all (index 0)
    at async promiseAllWithRateLimit (/home/e/contracts/src/tasks/ts/rate_limits.ts:76:11)
    at async getDumpInstructions (/home/e/contracts/src/tasks/dump.ts:262:5)
    at async dump (/home/e/contracts/src/tasks/dump.ts:696:5)
    at async SimpleTaskDefinition.action (/home/e/contracts/src/tasks/dump.ts:897:9)
    at async Environment._runTaskDefinition (/home/e/contracts/node_modules/hardhat/src/internal/core/runtime-environment.ts:217:14) {
  apiError: {
    errorType: 'UnsupportedToken',
    description: 'Token address 0x1c4853ec0d55e420002c5efabc7ed8e0ba7a4121'
  }
}

Deleting yarn.lock, and the installing dependencies via yarn, and finally attempting yarn build:sol fails with the following error:

yarn run v1.22.18
$ yarn build:sol && yarn build:ts
$ hardhat compile --force
An unexpected error occurred:

Error: Cannot find module 'tenderly'
Require stack:
- /tmp/ext-test-Gnosis-Protocol-V2-mzyKps/ext/node_modules/@tenderly/hardhat-tenderly/dist/tasks/push.js
- /tmp/ext-test-Gnosis-Protocol-V2-mzyKps/ext/node_modules/@tenderly/hardhat-tenderly/dist/tasks/index.js
- /tmp/ext-test-Gnosis-Protocol-V2-mzyKps/ext/node_modules/@tenderly/hardhat-tenderly/dist/index.js
- /tmp/ext-test-Gnosis-Protocol-V2-mzyKps/ext/hardhat.config.ts
- /tmp/ext-test-Gnosis-Protocol-V2-mzyKps/ext/node_modules/hardhat/internal/core/config/config-loading.js
- /tmp/ext-test-Gnosis-Protocol-V2-mzyKps/ext/node_modules/hardhat/internal/cli/cli.js
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:995:15)
    at Function.Module._resolveFilename.sharedData.moduleResolveFilenameHook.installedValue [as _resolveFilename] (/tmp/ext-test-Gnosis-Protocol-V2-mzyKps/ext/node_modules/@cspotcode/source-map-support/source-map-support.js:811:30)
    at Function.Module._load (node:internal/modules/cjs/loader:841:27)
    at Module.require (node:internal/modules/cjs/loader:1061:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.<anonymous> (/tmp/ext-test-Gnosis-Protocol-V2-mzyKps/ext/node_modules/@tenderly/hardhat-tenderly/src/tasks/push.ts:3:1)
    at Module._compile (node:internal/modules/cjs/loader:1159:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1213:10)
    at Object.require.extensions.<computed> [as .js] (/tmp/ext-test-Gnosis-Protocol-V2-mzyKps/ext/node_modules/ts-node/src/index.ts:1608:43)
    at Module.load (node:internal/modules/cjs/loader:1037:32) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/tmp/ext-test-Gnosis-Protocol-V2-mzyKps/ext/node_modules/@tenderly/hardhat-tenderly/dist/tasks/push.js',
    '/tmp/ext-test-Gnosis-Protocol-V2-mzyKps/ext/node_modules/@tenderly/hardhat-tenderly/dist/tasks/index.js',
    '/tmp/ext-test-Gnosis-Protocol-V2-mzyKps/ext/node_modules/@tenderly/hardhat-tenderly/dist/index.js',
    '/tmp/ext-test-Gnosis-Protocol-V2-mzyKps/ext/hardhat.config.ts',
    '/tmp/ext-test-Gnosis-Protocol-V2-mzyKps/ext/node_modules/hardhat/internal/core/config/config-loading.js',
    '/tmp/ext-test-Gnosis-Protocol-V2-mzyKps/ext/node_modules/hardhat/internal/cli/cli.js'
  ]
}
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

@tenderly/hardhat-tenderly had a release today, which coincides with this failure; there is a warning about an unsatisfied dependency, namely:

warning " > @tenderly/[email protected]" has unmet peer dependency "tenderly@^0.0.2".

Oddly enough, downgrading to version 1.2.0 didn't work either (not sure why we didn't see that before), but that one also complains about unmet tenderly@^0.0.1, so that might be a clue.

Finally, downgrading to @tenderly/[email protected] allows the build to run normally.

I wonder why GPv2SafeERC20 library does not contain a safeApprove function that allows to call non-standard approve functions with no return value (e.g. USDT).

OpenZeppelin's SafeERC20 lib replaced the old safeApprove (which resets the allowance before updating it) with a new forceApprove to handle this specific case.

Maybe we need a different route to determine traded tokens/balances? Like the Graph?

Original issue gnosis/gp-v2-contracts#795 by @nlordell

Specifically, it looks like we are trying to estimate USD prices, but can't estimate for DAI because:

Warning: price retrieval failed for token DAI (0x6b175474e89094c44da98b954eedeac495271d0f): SameBuyAndSellToken (Buy token is the same as the sell token.)

We currently rely on filledAmount[orderUid] to determine if a fill-or-kill order was executed or not. However, if sellAmount is zero (and buyAmount is zero, as noted below) and the order is executed then filledAmount does not change, which means that the order can be executed again. This is problematic as the fee would be taken multiple times from the user.

This is not critical for normal user orders as we don't generate zero-sell-amount orders in the interface. It's however unlikely but possible that a user creates an order selling nothing for a fee and would be affected by this issue. Most importantly, it could cause bugs in contracts that rely on filledAmount as well, see for example the ETH-flow contract case.

In the current code, this is not an issue for partially fillable orders.

Processing steps 1 to 5 of 32...
/home/e/contracts/src/ts/api.ts:142
    const error: CallError = new Error(
                             ^
Error: Calling "https://barn.api.cow.fi/mainnet/api/v1/markets/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2-0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2/sell/1394156490525603742 undefined failed with 400: {"errorType":"SameBuyAndSellToken","description":"Buy token is the same as the sell token."}
    at call (/home/e/contracts/src/ts/api.ts:142:30)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async estimateTradeAmount (/home/e/contracts/src/ts/api.ts:164:44)
    at async ethValue (/home/e/contracts/src/tasks/ts/value.ts:80:10)
    at async Promise.all (index 2)
    at async getTransferToReceiver (/home/e/contracts/src/tasks/dump.ts:150:34)

This is because my token list contains weth and my --to-token is also weth. I'm not sure if I am supposed to manually remove Weth or if the script is supposed to handle it. Nic said that the script had done this in the past.

Problem

The current way of creating a bonding pool is very basic. Solvers have to create a Safe which is owned by CoW DAO and deposit the required funds into it. The address that deposited the funds is then allowed to "vouch" for solver addressed, which consequently get added to the competition endpoint and are added to the authenticated allow list using a manual process.

This is not only cumbersome but may also create issues with regards to trust for these large amounts. A similar issue, with much smaller amounts, was faced during development of the MEV Blocker fee which lead to the creation of https://github.com/cowprotocol/mev-blocker-till

Suggested Solution

Introduce an accounting contract similar to the MEV Blocker fee till which allows bond providers to deposit a specified set of token/amounts into it. This set of allowed tokens and required amounts should be subject to change by CoW DAO or a delegated party. In order to be sufficiently bonded solvers require two components

1. A certain amount of "stable" asset (e.g. yield baring stable coin)
2. A certain amount of CoW tokens

Providers are allowed to vouch for a set of addresses which are then allowed to "solve" under their bond (replicating the concept of the bonding pool). It should be possible to efficiently check if a certain address is currently covered under a bonding provider (this check will be done by the settlement contract's authentication logic).

Bond providers can request withdrawal of their bonds with a specified time delay (e.g. 14 days) that should be long enough for the DAO to issue any bond seizure or penalty if necessary. Solvers operating under a bonding pool that is in the process of withdrawing funds should no longer be able to settle.

Acceptance Criteria

• Solvers feel comfortable depositing the bonded requirements into the proposed smart contract
• GPv2 Settlement contract's allow list check is based on the state of this contract

Discussion Items

It might be desirable to also map additional accounting details (e.g. payment of rewards, protocol fees) via this contract, although this functionality would be out of scope for the attached EPIC.

Hey CoW Protocol team!

Attempting to add @cowprotocol/contracts as a dep in our repo makes npm throw an error. We're using ethers v5.6.0 while this repo seems to be using ethers v5.5.2 while specifying ~5.4.0 as a peer dep. This makes npm v7 throw an error (see below).

Since you already have ethers as a dep, can you just remove the peer dependency altogether? Is there a better solution?

$ npm i
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR! 
npm ERR! While resolving: [email protected]
npm ERR! Found: [email protected]
npm ERR! node_modules/ethers
npm ERR!   ethers@"5.6.0" from the root project
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer ethers@"~5.4.0" from @cowprotocol/[email protected]
npm ERR! node_modules/@cowprotocol/contracts
npm ERR!   dev @cowprotocol/contracts@"^1.3.0" from the root project
npm ERR! 
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR! 
npm ERR! See /home/user/.npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/user/.npm/_logs/2022-06-14T10_15_20_321Z-debug-0.log

Discussed during a docs update.

The contract already exists (here is mainnet), it's just a matter of adding it to our deployment procedure.

This is a view-only helper contract that isn't used directly by the protocol, so auditing is low priority.