Gearbox Analytics : Meet Third-Eye Analytics
It’s been over a year since Gearbox Credit Accounts were mined, and with CAs came up a whole new kind of data. There was the obvious user data that can be, and has always been, looked at but there’s more to data than what meets the eye. This is where Third Eye comes in. Third Eye is Gearbox’s internal monitoring and analytics tool that reports on everything from Risk to User actions, from detection to reporting via notifications. It is our in house protocol intelligence centre that is always open. Read below to learn about it in detail.
To learn about just the user and performance data, you can refer to our protocol update below:
This is the first time that we introduce Third-Eye Analytics(TEA) to the world and this is done with a purpose. TEA has been in development before V1 was even launched and today, has matured enough to open-source its code and allow interested parties to contribute/indulge in this tool. This article explains our rationale behind third-eye, its features, and the use cases covered. The article is a first by our dev sided contributor Harsh and will be a more technical read. So read on to know more.
Why Third-Eye Analytics?
Even before since Gearbox V1 was in the works, our goal was to create an analytics webpage that provides insights not available on the main application or Etherscan.
For the users, this meant a webpage that could enable users to check the details of their closed accounts, compare their performance with other users, and have graphs for monitoring changes in different parameter values
As for the gearbox Risk committee, this meant to make arbitrary queries on this data to determine various health checks, bad debt, and liquidation efficiencies. This was to enable proactive movement to mitigate risks. By enabling this, we also increase the efficiency of our partnership with Risk DAO. Basis the queried data, internal risk contributors can determine exactly where the risk lies and using Risk DAO’s dashboard and inputs can move quickly to resolve the same.
Initially, we looked at Graph as an option for a similar intelligence system, but the exhaustive set of parameters we wanted wasn’t possible with it, the group of aggregations available was limited, and JSON output made searching for insights slower than a tabular format. Given this specification and scope for later adding more complex and interdependent insights, we settled on creating an in-house service for calculating all the needed parameters and getting them in the format we wanted. This service has evolved into third-eye today.
You can find all the contract addresses here for easier access to various data sources: https://dev.gearbox.fi/
TEA Architecture
Third-eye is written in golang using a dependency injection framework that eliminates the need for a global state and allows design flexibility. It models different types of contracts as sync adapters; each adapter can sync in isolation if its dependency adapters have synced for that block. Isolation allows adapters to be rolled back without affecting the whole application, requiring only the rollback of its dependent adapters.
Sync adapters can have one of two triggers for getting the data
- Event Triggers
- Query Triggers(queried at specific intervals).
Event-triggered adapters: Includes AddressProvider, ContractRegister, CMs, Pools, and ChainlinkPriceFeeds. Third-eye uses an adapter kit that stores independent adapters in the same level(allowing parallelization) and dependencies in the previous levels.
Query-triggered adapters: Mainly used for getting the prices of tokens that don’t emit an event on change in value. These include yearn, curve LP and convex LP tokens. These adapters use multicall(maker contract live on-chain, allowing bundling of calls and getting the response in a single call) to reduce RPC calls.
You can find definitions for these adapters in our models.
Third-eye then groups the fetched data by block number and stores it in a block repository, which syncs to the database. Once we have all the data for a block number, the debt engine comes into play. It receives these new inputs, finds credit accounts whose state has changed, and calculates their profit&loss, repayment amount, total value, and health factor. Snapshots of accounts’ new state are saved for creating graphs and retrospecting this data.
Interested readers can review the detailed architecture of third-eye.
Features
For this architecture to provide utility, there’s certain applications of the same that have been developed. The same are called features and enable easier functioning in various ways. Some of the most notable ones are:
Tenderly assisted call parsing: Gearbox emits a generic event(ExecuteOrder) whenever an action on third-party protocols occurs, like swap on AMM, deposit/withdrawal on any Vault/Pool, LPing on curve/convex, etc. This event only tells us which user made the call on which protocol. But the call data for this operation has yet to be discovered. Using Tenderly, we filter the inner call to the underlying protocol and parse the needed data. All these user actions are available on the charts webpage.
Notifications: The debt engine uses updated values in each block to calculate the updated state of credit accounts. This way, we can detect the exact block where the health factor of the account became less than 10K, turning borrowed amount into bad debt. Third-eye notifies on bad debt and whenever any liquidation happens.
DAO operations and treasury: Gearbox treasury gets funds in two ways: 1) Revenue streams(APY spread and liquidation Fee) and 2) Any raises against tokens. Third-eye tracks the closing balance of the treasury each day due to both operations. Apart from keeping an eye on treasury, DAO operations are also monitored and shown on the charts webpage for transparency.
Charts server: Third-eye’s job is fetching data, calculating missing and insightful parameters, and saving them in a needed format. It is complemented by a web server, which exposes REST endpoints for charts.gearbox.fi. These endpoints are p&l account ranking, cm, pool, account, and treasury details.
Improvements over the year
A year in development, the journey of this service over the period can only be understood by understanding where it started from and where we are today.
Tracking direct token transfers: Gearbox doesn’t restrict users from directly sending funds to the accounts. No event is emitted on gearbox-related smart contracts whenever this happens, making it hard to track such occurrences. To solve this, third-eye uses the accountManager adapter that fetches transfer events on all supported token contracts. It then filters all the already-seen transactions via credit manager adapters to remove known token transfers.
Throttling debt calculation: Those who have been with us since the last year’s testnet would know that users opened multiple accounts to test gearbox v1 on kovan. Users stress-tested the gearbox by doing many actions in a short period. This also tested third-eye’s debt engine and made us question what should be the frequency of taking accounts state snapshots to prevent DB from growing too fast(for kovan, it reached 20M+ entries in 5 months). We found most of the subsequent snapshots have a delta of less than 1% and decided to throttle saving debt snapshots based on these rules. Throttling kept the debt size in check while saving all vital snapshots.
DataStore optimizations: An ever-increasing number of debt snapshots requires better indexing tactics. We currently have debts stored as clustered index tree, drastically reducing the query time for rankings per 7/30 days. Indexing and rewriting specific tables have improved the overall response time of the charts server’s endpoints.
Open sourcing and welcome to Third Eye
Third-eye was the first backend project we worked on at gearbox. It has catered to our needs and has been evolving based on the changing demands. As the gearbox protocol has matured, the team has built several backend projects regarding testing, liquidations, monitoring, etc. Today we are open-sourcing third-eye for you. You can access it on GitHub.
At the moment, this will largely be an internal application. The goal is to increase the transparency on dev efforts to help people understand what we are building and contribute by giving inputs on what more parameters they would like to see. You can provide these inputs on Github itself or like always, in our discord. :)
We will have a similar approach towards other projects too. Once the devs believe the code is in a stable and secure position, we will open-source them for feedback and contributions. Common gearbox functionalities and utilities for other developers are available at Golang SDK. You can use these to create something you believe will add meaningful value. Hop into our discord to propose what you want to build for possible grants and DAO feedback.
Get GEARed up! If you would like to earn passively, remember to LP into our Lending Pools to earn GEAR. If you want to take leverage as Ninja just ping us on Discord or post on the forum. Otherwise you can always get involved with the DAO — discuss, research, lead and share. Call contributors out on their bullshit and collaborate on making things better.
Here is how you can follow developments:
- Website: https://gearbox.fi/
- dApp: https://app.gearbox.fi/
- User Docs: https://docs.gearbox.finance/
- Developer Docs: https://dev.gearbox.fi/
- Forum: https://gov.gearbox.fi/t/start-here-forum-rules/
- Blog: https://medium.com/@gearboxprotocol
- Github: https://github.com/Gearbox-protocol
- Twitter: https://twitter.com/GearboxProtocol
- Snapshot page: https://snapshot.org/#/gearbox.eth
- And, of course, the DAO working docs:
