Response to ChainLinkGod Accusations

While we tend to choose to ignore the noise from the Chainlink community, we feel obliged to react in this instance due to the gravity of the accusation.

Accusation in question

TL;DR

  • MakerDAO does not participate in nor benefit from liquidations in neither the Maker Protocol nor other protocols.
  • The fact that these slanderous accusation have been repeated not once, but three times, by the official Chainlink evangelist, reflects poorly on the integrity of the Chainlink community.
  • ChainLinkGod has dug up an old, known, and publicly disclosed issue that has since been remediated, and that is about to be permanently fixed by a production upgrade that is in the final stage of its roll-out.
  • The irony is that while the Maker Protocol was able to easily fix the issue, the Chainlink architecture is built in such a way that this cannot be avoided.

Statements

To be absolutely clear, MakerDAO and the Maker Foundation do not participate in liquidations, neither in the Maker Protocol nor in other protocols such as dYdX.

MakerDAO and the Maker Foundation have never profited or indirectly benefited from the use or sale of privileged price information.

Context

A few months ago, the Oracle Domain Team discovered a hidden undocumented state-size dependency within scuttlebutt, a p2p gossip network utilized by the MakerDAO Oracles. This was well documented both in the forum and discussed on the public Governance & Risk call multiple times.

This was concerning, as it could potentially be used by a malicious actor to spam the network. Two solutions were formulated, one short-term and one long-term.

Short term: Patch scuttlebutt to raise the state size limit

Long-Term: Integrate libp2p as a parallel gossip network to ensure 100% uptime in case either scuttlebutt or libp2p experienced an exploit, bug, or spam attack.

The short-term solution was to patch scuttlebot to bump up the state size to a high enough threshold that spam attacks become uneffective. However, as this change was nested deep in the dependency tree of scuttlebutt, it was unclear whether this might have adverse effects higher up in the stack.

Oracles are a mission critical piece of infrastructure for DeFi protocols. Failure is absolutely not an option. Adding code to a production system securing billions of dollars of value is something that needs to be handled delicately with an abundance of caution. Therefore, the decision was made to test the solutions for an extensive period of time before deployment into production.

In this interim period, it necessitated that access to the scuttlebutt network be restricted such that no malicious actor could abuse the attack vector we had publicly disclosed.

While necessary, it was a bit problematic, in that it gave Feeds and existing Relayers privileged access to signed price messages that were not public anymore. Fortunately, the pace of adaptability and innovation in DeFi is incredible. Liquidators without access to the scuttlebutt network started intercepting oracle updates in the mempool and front-running them. This leveled the playing field again among liquidators while the Oracle Domain Team developed and tested the proposed solutions.

The Oracle Domain Team completed testing of the Scuttlebot state size patch and rolled it out into production on 4/13/21. Development of the libp2p integration was also progressing favorably.

As many who follow DeFi closely are acutely aware. The growth of Flashbots in recent months has been astounding. To provide some context, Flashbots moves gas-price auction bidding wars between bots from the mempool to a special flashbot dark pool. The key advantage being that the loser(s) of a bidding war for a particular MEV opportunity, don’t end up having to pay for transactions that don’t “win.” In the case of Oracles this was slightly problematic because it meant price update weren’t being leaked into the mempool anymore, cutting off a segment of liquidators that were relying on that mechanism.

Fortunately, present day, the development of the libp2p integration has been completed, and rolled out to the production Oracle network in an upgrade earlier this month. However, the configuration option to activate libp2p has not been triggered yet as we undergo some final stability checks on the production network. As soon as these checks are completed in the coming weeks, libp2p will be activated, and network access can revert to being completely permissionless.

Final Remarks

The irony is that while Maker was easily able to fix the issue, the ChainLink architecture on the other hand has a fundamental design flaw such that this cannot be avoided. This is because it lacks the separation between Feeds and Relayers that the Maker Oracles have had from the beginning.

The MakerDAO Oracle architecture separates the roles of Feeds (price submitters) and Relayers (Oracle updaters). This means that by providing permissionless access and opportunity to be a Relayer, anyone can update a MakerDAO Oracle and extract MEV. Chainlink on the other hand does not separate the role of price submitter and Oracle updater. This means all MEV in Chainlink Oracles is completely monopolized by the Chainlink Feeds (price submitters), an exclusive group whose membership is controlled by Chainlink.

Chainlink randomly selecting a Feed to be the role of Oracle updater for each price update does not fix this problem, it just socializes gains among the privileged Feed validator set. This is not the case in an open permissionless network like the MakerDAO Oracles where anyone can be a Relayer to push Oracle updates.

58 Likes

Imagine all of DeFi at risk of a ChainLink oracle failure or attack. MakerDAO oracles are critical infrastructure. Competition is good.

1 Like

This post was flagged by the community and is temporarily hidden.

Chainlink is a centralised middleware that will soon be rendered obsolete.

Don’t parrot nonsense unless you are able to back it up.

I am disappointed in the Chainlink community. We just developed and expanded the oracle by ourselves, and MakerDao was slandered by the Chainlink community. This kind of behavior is really rascal.

1 Like

This might benefit from specific commit hashes and/or links to the relevant PRs for the referenced changesets?

1 Like

This post was flagged by the community and is temporarily hidden.

5 Likes

This post was flagged by the community and is temporarily hidden.

1 Like

“these accusations are slanderous”
“we are aware of the issue and we’re still working on a fix”

weird damage control seething at “autistic frogs” simply bringing to light a concerning disclosed issue but ok glad you’re bringing more transparency to the issue and will fix it soon because we all want this space and the values it stands for to succeed! fairness and transparency are the values we’re all rooting for. maker and chainlink should be complimentary and keep cordial mutual relationships, it’s very disappointing to see devs letting third party social media chatter irrationally cloud their judgment.

1 Like

Hi Nick, chiming in here as I was the person who originally investigated and raised the issue.

Just to be clear, I’m not accusing MakerDAO of profiting from insider trading, nor have I claimed that at any point. My intention from the beginning has solely been to get this fixed as quickly as possible.

However, it should be acknowledged that there has been a total lack of transparency present in this situation, which extends internally into your organisation. After all, you can’t possibly know if anyone from your team is running a liquidation bot, since this is by nature undetectable. You also can’t know which of the parties with privileged access have been violating the terms of the agreements they formed with your team. The insiders here could be anyone who is currently enjoying private access to the network.

It’s not the fault of MakerDAO that the 1 hour OSM protection was removed by third party protocols. However, by doing so the protocols involved created a situation that only MakerDAO could resolve, and which put MakerDAO in the uncomfortable position of being gatekeepers to hundreds of millions of dollars in liquidation profits.

The other protocols involved in this situation refused to address the problem, stating that it was your responsibility to do so. DyDx even went so far as to defend their removal of the delay, claiming that the OSM module actually brings systemic risk into the protocol by having a delay in the first place.

It’s great that MakerDAO is now publicly committed to fix this issue, but it’s disappointing that it has taken so long. I raised the issue in January and it’s now July, during which time the amount of wealth the network has amassed is incredible. I also originally raised this privately, in the hopes of getting the issue fixed quickly and avoiding negative publicity for your team. In your defence, you did acknowledge the seriousness of this from the beginning, but given the scale of the money involved I feel this should have been more of an internal priority for your team.

Still, I’m really glad that this is finally being resolved. The effects of this situation has been devastating to struggling mum-and-dad liquidators who just want a fair go in the markets, and who have been cut out of several major protocols since this debacle began. No-one expects the liquidation game to be easy, all we ask is to be on the same level playing field as everyone else.

Thanks!

4 Likes

This post was flagged by the community and is temporarily hidden.

7 Likes

Hmm it doesn’t seem like it was that chainlink guys accusation? Seems like it was @CodeForcer who judging by his reply is and looking at the original post wasn’t trying to attack anyone. I am a little disappointed in this response. It’s ok to acknowledge that a critical infrastructure flaw exists (or existed if you think it’s patched) as long as the team is working towards a fix and we should be thanking people who bring issues and results of those issues to light, not shaming them. This response felt immature and like you are attacking chainlink’s product, which afaik is used by the majority of the defi community including many of Maker’s partners & I’ve only ever heard their team talk about how they believe the space does need multiple oracle solutions, multiple exchanges etc.

1 Like

Am I the only who didn’t follow how a p2p network solves this problem?

The point is that whoever is last to sign on price, finalising it, can choose to not distribute the signed price updated in this public mempool or p2p network. And instead send it to a friend who extracts the MEV.

The only way to detect this is to observe the public mempool … And this applies equally to both Chainlink and MakerDAO

This post was flagged by the community and is temporarily hidden.

Well, unsurprisingly this thread is a bit of a shit-show. I’d appreciate it if all the Maker people could avoid antagonizing the Chainlink community.

For Chainlink people, if you have responses and don’t want them to be flagged, please make them without the inflammatory language.

23 Likes

Interestingly, the attack seems more directed to DyDx, which uses the feed and post the price.

Makerdao has the 1h delay, so it technically doesn’t matter as far as the price is not too far off.

1 Like