Add SQL query for solver approvals monitoring

[tamir-cow]

No description provided.

[harisang]

Is this actually the same query as the one that already exists in the repo? https://github.com/cowprotocol/dune-queries/blob/main/cowprotocol/monitoring/solver_approvals_4173928.sql

I admit i didn't remember this was there. If so, let's either close this PR or use it to improve the query. For example, one question I have is whether the query works for smart contract solvers. E.g., see this transaction: https://etherscan.io/tx/0x3fe09624e6f576e418ae6b1ce09034419b7b56233d6ee524c81052367b1bb03f

Does the query capture this correctly?

[harisang]

Also i believe we have a new proposer account. Does this need to be reflected in the query?

[tamir-cow]

Also i believe we have a new proposer account. Does this need to be reflected in the query?

Not for our use because we focusing on specific solver addresses

[tamir-cow]

Is this actually the same query as the one that already exists in the repo? https://github.com/cowprotocol/dune-queries/blob/main/cowprotocol/monitoring/solver_approvals_4173928.sql

I admit i didn't remember this was there. If so, let's either close this PR or use it to improve the query. For example, one question I have is whether the query works for smart contract solvers. E.g., see this transaction: https://etherscan.io/tx/0x3fe09624e6f576e418ae6b1ce09034419b7b56233d6ee524c81052367b1bb03f

Does the query capture this correctly?

@harisang It's the same query and it does not capture the attached tx

[harisang]

Is this actually the same query as the one that already exists in the repo? https://github.com/cowprotocol/dune-queries/blob/main/cowprotocol/monitoring/solver_approvals_4173928.sql
I admit i didn't remember this was there. If so, let's either close this PR or use it to improve the query. For example, one question I have is whether the query works for smart contract solvers. E.g., see this transaction: https://etherscan.io/tx/0x3fe09624e6f576e418ae6b1ce09034419b7b56233d6ee524c81052367b1bb03f
Does the query capture this correctly?

@harisang It's the same query and it does not capture the attached tx

Then i believe the query needs to be updated so that it works correctly for any tx that doesn't follow the format

• "from" -> solver
• "to" -> settlement contract

(e.g., smart contract solvers or flashloans txs)

[tamir-cow]

Is this actually the same query as the one that already exists in the repo? https://github.com/cowprotocol/dune-queries/blob/main/cowprotocol/monitoring/solver_approvals_4173928.sql
I admit i didn't remember this was there. If so, let's either close this PR or use it to improve the query. For example, one question I have is whether the query works for smart contract solvers. E.g., see this transaction: https://etherscan.io/tx/0x3fe09624e6f576e418ae6b1ce09034419b7b56233d6ee524c81052367b1bb03f
Does the query capture this correctly?

@harisang It's the same query and it does not capture the attached tx

Then i believe the query needs to be updated so that it works correctly for any tx that doesn't follow the format

• "from" -> solver
• "to" -> settlement contract

(e.g., smart contract solvers or flashloans txs)

It is. Reference: https://nomevlabs.slack.com/archives/C04V9D9JTEV/p1781508632992459?thread_ts=1781169095.967369&cid=C04V9D9JTEV

[harisang]

@tamir-cow i think approvals in txs like this one -> https://etherscan.io/tx/0x3fe20e9b8f325d8296421581b4f93608a313685ac591e8ac64a7a36e92c25487

are not captured. This is a flashloans txs from a solver that users executor addresses (not whitelisted) to execute multiple txs per auction.

Could you double-check this statement?

[tamir-cow]

@tamir-cow i think approvals in txs like this one -> https://etherscan.io/tx/0x3fe20e9b8f325d8296421581b4f93608a313685ac591e8ac64a7a36e92c25487

are not captured. This is a flashloans txs from a solver that users executor addresses (not whitelisted) to execute multiple txs per auction.

Could you double-check this statement?

@harisang Correct me if I'm wrong but I'm not sure this is supposed to be included in the first place. The owner of this approval is the executor address and not the settlement contract.

[harisang]

@tamir-cow i think approvals in txs like this one -> https://etherscan.io/tx/0x3fe20e9b8f325d8296421581b4f93608a313685ac591e8ac64a7a36e92c25487
are not captured. This is a flashloans txs from a solver that users executor addresses (not whitelisted) to execute multiple txs per auction.
Could you double-check this statement?

@harisang Correct me if I'm wrong but I'm not sure this is supposed to be included in the first place. The owner of this approval is the executor address and not the settlement contract.

I see this approval where the owner is the settlement contract

[tamir-cow]

@tamir-cow i think approvals in txs like this one -> https://etherscan.io/tx/0x3fe20e9b8f325d8296421581b4f93608a313685ac591e8ac64a7a36e92c25487
are not captured. This is a flashloans txs from a solver that users executor addresses (not whitelisted) to execute multiple txs per auction.
Could you double-check this statement?

@harisang Correct me if I'm wrong but I'm not sure this is supposed to be included in the first place. The owner of this approval is the executor address and not the settlement contract.

I see this approval where the owner is the settlement contract

@harisang This is a deeper approval inside the tx, the rank filtering we have (rk = 1) filters this approval because newer approval for the same spender token pair exists. If we drop this filter you will see this tx appear but I don't think this is the correct behavior.

[harisang]

@tamir-cow i think approvals in txs like this one -> https://etherscan.io/tx/0x3fe20e9b8f325d8296421581b4f93608a313685ac591e8ac64a7a36e92c25487
are not captured. This is a flashloans txs from a solver that users executor addresses (not whitelisted) to execute multiple txs per auction.
Could you double-check this statement?

@harisang Correct me if I'm wrong but I'm not sure this is supposed to be included in the first place. The owner of this approval is the executor address and not the settlement contract.

I see this approval where the owner is the settlement contract

@harisang This is a deeper approval inside the tx, the rank filtering we have (rk = 1) filters this approval because newer approval for the same spender token pair exists. If we drop this filter you will see this tx appear but I don't think this is the correct behavior.

I guess my issue concretely is the following.

if we run this subquery for the tx hash above

    select
        evt_tx_hash as tx_hash,
        evt_block_time as block_time,
        "from" as responsible_address,
        spender,
        contract_address as token,
        a.value,
        rank() over (partition by spender, contract_address order by evt_block_number desc, evt_index desc) as rk
    from erc20_ethereum.evt_approval as a
    inner join ethereum.transactions on evt_tx_hash = hash
    where owner = 0x9008d19f58aabd9ed0d60971565aa8510560ab41 and hash = 0x3fe20e9b8f325d8296421581b4f93608a313685ac591e8ac64a7a36e92c25487

we see this allowance and we get that the responsible solver is
0xc8ad355c8291cbd52e738ed1df1f5ccbbbbf00ee

However, this is not a solver address, but rather an executor address used by this whitelisted solver address 0xA9D635EF85bc37EB9Ff9d6165481eA230ed32392

So the query flags the wrong address as the "responsible solver"