RFP: Ethereum censorability monitor

Turned out there are a lot of good teams (we’re currently at 5 or 6 and they keep coming) who want to build the censorability meter for Ethereum. We can’t practically work with all of them on that separately and fund them all - that’s beyond our capacity. So we’re doing an open RFP instead. We ask teams to submit the links to their works and methodology to this thread, and in 3 months Lido will evaluate them and give out up to 7 grants:

  • 1st grant: 20k DAI - most useful meter for Lido’s purposes: tracking the effects of Lido policies on Ethereum censorability)
  • 2nd grant: 10k DAI - most useful meter for tracking the overall state of Ethereum’s censorability, can’t be the same participant as the first prize
  • up to 5x 2k DAI grants - best five working solutions out of the rest of the participants

We will separately work with select teams to fund their operational expenses at Lego’s discretion.

Criteria for the first grant, in order of importance:

  • tracks the current and historical metrics of service degradation for censorable transactions
  • tracks the impact of Lido and Lido’s node operators on service degradation
  • provides API, or, preferably, an open dataset to work with
  • is likely to be maintained long term (low complexity, low cost of maintenance, other sources of funding are a plus)
  • tracks the impact of Lido and Lido’s node operators to service degradation compared to the other staking pools and operators in staking pools, where applicable
  • is open-source

Criteria for the second grant and third grants, in order of importance:

  • tracks the current and historical metrics of service degradation for censorable transactions
  • is open-source
  • speed of delivery of minimally viable version in public (earlier is better)
  • provides API, or, preferably, an open dataset to work with
  • is likely to be maintained long-term (other sources of funding, low complexity, and low cost of maintenance are a plus)
  • tracks the impact of staking pools and select node operators to service degradation compared to the each other

We’re also interested in how the tx’s “value” (priority fee and extractable MEV) impacts these metrics - are more expensive censorable txs included faster? But if there’s no correlation in practice, including it in the main project isn’t important.

Only projects that a) have a open public version by the time RFP ends and b) posted a short freeform application in this thread will be considered. The end of the RFP is the 28th of February 2023 - so you’ll have about three months to deliver. After that, we’ll take a week or two to evaluate all the submissions.

18 Likes

Hello, very interesting project. Can you detail more what you mean by “service degradation for censorable transactions”? Besides “slow” tornado cash transaction (waiting for a non OFAC compliant validator) I don’t see what protocols could be censored/measured for service degradation.
Thank you in advance.

1 Like