> For the complete documentation index, see [llms.txt](https://limitless.gitbook.io/ramm/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://limitless.gitbook.io/ramm/instrument-examples-and-usage/conditional-lending-pool-clp/managers-as-oracles.md). # Managers as Oracles No Third Party Oracles are needed in RAMM's CLP ### Why Managers As Oracles? There are no reliable oracles for long-tail assets. For ones that do exist, they are easily manipulated. Instead, using RAMM's managers as oracles is a straightforward incentive-compatible mechanism for pricing collaterals in the context of lending. Alignment stems from the fact that the system necessitates managers' 'skin-in-the-game' when they price the risk of collaterals. {% hint style="info" %} The mechanism outlined below simply adjusts the `maxBorrowableAmount` per unit collateral based on simple supply-demand dynamics. If more capital is supplied compared to the amount borrowed, supply>demand which lowers the price(`maxBorrowableAmount`) of the collateral. If more capital is withdrawn compared to the amount borrowed, supply\ The `maxBorrowableAmount` parameter represents a collateral's borrowing power 'agreed' by the managers. It replaces a third party price feed. `maxBorrowableAmount` is akin to an implied 'price' of the collateral as determined by the managers' collective **`longZCB`** demand. During the lifetime of a lending pool instrument, `maxBorrowableAmount` will adjust to account for the collateral's value as perceived by the managers. [Recall](/ramm/protocol-flow/post-approval.md) that whenever a manager issues **`longZCB`** the protocol supplies capital to the instrument, and whenever a manager redeems **`longZCB`** the protocol withdraws capital from the instrument. As a result, all else being equal, there is a bijective relationship between **`longZCB`** issuance and the utilization rate. We can then create a relationship between `maxBorrowableAmount` and the utilization rate(or equivalently, how much **`longZCB`** at time t u\_t, based on the central principle that a low utilization rate means both the managers(supplier) and borrowers(demander) deem `maxBorrowableAmount` low, and vice versa. {% hint style="info" %} 1. Manager is bullish(bearish) with the given collaterals and `maxBorrowableAmount` 2. Manager issue(redeems) **`longZCB`**, thereby supplying(withdrawing) to(from) the lending pool. 3. Utilization rate goes down(up). {% endhint %} For the following parameters, we can determine B\_T, or the `maxBorrowableAmount` for a lending pool at time T, as a function of all recorded utilization rate(urate) until time T. $$ \hat{B} := \text{initial} \ \texttt{maxBorrowableAmount} \ I\_t = \texttt{maxBorrowableAmount} \ \text{percentage increment at time T}\ u\_u:=upper threshold \ urate \u\_l:=lower threshold \ urate $$ $$ I\_t = \begin{cases} x& \text{if } urate \geq u\_u\\ -x & \text{if } urate\leq u\_l \ 0& \text{otherwise} \end{cases} $$ $$ 0\leq x \leq 1 $$ $$ B\_T = \hat{B}\prod\_{i=1}^T(1- I\_i) $$ In words, `maxBorrowableAmount` will decrement by x if the urate is above a threshold(when managers redeem and thus withdraw from the pool), and increment by x if the urate is below a threshold(when managers issue and thus supply to the pool). This relationship gives rise to some desirable properties > 1. Attack reslient, as borrowable amount increases in increments per unit time. > 2. When the pool is overdrawn, if the managers *don't* issue **`longZCB`** given the higher APR from a higher urate, `maxBorrowableAmount` will decrease. > 3. When the pool is underdrawn, if the managers *don't* redeem **`longZCB`** given the lower APR from a lower urate, `maxBorrowableAmount` will increase. > 4. When the managers' perceived value of collateral decreases, they redeem **`longZCB`**, which will increase `maxBorrowableAmount` over time. > 5. When the managers' perceived value of collateral increases, they issue **`longZCB`**, which will decrease `maxBorrowableAmount` over time. > 6. Overall, the process does not increase the action space for managers. They simply issue/redeem **`longZCB`** when they are bullish or bearish.
The dynamic is shown in the graph above. When managers *redeem* **`longZCB`** and utilization rate exceeds the upper threshold U\_u, `maxBorrowableAmount` will decrease. When managers issue **`longZCB`** and utilization rate exceeds the lower threshold U\_u, `maxBorrowableAmount` will increase. The more time spent under(over) the threshold, the more `maxBorrowableAmount` will change. ### Liquidations Based on B\_T, an auction will be triggered to liquidate the collateral of the borrower if $$ B\_T \* Collateral \ posted \leq BorrowAmount - liquidationBuffer $$