Kashi Lending: Add new VWAP oracles from DIA to increase asset availability


Currently, Kashi Lending is solely pulling data from Chainlink oracles via the VWAP method and plans to integrate Sushiswap TWAP. It is important to have more oracles offering support for a wider and deeper breadth of data for the Kashi Lending product. DIA’s VWAP oracles combine a preferred volume-weighted price with a broad coverage of digital assets.


Sushiswap launched Kashi with Chainlink being the sole oracle feed. However, the lack of decentralized oracle solutions on Sushiswap causes problems. As talked about by Orionmuir, relying on Chainlink to deploy the necessary oracles onto Kashi stalls the acceleration of new products that can be offered–especially across multiple chains.


DIA is a product driven by users. Requests for new datasets are community driven. So, if there were a need to oracalize new token pairs that are unusual such as X or Y token, it wouldn’t require any discussion with the DIA team, but just require a ticket to be submitted. We believe this would be very beneficial as the oracle wouldn’t be the limiting factor for spinning up new markets.

The choice of VWAP methodology and multiple sources makes us a more resilient option compared to other TWAP based oracles. The DIA methodology calculates VWAPs from a set of constituents (centralized and decentralized exchanges). USD-denominated prices are calculated once every second based on local exchange executions.

We believe that a VWAP index price feed is a more accurate representation of the fair market price.


  • Sushiswap TWAP oracles only pull data from a single exchange which lacks market coverage and introduces vulnerabilities.
  • TWAP by nature is a lagging indicator, which falls out of sync with high market volatility. This could lead to Kashi ingesting bad data that can lead to unwanted liquidations.

Summary of Benefits

  • Fast and community driven deployment of VWAP price feeds on different EVMs
  • No tradeoff between lack of choice of assets (Chainlink) and resilience of data feed (Sushiswap TWAP)
  • Higher transparency on price feed calculation and source
  • Freedom of choice
  • Add DIA VWAP Oracles
  • Do not add DIA VWAP Oracles

0 voters


Chainlink Price Feeds, which are being used by Kashi, are decentralized at the data source, node operator, and network levels, so this statement does not make sense. Launching a Price Feed requires coordination between node operators, finding multiple high quality data sources, and are launched based on user demand for data. Additional feeds are launched all the time across multiple chains, but quality is always prioritized over quantity, while more are consistently launched all the time.

For additional context for others, DIA is a 100% centralized oracle service where DIA runs all the nodes. From their documentation “For collecting financial data, we use a centralized backend that runs collectors for all kinds of financial data.” (source) A centralized oracle service does not increase decentralization, it achieves the exact opposite.

I do agree about VWAP being more suitable for DeFi applications like Kashi over TWAP because of stale data, hence why Chainlink Price Feeds provides data feeds that aggregate from multiple professional data aggregation firms (CoinGecko, BraveNewCoin, Kaiko, etc) using different VWAP methodologies to increase tamper-resistance in a decentralized manner.


Hey, thanks for the reply–we appreciate the interest.

Glad we can agree on the benefit of a VWAP reference rate. That is an accepted practice.

If you carefully read the proposal, we don’t argue that Chanlink is not the right solution, but that Kashi requires more than one oracle provider to best service it’s users.

DIA is sourcing execution data at the tick level from decentralized (DEX)–such as Sushiswap-- and centralized (CEX) exchanges. Because of this, unlike Chainlink, we are able to provide a VWAP feeds for longtail assets. A big difference in how we engage with data is that we actually say where data comes from (source is on the trade level, not a logo of a “premium data provider” – calling this decentralized is interesting to say the least).

We believe it is a good idea to offer the end user to choose what is best for them. Some people prefer data from centralized sources with little transparency on its origin and many nodes broadcasting that data, while others prefer our methodology which places an emphasis on data integrity, enterprise-grade reference rate methodologies, and deploy efficiency.

We all seem to agree that Kashi users can benefit from VWAP feeds. This is something DIA can do out of the box and has a proven track record of doing. Our end goal is to empower the end user and enhance the Kashi product offering.


Does it really matter how DIA claims to be sourcing their data when the fetching, verification, aggregation, and delivery of financial market data are all controlled by a single centralized entity (DIA) who can manipulate the data at any point in time?

DIA doesn’t even need to be malicious for this to be an issue (or have a malicious/bribed insider), we have seen numerous other DeFi projects get hacked because they lost control of a single private key (EasyFi lost $59M because of a compromised private key for example).

There is reason why the DeFi ecosystem as a whole has moved away from centralized oracles (e.g. Oraclize) to decentralized oracle networks (Chainlink) that mitigate any single point of failure. Integrating DIA into Kashi would put user funds at risk for any pools using DIA’s centralized oracle service and would harm Sushi’s reputation as a result.

Key point: Using centralized oracles defeats the purpose of decentralized smart contracts.

For more context on how Chainlink ensures a consistently high level of data quality while ensuring decentralization end-to-end:


The more oracles the better in my opinion, don;t ever want to limit yourself to one solution with data…


Sourcing, verifying, aggregating, and delivering financial market data is of the utmost importance. This is why DIA provides transparency on the process and the methodologies we use. We provide full transparency instead of plainly propagating such critical data from third parties.

Using the number of nodes as a proxy for decentralization addresses just one part of the oracle infrastructure that is needed to provide data for dApps. A distributed node structure potentially mitigates one scenario - having a malicious node tampering with the data feed. So far this has not been a relevant attack vector and has not drained a single dollar; it is highly questionable if this is achieved by having multiple nodes and a lack of economic incentives to be a good actor. The risk of key loss mentioned is not oracle specific but smart contract specific and needs to be addressed on any level of infrastructure including the smart contract ingesting the data.

Regardless of whether one sees more value in focusing on infrastructure transparency and the underlying core data that is fed to a dApp or the amount of nodes providing generic data feeds from centrally chosen premium data providers, it should be in the user’s right to choose what he prefers.

We believe that freedom of choice caters to a better product and ecosystem. Forcing people to use one service which also is lacking the breadth of assets is limiting the short and long term growth for Kashi. Kashi is exactly built for the use case of having segregated markets with many assets and isolated risk. It requires more oracles to actually create “any” market. This proposal caters to Kashis product vision to integrate any oracle:

We see tremendous value in the ability to choose from different oracles. In the long term, this should not be limited to Chainlink and DIA but any oracle that the community wants.

Key point: Users should have the freedom of choice and not be forced into using a single option.

Lastly, we would like to focus on the technical and abstain from tribalism enforced discussions.


I also am a bit apprehensive about a central party providing oracle data, you didn’t really respond to the concerns around malicious actors. How does DIA try to guarantee data validity to it’s users? Has any other exchange or defi app integrated with DIA’s data feeds? Is it theoretically possible for DIA to unilaterally start feeding spoofed trade data?

I hope you don’t interpret this as tribalism, I’m just struggling from reading the DIA docs to understand the security design. I do, however, think it’s important to offer the user choice. I’d rather allow market makers who pay researchers to do DD make the call on Chainlink oracle vs DIA oracles instead of blacklisting DIA just because they’re not what you would traditionally think of as a decentralized oracle provider.

Additionally if you or a DIA team member are available on Thursday, I host a community call to discuss news+proposals for the sushiswap ecosystem, I’m sure many people would appreciate you coming out to talk about DIA and answer questions.


Thank you for your comment magicturtle!

A few of our team members from the product and engineering teams will be on the community call Thursday. We will make sure to answer all questions.

And, please do note that we have quite a few integrations in the traditional finance space and digital asset and DeFi ecosystems.


I too am apprehensive about implementing an oracle solution with a centralized backend. The documentation does not make it clear how this infrastructure is secured against malicious actors, lost keys etc. Also, I’m not really familiar with any major DeFi protocols using DIA to secure a large amount of value.

Security should be our #1 priority for long-term sustainability, and IMO the additional assets we’d gain don’t outweigh introducing a relatively untested point of failure to the Sushi protocol.