Atlendis v2
  • πŸ‘‹Introduction
  • πŸ—žοΈWhitepaper
  • πŸ”“Safety & Audit
  • Protocol
    • 🎨What Sets Atlendis Apart
      • RCL Lending Pools
      • Rate Discovery
      • Non Fungible Positions
    • 🏦Atlendis Borrowers
    • πŸ›£οΈUse Cases
      • Invoice Financing
      • Ramps and Cash Advances
      • Revenue Based Financing
      • Trade Financing
      • Buy Now Pay Later
      • Emerging Market Credit
    • ⚠️Risk Management
  • User manual
    • πŸ§‘Lender
      • πŸ§™Lender Actions
      • ❓Lender FAQ
      • ⏩Tutorial
    • 🏒Borrower
      • πŸ€Έβ€β™‚οΈBorrower Actions
      • 🏦Borrower FAQ
      • πŸ”©Integration
  • Developers
    • πŸ€“Protocol Overview
    • πŸ‘©β€πŸ’»Core concepts
      • Order Book Implementation
      • Position accounting vs. Pool accounting
      • Interests accrual and position accounting granularity
    • πŸ’»Technical integration
      • Deployment procedures
      • Protocol gas consumption
      • Tokens integration considerations
    • πŸ“‘Smart contract interfaces
      • Revolving Credit Line
        • IRevolvingCreditLine
        • IRCLBorrowers
        • IRCLGovernance
        • IRCLLenders
        • IRCLState
      • Roles Manager
        • IRolesManager
        • IStandardRolesManager
      • Error messages
    • ↗️Deployed Contracts
    • πŸ“ˆAtlendis Gateway
  • Governance
    • πŸ§‘β€βš–οΈGovernance
    • πŸ‘›Multisig
  • glossary
    • πŸ§‘β€πŸ«Core concepts
    • πŸ“ŠFrontend Indicators
  • Legal
    • βš–οΈTerms of Use
    • βš–οΈLegal Notice
    • βš–οΈPrivacy Policy
Powered by GitBook
On this page
  1. Developers
  2. Technical integration

Protocol gas consumption

Protocol usability

By construction, the Atlendis Protocol iterates on the multiple small liquidity pools that represent rate ticks in the pools order books.

Iterating in Solidity is always costly, especially when it involves modifying storage variables a lot like it's the case in the Atlendis Protocol. As noted in the report written by Runtime Verification after their audit, iterating on a high number of ticks could actually be an attack vector, since a malicious lender could deposit very small amounts in all of a pool's tick, forcing the borrower to iterate over all of them to take a loan. In some cases, it is even not excluded that a transaction could go past a block gas limit, and fail for that reason.

When developing the Atlendis Protocol, the Atlendis Labs team has been very aware of that potential issue, and wanted to make sure that the protocol would be usable, and would have a reasonable gas consumption. It is the reason why the minimum rate, maximum rate and rate spacing parameters have to be set during pool creation. These parameters limit the rates at which a lender can deposit, and thus limits number of ticks, framing the maximum gas consumption of the borrow and repay actions.

There is a fine balance to be found between having a lot of ticks, which means higher granularity and finer liquidity management but higher gas costs, and having fewer ticks, which is the opposite. For that reason, and after discussions with our partners, we agreed on methodology to choose these pool parameters. The methodology described above will be applied each time a new pool creation proposal is introduced, as we want to be mindful of the usability of the protocol :

  • agree on a maximum acceptable gas cost for the most gas intensive function - borrow

  • making gas measurements to determine approximatively the cost of iterating over a single tick

  • using the result of the two precedent points to determine an ideal number of ticks

  • choosing the minimum rate, maximum rate and rate spacing, in accordance with business requirements accordingly

PreviousDeployment proceduresNextTokens integration considerations

Last updated 1 year ago

πŸ’»