Deploy Compound III on Linea

Proposals
1

[RFC] Deploy Compound III on Linea

Introduction

Hello Compound Community! This is Cameron from Consensys and Jun from PGov. We are excited to engage the compound community for feedback regarding a deployment of Compound V3 on Linea. This thread aims to be a starting point for discussion with a tentative timeline below.

Before jumping into the specifics of a potential deployment on Linea, it’s exciting to spotlight the collaboration between the protocol teams. Linea and Compound Labs have been working to integrate the protocol into Linea’s testnet voyage. This joint effort has led to exploring new functionalities, such as implementing gas-less sponsored transactions in compliance with EIP-4337 and adhering to guidelines set by Compound Labs.

Last week’s testnet voyage, “DeFi week,” was live for 7 days. During this period, Compound Contracts have facilitated over 295,000 transactions. These transactions were conducted by more than 100,000 wallets, which collectively contributed to the 333M of testnet liquidity.

Given Compound’s success on the testnet, Linea is enthusiastic about guiding users toward the protocol, thereby bolstering the establishment of Compound V3 as a premier lending market for the network.

Timeline and Scope of the RFC

In alignment with a commitment to transparency. This proposal outlines a tentative timeline below regarding a formal proposal to deploy Compound V3 on Linea mainnet. Linea Mainnet is expected to launch in mid-July.

1. Current: Request for Comment Period - the request for comment is a timeframe where we can garner feedback from community members on the network and technical aspects of a deployment.
2. July 17th: Formal Proposal - After incorporating community feedback and recommendations, we plan to post a formal proposal on the Compound forum. This proposal will adhere to the formal multichain deployment structure guidelines.
3. July 28th: Voting phase - Pending positive community feedback and discussions with core stakeholders, we aim to advance the proposal to the voting phase.

Preamble:

Type: Multichain Deployment
Title: Deploy Compound III on Linea
Author: PGov / Consensys/Linea

Proposal Introduction

Point of Contact:
PGov: @PGov
Linea: @Cameron, @befa
Email: Governance@Consensys.net
Set up a time to talk about the proposal: Calendly

Proposal Summary:

The Linea team from Consensys and PGov team are proposing the deployment of Compound III on Linea, a zkEVM incubated by Consensys, to continue broadening Compound’s multi-chain future and establish the lending market as a leading protocol on a promising zkEVM with a robust distribution network.

Overview of Proposal

  1. About Linea
  2. Proposed Markets

About Linea

Linea is a scalable L2 on top of Ethereum powered by a zkEVM tech stack incubated by Consensys, resulting from over 20 months of R&D from Consensys’s research team. This team has a track record of successful projects in the zk space, including the GNARK library and active involvement in the Merge.

Linea processes native EVM bytecode for proving and verification. This approach allows for the execution of Solidity smart contracts without needing modifications or re-audit. This also means compatibility at the RPC level with widely adopted middleware and toolsets, providing developers with a familiar environment to build using well-established tools and infrastructure.

Moreover, the network intends to align its onboarding and distribution through existing relationships with MetaMask, Infura, and Truffle communities. These products will help bootstrap the network and better serve developers, protocols, and builders.

Proposed Markets

We propose that the Linea deployment starts with an isolated USDC market with crypto majors as collateral. We also propose a conservative approach, after the applicable parties provide market and asset recommendations.

Motivation

Linea provides Compound access to an expansive and well-established user base through existing Consensys product integration. This connection facilitates a more efficient distribution and onboarding process for Linea, helping to catalyze Compound adoption on the network. This strategic alignment expands Compound’s market penetration and encourages new opportunities for user engagement.

|624x403.98368046687943
|624x403.983680466879431600×1037 105 KB

Linea prioritizes User Experience (UX), aiming to eliminate barriers for MetaMask’s impressive community of 30M MAUs. By securing native support in the default MetaMask network dropdown list, Linea enhances user convenience and fully supports all MetaMask curated experiences. These include On/Off Ramp, MetaBridge, MetaMask Swaps, the Portfolio dApp, and the MetaMask SDK, presenting numerous opportunities for incorporating the Compound protocol.

Grant Application:

Did not apply

Non-Technical Evaluation

Over 100 global partners and protocols are committed to launching on Linea within the first week of mainnet, some of which are below.

|624.5178423236515x395.99999999999994
|624.5178423236515x395.999999999999941600×1016 192 KB

Linea’s testnet has handled over 2 million transactions under private beta and over 40 million transactions under public beta. Many of these transactions are users of the ongoing Voyage quest, a crucial initiative designed to help stress-test the network. The network has also shown unprecedented developer activity, with over 4.3 M unique addresses deploying over 2M contracts, showcasing a vibrant and engaged developer community.

Security Evaluation

We identified the following considerations to be aware of. These considerations resulted from consultation with our internal team, Linea, and external stakeholders.

  • Linea’s sequencer and prover are centralized
    • The team is committed to decentralizing the sequencer and prover within the first 12 months of operation
  • A multi-sig can upgrade core smart contracts
    • The team is looking to mitigate centralization risk through the use of a security council within the first 12 months of operation
  • Low liquidity markets
    • A primary variable for risk analysis is liquidity data. As Linea does not expect to have accurate liquidity data by the time this proposal goes live, the team is looking into how best to mitigate risk for protocol stakeholders

Technical Evaluation and Considerations

  1. Technical Implementation
  2. Cross-chain Governance
  3. Oracles

Technical Implementation - Linea onboarding engineers will handle all technical deployment under advisement from all applicable stakeholders, including Compound Labs, OpenZepplin, and Gauntlet.

Please see a list of deployed testnet contract addresses here.

comet 0xa84b24A43ba1890A165f94Ad13d0196E5fD1023a
configurator 0x079f68Fa440A0F04d741a5Aba7DA8fE9DfB0AA8B
rewards 0x44411C605eb7e009cad03f3847cfbbFCF8895130
bridgeReceiver 0x06F066A9C0633507EAc640D89442C77748C3a2a8
l2MessageService 0xC499a572640B64eA1C8c194c43Bc3E19940719dC
l2TokenBridge 0xB191E3d98074f92584E5205B99c3F17fB2068927
bulker 0xad6729C101691A63F7d1e4CcbaD04bC8c6818a22
fauceteer 0x953d0A78eeC15E76266792fE163dC5316F5c2aca

Cross-chain Governance - The smart contracts deployed on Linea will be the same as the mainnet contracts, using the compound cross-chain governance process. The Layer 1 (L1) Timelock will manage the Linea contracts, transmitting messages to the Layer 2 (L2) BridgeReceiver through the native message-passing bridge. Please refer to the link provided for more comprehensive information on Compound III’s multi-chain governance approach.

Oracle - Linea currently does not have Chainlink integration. In looking for a suitable alternative for the deployment, the Linea team conducted a competitive analysis of oracles operating on the network. The analysis considered factors including Total Value Secured (TVS), data sources, aggregation methods, security, and market adoption. The evaluated on-chain oracle services were: Pyth, Redstone, and Umbrella (Deployed on testnet Compound integration).

The Linea team proposes to begin the discussion with Pyth as the oracle provider. Pyth’s first-party data is directly sourced from various trusted institutions, including exchanges, trading firms, and market makers. Pyth’s architecture and design enable secure and cost-effective high-frequency price feeds. The service has obtained audits for various networks, found here. Lastly, they have shown promising market adoption, including 1.7B TVS, and primary oracle integration at Synthetix and Venus.

Other Considerations

Sponsorship – PGov did not receive any sponsorship to contribute to this proposal.

Market Backstop Discussions – The Linea team is assessing the viability of having a safety module to backstop protocol losses that occur directly from oracle or liquidity manipulation for the first 60 days of operation. This would not be smart contract enabled. These discussions are ongoing and not finalized. According to the feedback on this proposal, The team will provide more details on this topic.

Copyright Waiver

Copyright and related rights waived via CC0.

License Exemption

We are requesting an exemption from the community that will allow the Linea network to obtain a Compound Business Source License (BSL) to use the Licensed Work, update compound-community-licenses.eth, and deploy it on the linea network, provided that the deployment is subject to Ethereum Layer 1 Compound Protocol governance and control.

Linea References

5 Likes
2

Chainlink is maintaining price information on-chain, ready to be consumed by compound directly (also called a push oracle). In contrast to that Pyth and Redstone are known for their Pull architecture, where prices are available elsewhere and are pulled into the respective chain whenever needed.

Compound lll is not build around this pull architecture and similarly in governance posts in the AAVE forum it was pointed out that AAVE cannot simply switch to a pull model, the same restrictions compound will be facing.

I’d be interested in knowing what integration is being proposed here and how exactly e.g. Pyth is going to be used to function as an oracle for Compound with the pull vs push restrictions in mind.

4 Likes
3

Thank you @sleezy - Great question! I circled back with a Pyth and Redstone representatives to get more technical details on push model integration.

Let me know if this answers the above; happy to gather more specific information.

Proposed Pyth Integration

Pyth operates with both a pull and push model. For the push model, The Pyth EVM price pusher is a service that regularly pushes price updates to the on-chain Pyth contract. Any entity can run this service to push regular updates based on various conditions, such as a minimum update frequency or a price deviation threshold. This service is “Chainlink compatible” and would be leveraged for integration using Pyth.

In the context of operating and maintaining the pusher for Compound III on Linea, the Linea core team will fund, operate, and maintain the price pusher. After discussions with the Linea team, we suggest running the pusher on the same update parameters used for mainnet price feeds. This approach provides the same functionality as the standard chainlink integration.
_

*** The parameters for the price feeds are subject to change based on feedback from core stakeholders to ensure protocol and user safety. (i.e. if more updates are necessary)

The goal would be to mimic the chainlink price feed updates found here.

Redstone Functionality

RedStone Finance also offers a push model known as the RedStone Classic model. This model uses an off-chain relayer that pushes data on-chain based on customizable conditions such as time intervals or value deviations. The relayer is permissionless, but Redstone typically operates end-to-end and maintains the pusher. This model is also “Chainlink compatible.”

2 Likes
4

Thanks @Cameron. Both of those imply heavy centralisation and are in stark contrast to what is currently in use with Chainlink.

In the case of Pyth, Compound will need to trust Linea as the sole entity of pushing prices and everything that comes with that (infrastructure, network costs, etc).

In the case of Redstone, the sole entity pushing the prices is apparently Redstone themselves, which again puts all the trust assumptions on a single entity.

Compound utilities Chainlink because it is actually a decentralized oracle network, where every node is ensuring that prices get published through OCR. If one oracle node operator fails, another makes sure that prices are on-chain.
Chainlink DONs range from 11-30 nodes within a certain price feed.

Your suggestion here in terms of oracles is a heavy downgrade in terms of security assumptions to what compound is used to and introduces risks that are currently not present.

I also don’t want this to become a bashing post. I like both Redstone and Pyth as innovation within the oracle space is good. I think their pull models are a novel approach and allow for many new interesting use cases.

With that being said I want to reiterate that you don’t suggest using them in a way they are advantageous, meaning in an actual pull fashion natively by compound. Instead it is being suggested to turn these pull models into a Chainlink like push model, which creates major centralisation risks where there were previously none since the responsibility of price pushing is put into a single entity.

Edit: you also refer to protocols like for instance synthetix as references for pyth, but synthetix integrates pyth in an actual pull model and not a makeshift push model.

2 Likes
5

@sleezy, Thank you for your thoughtful response. We appreciate your concerns around potential centralization. I was able to link up with internal teams at Consensys and the oracle providers to get a more thorough understanding of the concerns you shared and propose some ideas.

Firstly, I want to acknowledge the value that Chainlink brings to the table with its decentralized oracle network. It’s a robust solution that has proven its worth in the industry and has our utmost respect. However, Chainlink is not deployed to the Linea network and thus is not an option for us at this time.

The goal of our discussion is not to downgrade security assumptions but to find an alternative oracle solution that enables support for a deployment on Linea. The core Compound contracts would require a push model oracle; this also was confirmed by core stakeholders. A pull model oracle would require a more significant development lift. One core benefit of deploying on Linea is that, as a type two zkEVM, existing contracts can be deployed without modification. @befa can speak more on the benefits of a type2 zkEVM if needed.

A primary concern with the pushing solutions is a centralization risk associated with entities running the infrastructure. In the following, I will attempt to alleviate some of these concerns and propose ways to mitigate risk.

At Consensys, we take managing infrastructure seriously and have extensive experience in this area. Over the past 8 years, this experience has come from maintaining core Ethereum clients, hosting >20,000 Ethereum validators, Infura, operating infrastructure at Rocketpool and Lido, and more.

Specific Concerns

  1. In all of the above scenarios, the price pushing is done permissionless, so any person or entity can set up an instance and push the prices under the same parameters. This is particularly interesting in the case of an entity that has an incentive to push prices more frequently. For example purposes only, a liquidator operating onchain might be incentivized to run an instance and update the price pusher more frequently. The permissionless nature of the price pushing provides much flexibility to address redundancy further as the ecosystem grows.

  2. Under the example of Pyth, this specific instance of the price pusher would be running and monitored by our dedicated protocol & infrastructure teams. To help address redundancy, In the unlikely scenario that the price pusher would not update, the Pyth Data Association is committed to operating another pusher instance under the same parameters. Furthermore, Consensys will have backups ready to deploy under the same parameters if needed. Structures like this are common in the industry and closely related to how centralized sequencers are monitored across major L2 rollup ecosystems. (24/7 monitoring, response, backup)

  3. We also understand that OpenZepplin manages monitoring for the DAO. Consensys/Linea is also open to collaborating on a bot that monitors price updates for the discord. This helps to keep all stakeholders informed.

  4. Lastly, The Linea team is working to onboard Gelato’s automation relay network. This process is ongoing, with no finite ETA. However, when integrated, there is an option to run pushers (n instances/secondary/backups) on the Gelato relay network.

I hope the above ideas and information help alleviate some concerns and find a middle ground for a deployment. We are open to working with community members like yourself to find solutions that benefit all involved parties. If interested, you can access our team’s calendar to discuss any ideas you have for the deployment above.

2 Likes
6

thanks for the thorough writeout @Cameron!
I just wanted to highlight what you’ve written initially vs what you’re suggesting now are completely different things and as such turn the convo into an entirely different direction.

In the suggested pyth model you said, that Linea would be operating the sole price pusher

which now turned into Linea + Pyth + potentially Gelato, which obviously is a completely different conversation to be had, as you’ve now introduced multiple layers of potential decentralization (both in the form of more nodes and more entities running those).

A combination of the Linea team together with the oracle operator plus a potential Gelato Web3 Functions integration definitly sounds more appealing that what has been initially suggested.

2 Likes
7

H/T to the Complabs team, who worked diligently to get the forum back up

@sleezy - Thanks for the comment above!

You are absolutely correct in your analysis. We approach these discussions with an open mind and to engage with community members like yourself, to spot [and address] any weaknesses or concerns that might be raised. Having multiple entities run the price pusher is an outcome of our direct conversation and a perfect example of how open discussion can strengthen proposals. This will meaningfully impact how the proposed oracle will operate and reduce risk if this deployment passes through governance.

Thank you for working through the above with us; looking forward to further discussion on the potential deployment!

1 Like
8

I think we just need all the details on the table to make a fully informed decision. It is fine utilizing a new approach to oracles, but we need to know what precisely changes and what new/additional risks compound is taking on in this approach.

The push model we’re used to from Chainlink has the benefit that prices are maintained directly by the oracle node operators by the chain we consume them on. So the entities that fetch the price, come to an agreement off-chain and then put the price on-chain to consume are the same people.

image
image1934×575 82.4 KB

Compared to that the suggested Pyth model will introduce multiple different parties that are currently not in the picture in the push model, since its main design is a pull design.

With Pyth:

  1. oracle operators push prices to an aggregation contract on Pythnet
  2. Wormhole (a bridge) then attests to these values and makes them available through an HTTP gateway
  3. This gateway is then called by the Linea Team, the Pyth Foundation and potentially Gelato using a price pusher
  4. This pusher checks the price reported by the gateway against the on-chain price on the contract on the target chain and pushes prices if certain conditions are met
  5. Then compound reads the value.
    image
    image1992×775 145 KB

The overall effect is the same, prices will be on-chain, readily available for compound to be consumed.
The difference however lies in how many trust assumptions compound takes on.
In the Chainlink push model, you trust the node operators. It’s the same entities coming to an agreement what the price is (aggregating off-chain through OCR) that are pushing the respective price onto the contract on the target chain to be consumed by Compound at will.
In the Pyth model you trust:
a) Pythnet being online/maintained
b) the node operators to aggregate (on Pythnet) (*note this is the same as chainlink as you trust the oracle operators)
c) Wormhole (a bridge) to attest to the values on Pythnet
d) Linea to operate a price pusher
e) the Pyth Foundation to operate a price pusher
f) potentially Gelato to operate? a price pusher

While the end result is the same, you’ve just introduced:

  1. a bridge
  2. another chain
  3. 3 entities pushing prices

alongside the node operators that were needed anyway.

I know that my post might come across as severly negative, but that’s mainly because the topic of oracles was brushed aside as if it wasn’t an issue or a major change. You’re going to introduce a completely new model, with more parties involved, hence more trust assumptions, hence increased risk. The overall operation of such a system and the risk that compound takes on should be included if such a proposal is made, and should not be up to someone to point out.

1 Like
9

Another thing i wanted to mention here is that this decision is being justified by Pyth being used as a primary oracle and securing “billions” in value according to the Defillama TVS Dashboard.

75% of Pyth’s TVS come from Venus and Synthetix.

On Venus, the primary oracle is Chainlink and Pyth values are used to santiy check Chainlink. (Read more here)
Pyth is not the primary oracle like being claimed here.
On Synthetix, Pyth and Chainlink are used in combination for Synthetix Perps only. (Read more here)
Pyth is not the sole oracle used on Synthetix. It is only used in combination with Chainlink.

Most of the TVS that is used for justification of this provider is by projects that employ them alongside Chainlink. None of the 75% (and even more if we go down the list) are secured purely by Pyth.

This is in stark contrast to what is being suggested and communicated here.

1 Like
10

Hi @PGov @Cameron @sleezy ,

Before this goes to the formal proposal phase I thought I’d throw the Tellor hat in the ring as another possible option. After reading the discussion, it might also be worth exploring a multi-oracle system here, similar theme to the Chainlink/Uniswap anchor that Compound uses on mainnet.

Tellor has multiple live implementations as a component in a multi-oracle design:
A common use-case being a fallback to Chainlink for Liquity, Ethos, and more recently Raft. We’re also being used as a 1-of-3 median oracle for Ampleforth.

In terms of the push/pull dynamics we, too, are a pull oracle that can develop permissionless push solutions, i.e. our implementation on DIVA protocol.

Exciting to see Compound and Linea’s testnet progress so far and we’d love to help build out a resilient oracle solution that gives the community peace of mind. Happy to answer any questions.

Thanks!
Ryan

11

To the best of my knowledge (happy to be corrected) the Uniswap Achor is a thing of the past and only used on Compoundv2.

This proposal is about v3, which is configured with a single oracle in mind (currently Chainlink). V3 doesn’t use UAV2 or UAV3 in any capacity to the best of my knowledge.

12

@sleezy - Thank you for your perspective. As we navigate these concerns, our objectives moving forward are twofold:

  1. Address issues and concerns you’ve raised above through more detailed information/education about the oracle, and
  2. Have Pyth come to the forum to educate and further explain technical details on the oracle, including a walkthrough of how the oracle will function in a Compound integration.

This will help all stakeholders make a more informed decision when this proposal moves out of a RFC stage.

First, You highlight +6 new trust assumptions [a-f], as we walk through below, this is not accurate. You also are proposing that the newly introduced entities are in fact bad. This could be misleading, as 2 out of the 3 are trustless systems, and the third is a permissionless price pushing process, with multiple instances running.

above, A&B are separate, when they are the same. We could almost say this about any oracle. For Pyth, the prices are brought to Pythnet through blockchain transactions from each individual publisher, those are then automatically aggregated on Pythnet within the Pyth smart contract, following this algorithm.

Pythnet is the application-specific blockchain operated by Pyth’s data providers, in other words, each data publisher is also a validator. With more than 80 data providers today, any name listed here, are both a data provider and validator to the Network. Further, the network has onboarded various leading infrastructure providers to provide support to any of the 80+ data providers.

These node providers reinforce trustlessness across the network.

Wormhole operates trustlessly; there is no single entity that needs to be trusted. There are 19 guardians that operate within the system. These guardian nodes monitor the activities taking place on the chains to ensure the security of transactions. Further, and to be used as support, they have recently undergone an in-depth diligence regarding governance message passing. This process was carried out by an independent committee funded by the Uniswap Foundation, and Wormhole was one of the few providers to meet the committee’s standards for the DAO.

Wormhole Docs
UF Bridge Assessment Report

These concerns are not as applicable as they might seem at first glance. We’ve spent considerable time addressing the question of redundancy. The price pusher acts more like a scheduler, initiating transactions to broadcast prices through Wormhole’s trustless bridge. This process is permissionless, meaning any entity can spin up an instance of a pusher and start pushing prices.

Because the price pushing is integrated into a trustless process, the Pyth smart contract on every chain will verify all the prices ingested to ensure that (1) they’re prices attested by 2/3 of the Wormhole guardians; (2) and that it is sufficiently recent (both fresher than the current price in the Smart contract and within the last few seconds)

We acknowledge that the oracle implementation is one of the most critical aspects of this deployment. While Chainlink is not an option for this proposal, we strongly believe that what we are proposing is pragmatically the best option for this potential deployment.

Technical details on the oracle from the source will be beneficial for discussion moving forward, and we formally invite Pyth to the forum to provide more details, then further explain, educate, and answer technical questions around on the oracle.

1 Like
13

Hey Cameron, this is Mario, a Contributor from the Pyth Data Association

Thank you very much to all for this proposal and the thoughtful comments. Conversations like these are required for effective governance, and to ensure that Compound, among others, can expand to an exciting new chain like Linea while maintaining its high security standards.

Oracle Design

Pyth Network is an oracle designed to deliver accurate, reliable, and high-frequency prices to any blockchain. The protocol aggregates pricing data from a network of 80+ data providers, including some of the biggest financial institutions in both crypto and tradfi. The core of the protocol is an appchain called Pythnet operated by the data providers themselves. Data providers continuously stream prices for over 250+ assets to this blockchain, where their prices are robustly aggregated into the Pyth price. The aggregation procedure is robust and requires over 50% of data providers to manipulate the price.

Pyth prices are transferred from Pythnet to other blockchains via the Wormhole Network. Wormhole has 19 guardians who attest to the state of Pyth prices on the Pythnet blockchain. This process results in a continuously updating stream of signed price payloads. These payloads can be submitted to Pyth contracts on any supported blockchain; these contracts verify the validity of the signatures and store the price on-chain. Updating the on-chain Pyth price is a permissionless operation: anyone can submit a valid price payload at any time.

The entire system is designed for high reliability and performance. At every stage from data providers through wormhole, multiple independent entities would have to fail in order to cause an outage. Since Pyth’s launch in Fall 2022, Pythnet has had zero downtime, and the oracle has recently been delivering over 1 million price updates on-chain per day.

Compound Integration

There are multiple ways for protocols to integrate with Pyth. The most common is a “pull” integration, where the users of the protocol perform the permissionless Pyth price update themselves. This integration guarantees that the protocol receives the freshest prices which can be critical for latency-sensitive protocols.

However, for protocols such as Compound, it is technically simpler to perform a “push” integration. In this integration, an off-chain service called the Scheduler continuously updates the on-chain Pyth price, allowing anyone to use the on-chain price without worrying about updating it themselves. In this particular case, any combination of Consensys, the Pyth Data Association, and decentralized infrastructure like Gelato could operate this service.

Note that Pyth supports permissionless price updates even in a “push” integration. This approach eliminates the reliability risk associated with the off-chain service. Even if the service is offline, users will still be able to use Compound by simply sending a Pyth price update transaction first. While this may be awkward for retail users, sophisticated users — including liquidators — can and will integrate in this fashion.

2 Likes
15

Thanks for the writeout and clearing some of my misconceptions! Took the liberty to excentsively dive into the pyth docs again.
While some parts are cleared (e.g. that the oracle nodes are simultaniously the chain validators) others still remain, like e.g. the introduction of a bridge (even if that bridge is decentralized).

Overall, a pyth integration will introduce two sets of new parties in addition to the oracle node operators:

a) wormhole - the decentralization aspect of wormhole is not in question. but compared to what compound is used to currently, you have to acknowledge that you’ve introduced another party into the data delivery chain and no matter how trustworthy that party is, it is added risk compared to a system that doesn’t require them (especially considering that there is history of such exploits with wormhole). I think it is pretty obvious that a solution that is utilizing a bridge carries more risk than one that doesn’t. I hope that isn’t up for debate here.

b) Pushing - like outlined by @mariobern some entities are required to push prices for compound to function in a way that it is used to. Again comparing to what compound currently relies on are oracle nodes that do this. In the suggested pyth model 3 more entities (Consensys, Pyth and Gelato) are being introduced. We can sit here all day and debate how trustworthy these entitites are, which won’t change for one second that (similar to the bridge vs no bridge above) more parties need to be trusted and hence more risk is carried.

Just from the logical standpoint of risk, it is pretty obvious and non-debatable that the suggested implementation carries more risk than what compound currently implies. I don’t think anyone here can and/or questions that. It’s just a matter of if this is a risk that is willing to be taken.

As a disclaimer since i’m seeing some talk on twitter from people involved in this from the sides of pyth and consensys alike. I’m neither a holder of oracle tokens, neither do i work for any oracle projects, so throwing accusations into those directions looks pretty weak. I simply try to bring transparency into this because not all facts (risks) are being presented by parties that obviously want a compound deployment. There are chains popping up left and right and everybody is doing everything in their power to force a blue chip defi deployment and in some cases without properly outlining what new risks these blue chip protocols are taking on. It took some anon asking the tough questions before you decided to dive deeper and you still haven’t even acknowledged that the suggested implementation requires more trust (something non-debatable).

1 Like
16

I continued my research into various solutions that are being suggested here in the forums and i’ve stumbled upon another question for the Pyth and Consensys guys in this thread.

From what i could gather from the docs and this proposal is the fact that:

  1. prices are aggregated on pythnet from oracle operators, who are chain operators directly
  2. wormhole attests to these values
  3. someone runs a gateway that allows these values to be fetched
  4. some entities run a price pusher to push it to the desired chain

I am now particularly interested in the third point, which you call the Price Service, that was not mentioned anywhere in this thread. According to your documentation anyone can run one of these, but Pyth is the primary entity that does so. Since there was no mentioning of Consensys also running a Price Service alongside the mentioned Price Pusher, this would mean that this entire setup would rely on a single Price Service, hosted by Pyth.

So the suggested implementation here is that multiple entities run a Price Pusher that gets data from a singular, pyth-hosted Price Service. Or is the plan that Consensys also hosts such a Price Service? If so, i’d be good for them to mention this as well, as this seems to be yet another angle of potential centralization that finds no mentioning in this thread.

Here is the Github repo for the Price Service, for anyone interested. If the Pyth-hosted Price Service fails, and nobody else runs an additional one, all of these Price Pushers that are mentioned here to be ran by Pyth, Consensys and Gelato, won’t be able to get any data and won’t be able to maintain price information on-chain.

3 Likes
17

Considering the affiliation between Linea and Infura’s Chainlink node, it is plausible that the Chainlink infrastructure operated by Infura serves as the potential source of the data being provided by Linea. By incorporating other solutions like Pyth, Linea and Consensys could enhance the overall reliability and transparency of their data feed, potentially mitigating any concerns related to single-source dependency. This approach aligns with Consensys’ commitment to providing cutting-edge and secure services for their users, while also leveraging the speed and security of the Solana network through Pyth.

18

As part of the Compound III Security tooling grant DeFiSafety has filled out a revised Linea CIP-5 checklist for Linea. Comments on content, formatted and level of detail welcomed as I have 4 more checklists to do!

Short summary:
Linea appears to have a strong capable team implementing this chain. We received good technical support while completing this document. Virtually all answers in the checklist are complete with usable data. Linea has excellent EVM equivalence. There are a large variety of bridges and oracles that interface with Linea. DeFi Apps are just starting with only 200M TVL on chain, mostly with smaller DeFi apps.

1 Like