Liqwid price control mechanisms

Liqwid price control mechanisms


  1. Abnormal price patterns
    1.1 Introduction
    1.2 Possible reactions and remediation measures
    1.2.1 Hardcoded values
    1.2.2 Trailing price
  2. Market halting power for the Liqwid Core team
  3. Conclusion
    3.1 Upcoming Liqwid governance vote


1.1 Introduction

After the incident on January 10, 2024, when the Oracle price for DJED fluctuated from $1 to 0.001 and then to $8, it became evident that the Liqwid protocol cannot fully rely on any price feed providers, whether centralized or decentralized. As a result, Liqwid recognizes the imperative need for additional controls on the oracle data, which forms the basis for determining the prices of every asset listed on the platform.

1.2 Possible reactions and remediation measures

Once the protocol is confronted by such events like on January 10, it basically has 3 choices:

  1. To take the price as it is from the oracle,
  2. To modify it when the current price does not seem correct. There we can either determine:
  • hardcoded values (minimum value is called “Floor” and maximum value is called “Cap”),or
  • lagging values (where the current price is between its previous price and the new oracle price
  1. To block / halt the trading for a CNT

Figure: Overview of the different choices when confronted to abnormal prices
Picture2 3 Choices

1.2.1 Hardcoded values

Some assets have an intrinsic value which is “always” equal to its fair value or its market price.
Stablecoins are backed by $1 (either fiat-backed or token-backed) and the market is expected to see their price trading around $1.

Deviations are tolerated by the market participants as liquidity is fluctuating on the crypto market, but normally people do not accept (and even are not using/buying) any stablecoins having its price going below a certain value, or above another threshold. This event is usually the consequences of a so-called “de-peg” event which has also various causes.

Therefore, if the oracle price is not working adequately, where the price is way under or below $1, we can determine as control mechanisms a cap (= a maximum price) and a floor (= a minimum price).

Controlled price in Liqwid regarding the current price (Pi) are:

  • If Pi >= Cap, then Price = Cap
  • If Pi <= Floor, then Price = Floor
  • Otherwise Price = Pi

1.2.2 Trailing price

As we have witnessed many times in the crypto history, token prices can have some very high volatility induced by different factors, and some are more ephemeral than others (provoked or not).

During this short period of time where the price is deviating heavily from its historical value (or expected fair value), the mechanism of trailing price can be implemented to protect the protocol.

Trailing prices only happen when the assets price (after being controlled versus a second oracle – 1st line of defense) is trading between the corridors determined by the Cap & Floor (2nd line of defense).

The Trail price is determined by the maximum amount of % price change the Liqwid protocol wants to see happening in 1 or 2 minutes.

This control system protects against flash crashes induced by market exploit and reduces the price volatility in the short term (limited lagging in time), while it allows the price to converge to its oracle price over time.

Figure: Visual example of a trail price vs Oracle price having extreme volatility over time


As demonstrated in previous instances, a prompt response is crucial to safeguard Liqwid assets. In a situation akin to the events of January 10, 2024, a decision to halt the markets must be made within 5 to 15 minutes to minimize risk exposure and control potential damage.

Until better and more automated oracle and control mechanisms are in place, Liqwid will rely on human intervention as a last resort. The only other alternative would be that Liqwid built its own oracle/price data feeds and controls based on on-chain data. As this solution is not feasible in the short term, the ability to halt trading in specific market conditions to ensure stability and fairness is essential.

In this regard, implementing a standardized process, known as the ‘kill switch,’ to halt the batching of Liqwid markets proves to be the most effective solution available to us.

In our view, the “Kill switch” process would work as such:

  • Activated by 1 single person from the Core Team, incl. audit trail (time, date, name)
  • Can stop all markets (Future: selected market)
  • Every activation/resume of the kill switch triggers some alert sent to the team

Furthermore, this process is well-documented, known to the Liqwid Core team, easily accessible to different individuals, and carries a low risk of errors during operation.


The Liqwid Oracle control mechanisms play a crucial role in safeguarding borrowing and lending markets. Through the integration of various price sources, alongside hardcoded values and/or trailing prices in the event of oracle failures, we are confident that the Liqwid protocol will exhibit enhanced resilience.

Business continuity and swift disaster recovery are paramount for the Liqwid Core team. Therefore, the ability to activate the kill switch, which halts market batching and prevents the validation of transactions with incorrect prices on the blockchain, is imperative.

It is noteworthy that the Core team also possesses the “Pause Guardian” multi-sig, capable of instantly halting the protocol with the agreement of four signatories. In contrast, the kill switch can be triggered by a single individual and is readily accessible, akin to a fire extinguisher.

3.1. Upcoming Liqwid governance vote

We recommend voting in favor of the following proposal in the Liqwid governance:

  • Implementation of the cap and floor system for Liqwid prices.
  • Introduction of the trailing price system for Liqwid prices.
  • Establishment of a kill switch system.
  • Granting power and authority to the Core Team to utilize the kill switch and take necessary actions to mitigate risks and prevent protocol disasters.

All these proposed measures aim to ensure the prompt recovery of the protocol and/or sustain business continuity in the aftermath of a failed oracle update.

:envelope_with_arrow: Do you support this proposal?

    • Yes, I support this proposal.
    • No, I do not support this proposal.

0 voters

As this proposal states, the core team is confident that the measures of trailing price and utilization of multiple oracles will give the protocol good resilience against repeat scenarios.

It seems from your description that the kill-switch essentially IS the pause-guardian simply without the multi-sig requirement. Would love to see a specific roadmap or plan with clear objectives that lead to the removal of the kill switch.

I support this tentatively due to necessity born out of Cardano’s infant oracle scene, but it should be abandoned ASAP or reverted back to multi-sig only with multi-sig control being expanded as time goes by.


I agree and think that will certainly be the plan long term. We are focused on completing testing of the recommended oracle hardcap bounds and trailing price security features.


I think that activation of the kill switch should require at least two signatories not just one.

1 Like

Is it feasibility to outsource the oracle services to native oracle service providers like Charli3 and/or Orfax?

1 Like

Liqwid already uses Charli3 for ADA, DJED, iUSD and SHEN markets yes. The mechanisms we are discussing in this forum post and vote has passed to have implemented on the Liqwid oracle contract’s offchain are a 2nd layer of defense in the critical event faulty oracle price data is approved through a third party oracle service provider (which has happened multiple times in Ethereum DeFi). These features would protect Liqwid protocol in the scenario where the 3rd party oracle service provider fails, these features are not themselves oracles and they do not replace Liqwid’s requirement for C3/Orcfax’s oracle services.

1 Like