Proposal: Update sOADA to properly calculate conversion price from on-chain data

Recently, both OADA and sOADA were integrated into the Lenfi platform as borrowable and collateral assets:

This was great to see, but the execution of sOADA integration has resulted in an extremely flawed outcome that is in fact seriously dangerous to anybody who wants to use sOADA on the platform.

Currently, the price data being referenced for sOADA is pulled from a single minswap v2 pool: https://minswap.org/pools/f5808c2c990d86da54bfc97d89cee6efa20cd8461616359478d96b4cfdb20ab9cafd79dc9f5960d1d9931a0ec337d4eb671b744e15915d91a0668efd

This pool has virtually zero liquidity in it. A single market sell of 100 sOADA will affect the pool price by over 60%. This creates HUGE liquidation risk.

There is no reason for liquidity pools to exist for this asset. There is no incentive to do so, and given the mechanics and incentives of the OADA system - external liquidity will likely never really arise on a DEX.

sOADA liquidity exists within the protocol itself. This is by design. sOADA holders unstake to OADA in the OADA UI. This will always be primary and deepest liquidity source, and should represent the most accurate price feed of sOADA on the market.

I really cannot understand why it was implemented as it currently is. It introduces huge risk and the integration is dead on arrival - nobody should touch it.

To fix this, Lenfi needs to source price data in a different way:

  • Calculate the current conversion rate from sOADA to OADA when unstaking:
    Optim Finance | SPO Bonds

  • Use that conversion rate to calculate the price when swapping OADA back to ADA on the splash stableswap:
    Splash Protocol

The calculation should like something like this, with current price data as an example:

Current conversion rate is 1 sOADA = 1.00727 OADA
Current price of OADA/ADA is 0.999445

1.00727 * 0.999445 = 1.00671096515

Something like this will be infinitely more useful and safe than the current integration. I hope the DAO will consider this and implement it as described.

  • Approve
  • Disapprove
  • Abstain
0 voters

An asset with what TapTools describes as $45 liquidity had a heat check then was approved??

Very interesting. While I prescribe to the ideology of “you make your own choices” (lending a volatile asset), it seems peculiar that this proposal is a retrospective one.

I do recall older comments in the channels regarding setting a minimum liquidity to avoid this (and by extension being voted in approval regardless of being within a tooth hairs skin of NO LIQUIDITY as measured by the established metrics we’ve used from day one until now)

An asset passed a temperature check with x votes, then passed on chain vote with y votes… nobody noticed this issue?

It occurs to me the lenders exactly knew and drooled at the thought… as an asset like this becomes active on AADA; who benefits?

However, it is proof of the choice of the votes being adhered to regardless of any reason or sense that is measurable.

1 Like

The intention of the proposal was to have it integrated with the liquidation pricing referencing the liquidity internal to the OADA system

It’s an issue of improper integration, for whatever reason. Liquidity exists but team decided to reference a dex pool instead, I guess because it is their “standard” integration process.