Blend V1
  • Blend Documentation
  • ๐Ÿ“„Blend Whitepaper
  • ๐ŸงชMedia Kit
  • ๐Ÿš€Deployments
  • ๐Ÿ•ต๏ธโ€โ™‚๏ธAudits & Bug Bounties
  • ๐Ÿง‘โ€๐ŸญGithub
  • ๐Ÿ‘ฅUsers
    • General/FAQ
    • Choosing Pools
    • Lending-Borrowing
      • Lending
      • Borrowing
      • Liquidations
    • Backstopping
    • BLND Token
    • Auctions
  • ๐ŸŒŠPool Creators
    • General
    • Tutorial: Setting Up a Pool
    • Adding Assets
      • Risk Parameters
      • Interest Rates
      • Emissions
    • Pool Management
    • Selecting an Oracle
    • Setting Backstop Take Rate
    • Setting Max Positions
    • Backstop Bootstrapping
    • Required Infrastructure
  • ๐Ÿ“šTech Docs
    • General
    • Core Contracts
      • Emitter
        • Backstop Management
        • Blend Distribution
      • Backstop
        • Deposit Management
        • Drawing and Donating
        • Emission Distribution
      • Pool Factory
        • Lending Pool Deployment
      • Lending Pool
        • Fund Management
        • Liquidation Management
        • Emission Management
        • Interest Management
        • Pool Management
        • Bad Debt Management
        • Protocol Tokens
    • Guides
      • Deploying a Pool
    • Potential Improvements
Powered by GitBook
On this page
  • Known Issues
  • Recommended Improvements
Export as PDF
  1. Tech Docs

Potential Improvements

This page covers known issues and potential improvements that could be made to the codebase if a new version of blend is released.

Known Issues

Potential for "stuck" Interest Auctions

Due to a bug in interest auction fill logic, if an interest auction is live for 400 blocks, it becomes impossible to fill the auction. This should never happen in practice as filling the auction will be profitable past 300, however it can occur if no one is monitoring the auctions progress.

If the auction does become stuck the existing entry must expire before a new one can be created.

Potential for Unliquidatable Positions

Due to a lack of precision in the percent_liquidated parameter of the new_liquidation_auction()function (the parameter can only contain 3 digits representing whole percentages), it's possible for a user to be unliquidatable if the contract deems that their acceptable liquidation range is between 99% and 100%. In practice this requires quite extreme collateral and liability factors, as well as the user becoming undercollateralized extremely quickly, so it is quite unlikely. Furthermore, future price fluctuations will remove their position from this state.

Withdrawal Dequeuing Order

When a user dequeues a backstop withdrawal, the contract removes queued withdrawals from the front of the queue rather than the back. This results in the user's oldest queues (the one's closest to being unlocked or already unlocked) being dequeued rather than the newest ones.

Recommended Improvements

Add `load_pool()` Function

It's annoying to reconstruct current pool and reserve state from ledger entries. Future versions of the protocol should include a load_pool() function that returns all reserve data and configurations

PreviousDeploying a Pool

Last updated 10 months ago

๐Ÿ“š