Closed dapp-whisperer closed 1 year ago
Just wrapped a veeeery productive, 1.5hr long meeting with Guardrail. Went over each one of the alerts on our monitoring plan and identified the specifics on how to monitor them based on function calls, events, aggregation of data, etc..
Specifics on custom monitoring:
getTCR
function takes the price as input and the system's latest price is not updated unless fetchPrice is called which ocurrs upon user interactions. So the TCR may have changed due to price fluctuations but, unless a player interacts with the system, the system's state data won't reflect this change. For this reason, Guardrail is going to take constant snapshots of the totalDebt and totalCollateral (which are available) and will use a constant snapshot of the CL price feed directly to estimate the TCR. This could also be done through a proxy contract but they have access to the three data points and can aggregate via a query off-chain.baseRate
. Since we removed the baseRate updates from borrowing operations, only redemptions change the base rate value. This means that, at any given time, even if the base rate virtually decayed to 0, the latest stored base rate will always be above 0. So reading the value from chain doesn't work, to get an estimate of the real time base rate you will have to look at the time stamp of the last base rate update (from the event emitted) and estimate the current rate based on the time elapsed since.It was decided to pursue Guardrail as the economical and parameters monitoring solution for eBTC and investigate a different engagement with Hypernative for Security monitoring (proactive).
Investigate alternative solutions for web3 monitoring