diff --git a/docs/Protocol/data-sources.md b/docs/Protocol/data-sources.md index 18bec0b..967c268 100644 --- a/docs/Protocol/data-sources.md +++ b/docs/Protocol/data-sources.md @@ -11,11 +11,12 @@ The data sources defined by a market can be static or dynamic, depending on the ## Static Data Sources -Our implementation of a data market serves datasets to render a live Uniswap V2 dashboard. Further details about the data source configuration and snapshot schema can be found in the following section of our documentation: +Our implementation of a data market serves datasets to render live Uniswap V2 and Aave V3 dashboards. Further details about the data source configurations and snapshot schemas can be found in the following sections of our documentation: * [Building with Powerloom -- Uniswap V2 Dashboard](/docs/build-with-powerloom/use-cases/existing-implementations/uniswapv2-dashboard/) +* [Building with Powerloom -- Aave V3 Dashboard](/docs/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/) -Continuing with this example, you can explore the data sources list defined as part of the Uniswap v2 specific configuration in the [`snapshotter-configs`](https://github.com/Powerloom/snapshotter-configs/blob/fcf9b852bac9694258d7afcd8beeaa4cf961c65f/projects.example.json#L1-L11) repository. +Continuing with the Uniswap V2 example, you can explore the data sources list defined as part of the Uniswap v2 specific configuration in the [`snapshotter-configs`](https://github.com/Powerloom/snapshotter-configs/blob/fcf9b852bac9694258d7afcd8beeaa4cf961c65f/projects.example.json#L1-L11) repository. ```json reference https://github.com/Powerloom/snapshotter-configs/blob/fcf9b852bac9694258d7afcd8beeaa4cf961c65f/projects.example.json#L1-L11 diff --git a/docs/build-with-powerloom/snapshotter-node/architecture.md b/docs/build-with-powerloom/snapshotter-node/architecture.md index a6ba91e..7f6830f 100644 --- a/docs/build-with-powerloom/snapshotter-node/architecture.md +++ b/docs/build-with-powerloom/snapshotter-node/architecture.md @@ -17,6 +17,7 @@ Use case-specific logic for generating snapshots and other configurations are av * DEXs like Uniswap v2, Quickswap * Bridges like bungee.exchange, Owlto finance +* Lending markets like Aave and Compound The architecture has been designed to facilitate the seamless interchange of configuration and modules. Adapting the system to different use cases is as straightforward as changing a Git branch. @@ -25,11 +26,15 @@ You can observe the corresponding branches within [snapshotter-configs](https:// #### Snapshotter Computes * `eth_uniswapv2`: Pooler implementation for the Uniswap v2 dashboard * `eth_uniswapv2_lite`: Pooler implementation for the Uniswap v2 dashboard but without the calculation of complex aggregate data points from scratch. +* `aave`: Pooler implementation for the Aave v3 dashboard +* `aave-lite`: Pooler implementation for the Aave v3 dashboard but without the calculation of complex aggregate data points from scratch. * `zkevm_quests`: Implementation for Quests on Polygon zkEVM #### Snapshotter Configs * `eth_uniswapv2_5_pairs`: Pooler lite mode config with only 5 chosen Uniswap v2 pair contracts * `eth_uniswapv2`: Pooler config with only 180 Uniswap v2 pair contracts +* `aave`: Pooler config with all Aave v3 asset contracts +* `aave-lite`: Pooler config to be used with the aave-lite compute branch * `zkevm_quests`: Config for Quests on Polygon zkEVM ### Configuration Files diff --git a/docs/build-with-powerloom/snapshotter-node/full-node/health-tracking.md b/docs/build-with-powerloom/snapshotter-node/full-node/health-tracking.md index 6e238db..b735a69 100644 --- a/docs/build-with-powerloom/snapshotter-node/full-node/health-tracking.md +++ b/docs/build-with-powerloom/snapshotter-node/full-node/health-tracking.md @@ -127,7 +127,7 @@ curl -X 'GET' \ { "epochId": 12, "submittedSnapshotCid": "snapshotcid", - "submittedSnapshot": {} + "submittedSnapshot": {}, "finalizedSnapshotCid": "finalizedsnapshotcid", "finalizedSnapshot": {}, "reason": "reason for incorrect submission" diff --git a/docs/build-with-powerloom/use-cases/building-new-usecase/extending-uniswapv2-dashboard.md b/docs/build-with-powerloom/use-cases/building-new-usecase/extending-uniswapv2-dashboard.md index c53f9ee..f8e2a4c 100644 --- a/docs/build-with-powerloom/use-cases/building-new-usecase/extending-uniswapv2-dashboard.md +++ b/docs/build-with-powerloom/use-cases/building-new-usecase/extending-uniswapv2-dashboard.md @@ -1,9 +1,9 @@ --- sidebar_position: 0 --- -# Extending Pooler +# Extending Uniswap V2 dashboard usecase -This documentation provides a step-by-step guide for developers looking to extend the functionality of the UniswapV2 Dashboard, specifically focusing on implementing new data points. The goal is to empower developers to enhance the dashboard with custom features, making it a valuable tool in hackathons and blockchain analytics. +This documentation provides a step-by-step guide for developers looking to extend the functionality of the UniswapV2 Dashboard use case, specifically focusing on implementing new data points. The goal is to empower developers to enhance the dashboard with custom features, making it a valuable tool in hackathons and blockchain analytics. ## Extending with New Data Points diff --git a/docs/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/_category_.json b/docs/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/_category_.json new file mode 100644 index 0000000..d9552c7 --- /dev/null +++ b/docs/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/_category_.json @@ -0,0 +1,8 @@ +{ + "label": "AaveV3 Dashboard", + "position": 1, + "link": { + "type": "generated-index", + "description": "AaveV3 Dashboard Implementation using Powerloom protocol" + } + } \ No newline at end of file diff --git a/docs/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/data-points.md b/docs/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/data-points.md new file mode 100644 index 0000000..e440b39 --- /dev/null +++ b/docs/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/data-points.md @@ -0,0 +1,110 @@ +--- +sidebar_position: 1 +--- + +# Datapoints + +![AaveV3 Dashboard Powerloom](/images/aavev3-dashboard-powerloom.png) + +In Aave V3-Pooler, data points are specific, quantifiable elements derived from Aave V3 lending activities. +Each snapshot inherits `Snapshot Base` which looks something like this +```python reference +https://github.com/PowerLoom/snapshotter-computes/blob/6fb98b1bbc22be8b5aba8bdc860004d35786f4df/utils/models/message_models.py#L9-L17 +``` + +The following type of Base Snapshots are generated for the Aave V3 dashboard: + +**1. Asset Metrics Snapshot:** + +The Asset Metrics refer to the total supplied and borrowed amounts, supply and borrow interest rates, and the indices used to compute future rate changes. +The asset snapshot looks something like this: + +```python reference +https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/models/message_models.py#L26-L42 +``` +* **1a. AaveSupplyData and AaveDebtData** + + The nominal token amount and the token amount in terms of USD at the time of snapshotting: + + ```python reference + https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/models/data_models.py#L65-L72 + ``` +* **1b. AssetDetailsData** + + Additional asset details include the maximum loan-to-value ratio, liquidation information, the asset's reserve factor, borrow/supply caps, and available eMode options. + + For further information, please see the Aave V3 Protocol [Documentation](https://docs.aave.com/risk/asset-risk/risk-parameters). + + ```python reference + https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/models/data_models.py#L25-L34 + ``` + +* **1c. RateDetailsData** + + Additional rate details describing the interest rate strategy for the asset. + + For further information, please see the Aave V3 Protocol [Documentation](https://docs.aave.com/risk/liquidity-risk/borrow-interest-rate). + + ```python reference + https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/models/data_models.py#L37-L45 + ``` + +**2. Volume-by-Action Snapshot** + +The asset's total volume-by-action for the Epoch, and the corresponding events for each action emitted by the blockchain. +The volume-by-action snapshot looks something like this: + +```python reference +https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/models/message_models.py#L91-L98 +``` + +* **2a. volumeData** + + The total nominal token volume and the volume in terms of USD at the time of snapshotting: + + ```python reference + https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/models/data_models.py#L92-L94 + ``` + +* **2b. liquidationData** + + Additional details describing a liquidation action: + + ```python reference + https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/models/data_models.py#L117-L122 + ``` + +These base snapshots are used as the data source for higher-order aggregates. These aggregates are then used to generate the data points present in the Aave V3 Dashboard. Refer to [data-composition](/docs/protocol/data-composition) for more details on how data points are composed. + +The following aggregate snapshots are generated by AaveV3-Pooler using base snapshots. + +**1. Top Assets by Marketshare Snapshot:** All assets are organized by the total market share on the protocol. The top assets by marketshare snapshot look something like this: + +```python reference +https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/models/message_models.py#L55-L69 +``` + +**2. 24 Hour Volume-by-Action Snapshot:** 24-hour volume-by-action for each asset per Epoch. The 24-hour volume-by-action snapshot looks something like this: + +```python reference +https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/models/message_models.py#L101-L107 +``` + +**3. Top Assets by 24 Hour Volume Snapshot:** All assets are organized by total, 24-hour total volume-by-action. The top assets by volume snapshot looks something like this: + +```python reference +https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/models/message_models.py#L110-L128 +``` + +**4. 6 Hour Average Rate Snapshot:** Average supply and borrow rates over the previous 6 hours per Epoch. The 6-hour rate snapshot looks something like this: + +```python reference +https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/models/message_models.py#L82-L88 +``` + +**5. 24 hours Total Market Stats Snapshot:** 24-hour stats for the entire Aave lending market. The 24-hour stats snapshot looks something like this + +```python reference +https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/models/message_models.py#L72-L79 +``` + diff --git a/docs/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/index.md b/docs/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/index.md new file mode 100644 index 0000000..dc713d8 --- /dev/null +++ b/docs/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/index.md @@ -0,0 +1,24 @@ +--- +sidebar_position: 0 +--- + +# Introduction + +## Pooler - AaveV3 Data Market + +Powerloom's AaveV3 dashboard is an [extension](/docs/build-with-powerloom/use-cases/building-new-usecase/extending-uniswapv2-dashboard) of the Pooler framework. Its design is similar to the [UniswapV2](/docs/build-with-powerloom/use-cases/existing-implementations/uniswapv2-dashboard/) dashboard use case. The data network is powered by [Snapshotters](/docs/build-with-powerloom/snapshotter-node/introduction) who capture critical data points from Aave's on-chain Smart Contracts. This data is then processed, aggregated, and displayed on the dashboard to provide users of the Aave protocol with actionable metrics. This implementation is a testament to the composable nature of Pooler and the Powerloom data network's flexibility in capturing a diverse range of data points. + +The Dashboard is hosted at [aave-v3.powerloom.io/](https://aave-v3.powerloom.io/) + +### Data Points and Aggregated Metrics + +Data points are essential elements that serve as the foundational units upon which base snapshots are built. In the Aave protocol, they capture key information about loans, such as the total supplied and borrowed amounts, interest rates, and asset prices at the time of the lending. These base data points are snapshotted and then aggregated by AaveV3-Pooler to provide broader loan market statistics & insights, such as 24-hour lending/borrowing volumes and historical APR rates. Due to their inherent complexity, participants may find lending markets challenging to navigate. Access to actionable metrics is important for users seeking to deploy their capital efficiently and at the appropriate risk levels. + +--- + +### Development and Extension + +The Pooler framework builds upon the modular architecture of a Snapshotter Node and enables extensions and custom use case implementations. A developer can extend the pooler compute files found in [snapshotter-computes](https://github.com/PowerLoom/snapshotter-computes/tree/aave) and config files found in [snapshotter-configs](https://github.com/PowerLoom/snapshotter-configs/tree/aave) to build their own custom use case implementations. + +The documentation has a dedicated section that discusses further implementation and use-case extensions. +Check out our guide on [Setup and Extension](/docs/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/setup-and-extension.md). diff --git a/docs/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/setup-and-extension.md b/docs/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/setup-and-extension.md new file mode 100644 index 0000000..8626527 --- /dev/null +++ b/docs/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/setup-and-extension.md @@ -0,0 +1,140 @@ +--- +sidebar_position: 1 +--- + +# Setup and Extension + +This section will help you set up a full node to participate in the Powerloom Aave V3 data market and run your personal dashboard. At the end of this guide, you will find instructions on extending the current Aave V3 implementation with additional data points. + +## Full Node Setup + +:::tip +Prerequisite: Ensure that the minimum requirements are met by the system on which it is to be deployed, which is located under the **System Requirements** section of the [Full Node - Getting Started](/docs/build-with-powerloom/snapshotter-node/full-node/getting-started.md) page. +::: + +1. **Cloning the Deploy Repo** - Clone the repository against the `aave` branch. Open the terminal and run the below command to clone the deploy repo in a directory named `powerloom_deploy`. + ```bash + git clone https://github.com/PowerLoom/deploy.git --single-branch powerloom_deploy --branch aave && cd powerloom_deploy + ``` + +2. **Configuring The Node** - Copy `env.example` to `.env`. +- Ensure the following required variables are filled: + - `SOURCE_RPC_URL`: The URL for the Ethereum RPC (Local node/Infura/Alchemy) service. + - `SIGNER_ACCOUNT_ADDRESS`: The address of the signer account. This is your whitelisted address on the protocol. **Using a burner account is highly recommended** + - `SIGNER_ACCOUNT_PRIVATE_KEY`: The private key corresponding to the signer account address. + - `PROST_RPC_URL`: The URL for the PROST RPC service. + - `PROTOCOL_STATE_CONTRACT`: The contract address for the protocol state. + - `RELAYER_HOST`: The host address for the relayer. + - `NAMESPACE`: The unique key used to identify your project namespace + - `PROST_CHAIN_ID`: The chain ID for the PROST RPC service. + - Optionally, you may also set the following variables: + around which all consensus activity takes place. + - `POWERLOOM_REPORTING_URL`: The URL for reporting to PowerLoom. + - `IPFS_URL`: The URL for the IPFS (InterPlanetary File System) service in HTTP(s) (e.g. `https://ipfs.infura.io:5001`) multiaddr format (e.g. `/dns/ipfs.infura.io/tcp/5001/https`) + - `IPFS_API_KEY`: The API key for the IPFS service (if required). + - `IPFS_API_SECRET`: The API secret for the IPFS service (if required). + - `SLACK_REPORTING_URL`: The URL for reporting to Slack. + - `WEB3_STORAGE_TOKEN`: The token for Web3.Storage. You can generate or retrieve this token from your [API tokens page](https://web3.storage/tokens/?create=true) after signing up for a free plan at web3.storage. + +3. **Running The Node** +- Run the following command (ideally in a `screen`) and follow the instructions. + ```bash + ./build.sh + ``` + +4. **Displaying the Dashboard** +- Once all of the services are up and running, the front-end can be accessed via [Pooler Frontend](https://github.com/PowerLoom/pooler-frontend/tree/aave) to see an Aave V3 summary data dashboard similar to the [PowerLoom Aave V3 Dasboard](https://aave-v3.powerloom.io/). + - The front-end does not come packaged as part of the Aave deploy repository and will need to be run separately. The Front-end deployment instructions can be found [here](https://github.com/PowerLoom/pooler-frontend/tree/aave?tab=readme-ov-file#powerloom-pooler-product). + - The dashboard's `Synced by` section displays the time of the last snapshot taken, indicating if your snapshotting is falling behind. + +## Extending the Aave V3 Implementation + +:::tip +This section will utilize core concepts explained in the [Closer Look at Snapshots](/docs/build-with-powerloom/use-cases/existing-implementations/uniswapv2-dashboard/closer-look-at-snapshots) section. It is strongly recommended that you review this page before extending the Aave use case. +::: + +### Development Node Setup + +1. **Forking the Computes and Config templates** - For an optimized development process, it's recommended to fork the templates [snapshotter-computes](https://github.com/PowerLoom/snapshotter-computes/tree/aave) and [snapshotter-configs](https://github.com/PowerLoom/snapshotter-configs/tree/aave). Our system utilizes the Git submodule architecture to manage these components efficiently. For a deeper understanding of how these elements integrate and function within our larger system, please refer to our [architecture documentation](/docs/build-with-powerloom/snapshotter-node/architecture.md). This approach ensures a streamlined and cohesive development workflow. + + - Aave V3 Snapshotter Configs: https://github.com/PowerLoom/snapshotter-computes/tree/aave + - Aave V3 Snapshotter Computes: https://github.com/PowerLoom/snapshotter-configs/tree/aave + + Once the above branches are forked, you should have the two repositories in your profile. + +2. **Deploy the Development Node** - Detailed instructions for configuring the Aave V3 use case for development can be found in the [Powerloom Deploy](https://github.com/PowerLoom/deploy/tree/aave?tab=readme-ov-file#instructions-for-code-contributors) GitHub repository. + + - Ensure that the correct Config and Computes submodules are provided in the `SNAPSHOT_CONFIG_REPO` and `SNAPSHOTTER_COMPUTE_REPO` entries in the `.env` file. These must be changed if you have chosen to fork the submodule repositories as they are set to the Powerloom URLs by default. Additionally, ensure the correct branch names are provided in `SNAPSHOT_CONFIG_REPO_BRANCH` and `SNAPSHOTTER_COMPUTE_REPO_BRANCH` entries if they have been changed. + +3. **Run the Node** - It is recommended to run the full node before any extensions are made to ensure the setup is done properly. + ```bash + ./build-dev.sh + ``` + +### Preloaders + +Most on-chain data used by the current Aave V3 use case is retrieved using [Preloaders](docs/Protocol/Specifications/Snapshotter/preloading.md). These processors run before the base snapshots and are computed to reduce redundant queries on the Aave Smart Contracts. The Aave protocol stores data for *all* assets in their Smart Contracts, so preloaders are particularly useful when gathering data for this use case. Any base snapshot extension of the current implementation may find that the required on-chain data has already been gathered by a preloader. See the [Snapshot Generation](docs/Protocol/Specifications/Snapshotter/snapshot-build.md) page for more information on "how base snapshots are built". + +There are two important preloaders to be aware of: + +1. **Bulk Asset Data Preloader** +```python reference +https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/preloaders/asset_data/preloader.py#L10-L34 +``` + +2. **Bulk Events Preloader** +```python reference +https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/preloaders/volume_events/preloader.py#L9-L33 +``` + +Both of these preloaders retrieve on-chain data and then store it locally in Redis for [later use](https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/core.py#L93-L121) by the base snapshot processors' `compute` functions. The data models describing the data gathered by the `BulkAssetDataPreloader` can be found [here](https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/models/data_models.py#L9-L45). The list of event emissions gathered by the `BulkVolumeEventsPreloader` can be found [here](https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/models/data_models.py#L9-L45). + +Visit the [Data Points](/docs/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/data-points.md) section for a complete list of currently available base snapshots. + +### Adding an Aggregate Snapshot + +For this example, we will add a 6-hour volume-by-action aggregate using the 24-hour volume aggregate as a reference. The data for the 24-hour volume aggregate is already retrieved by the `BulkVolumeEventsPreloader` and processed using the `AggregateSupplyVolumeProcessor` as seen in this [compute](https://github.com/PowerLoom/snapshotter-computes/blob/aave/aggregate/single_aave_volume_24h.py#L108). + +1. **Create the Aggregation Worker Processor**: + + In the `aggregate/` directory of your forked `snapshotter-computes` repository, create a Python file containing your new processor. + - Name the file something like `single_aave_volume_6h.py` + - For now, this will be used as a placeholder and filled in with the processor's logic in later steps. + - Visit the Aggregate Snapshots section of the [Snapshot Generation](docs/Protocol/Specifications/Snapshotter/snapshot-build.md) page for more information on Aggregate Processors + +2. **Configure Aggregation Worker**: + + In the `aggregator.json` file of your forked `snapshotter-configs` repository, add a new entry for your aggregation worker class. This class will be responsible for handling the new data aggregation task. + - Define the `project_type` as something like `single_aave_volume_6h`. + - Set `aggregate_on` to `SingleProject` since we will extend the current SingleProject 24-hour implementation. + - Under `processor`, specify the module and class name of your new processor created in Step 1. + + ```json + { + "config": [ + // ... existing configurations ... + { + "project_type": "single_aave_volume_6h", + "aggregate_on": "SingleProject", + "processor": { + "module": "snapshotter.modules.computes.aggregate.single_aave_volume_6h", + "class_name": "AggregateSupplyVolumeProcessor" + } + } + // ... additional configurations ... + ] + } + ``` + +3. **Modify the Processor Logic**: + + Modify the data collection logic to concentrate on a 6-hour time span (`epochId`). Refer to the existing 24-hour aggregation example for guidance on structuring your logic. The 24-hour aggregate currently collects data for all core Aave V3 "actions" that can be taken on-chain. You may continue to collect data for all action's events, or you may choose to focus on a single action. Keep in mind that you will need to create a new data model in the `utils/message_models.py` file in your `snapshotter-computes` fork if you choose to change the snapshot data. See the [`AaveVolumeAggregateSnapshot`](https://github.com/PowerLoom/snapshotter-computes/blob/aave/utils/models/message_models.py#L101-L107) for reference. + +4. **Testing and Validation**: + + After implementation, rigorously test your new feature to ensure accuracy and efficiency. Validate that the data collected aligns with your intended 6-hour aggregation of each asset's volume-by-action. + +5. **Commit and Share Your Work**: + + Once your implementation is complete and tested, commit your changes to your implementation branch. Share your work with the community by creating a pull request to the `aave` Computes repository, if desired. + diff --git a/docs/build-with-powerloom/use-cases/existing-implementations/activity-tracking/_category_.json b/docs/build-with-powerloom/use-cases/existing-implementations/activity-tracking/_category_.json index e21ce57..85c840c 100644 --- a/docs/build-with-powerloom/use-cases/existing-implementations/activity-tracking/_category_.json +++ b/docs/build-with-powerloom/use-cases/existing-implementations/activity-tracking/_category_.json @@ -1,6 +1,6 @@ { "label": "On-Chain Activity Tracking", - "position": 1, + "position": 2, "link": { "type": "generated-index", "description": "Monitor Events and Transactions over various chains and protocols" diff --git a/docs/build-with-powerloom/use-cases/existing-implementations/uniswapv2-dashboard/closer-look-at-snapshots.md b/docs/build-with-powerloom/use-cases/existing-implementations/uniswapv2-dashboard/closer-look-at-snapshots.md index bb4a219..cf836b4 100644 --- a/docs/build-with-powerloom/use-cases/existing-implementations/uniswapv2-dashboard/closer-look-at-snapshots.md +++ b/docs/build-with-powerloom/use-cases/existing-implementations/uniswapv2-dashboard/closer-look-at-snapshots.md @@ -12,7 +12,7 @@ Before you dive into this section, please make sure you take a look into the [Sn Snapshotter node has several interfaces defined to handle the heavy lifting so that you can focus on just writing computes modules. For example, `TradeVolumeProcessor`, located in the **Snapshotter-computes** [`snapshotter-computer/trade_volume.py`](https://github.com/Powerloom/snapshotter-computes/blob/eth_uniswapv2/trade_volume.py), is one of the base Processor computes for Pooler. This class uses the `GenericProcessorSnapshot` structure found in [`snapshotter/utils/callback_helpers.py`](https://github.com/Powerloom/pooler/blob/main/snapshotter/utils/callback_helpers.py). -Any compute for base snapshots basically needs to implement the `compute` function. +Any processor for base snapshots needs to implement the `compute` function. ```python reference https://github.com/Powerloom/snapshotter-computes/blob/74b2eaa452bfac8c0e4e0a7ed74a4d2748e9c224/trade_volume.py#L23-L28 @@ -72,10 +72,10 @@ https://github.com/Powerloom/snapshotter-configs/blob/ae77941311155a9126205af087 `AggregateTradeVolumeProcessor`, located in the **Snapshotter-computes** [`snapshotter-computer/aggregate/single_uniswap_trade_volume_24h.py`](https://github.com/Powerloom/snapshotter-computes/blob/eth_uniswapv2/aggregate/single_uniswap_trade_volume_24h.py) is one of the aggregate computes for Pooler. This class uses the `GenericProcessorAggregate` structure found in [`snapshotter/utils/callback_helpers.py`](https://github.com/Powerloom/pooler/blob/main/snapshotter/utils/callback_helpers.py). -Any compute for base snapshots basically needs to implement the `compute` function. +Any processor for aggregate snapshots needs to implement the `compute` function. ```python reference -https://github.com/PowerLoom/snapshotter-computes/blob/74b2eaa452bfac8c0e4e0a7ed74a4d2748e9c224/aggregate/single_uniswap_trade_volume_24h.py#L58-L66 +https://github.com/PowerLoom/snapshotter-computes/blob/74b2eaa452bfac8c0e4e0a7ed74a4d2748e9c224/aggregate/single_uniswap_trade_volume_24h.py#L110-L118 ``` The `compute` function is the main part where we create and process snapshots. It uses these inputs: @@ -87,7 +87,7 @@ The `compute` function is the main part where we create and process snapshots. I - `protocol_state_contract`: Protocol state contract Web3 object. - `project_id`: Project ID for which the aggregate snapshot is being generated. -`msg_object` is either of type `PowerloomSnapshotSubmittedMessage` or `PowerloomCalculateAggregateMessage` for even more complex aggregats. +`msg_object` is either of type `PowerloomSnapshotSubmittedMessage` or `PowerloomCalculateAggregateMessage` for even more complex aggregates. PowerloomSnapshotSubmittedMessage contains the following information: ```python reference diff --git a/docs/build-with-powerloom/use-cases/existing-implementations/uniswapv2-dashboard/data-points.md b/docs/build-with-powerloom/use-cases/existing-implementations/uniswapv2-dashboard/data-points.md index 0c035b7..98cd7c0 100644 --- a/docs/build-with-powerloom/use-cases/existing-implementations/uniswapv2-dashboard/data-points.md +++ b/docs/build-with-powerloom/use-cases/existing-implementations/uniswapv2-dashboard/data-points.md @@ -26,20 +26,20 @@ https://github.com/PowerLoom/snapshotter-computes/blob/6fb98b1bbc22be8b5aba8bdc8 These base snapshots are then used to generate higher order aggregates. These aggregates are then used to generate the data points that are used in the Uniswap V2 Dashboard. Refer to [data-composition](/docs/protocol/data-composition) for more details on how data points are composed. -Following aggregate snapshots are generated by Pooler using base snapshots. +The following aggregate snapshots are generated by Pooler using base snapshots. **1. 24 Hour Trade Volume Snapshot:** 24 hour trade volume of each pair per Epoch. The 24 hour trade volume snapshot looks something like this ```python reference https://github.com/PowerLoom/snapshotter-computes/blob/6fb98b1bbc22be8b5aba8bdc860004d35786f4df/utils/models/message_models.py#L57-L64 ``` -**2. 7 days Trade Volume Snapshot:** 7 days trade volume of each pair per Epoch. The 7 days trade volume snapshot exactly like 24 hour trade volume snapshot but with a different time window. +**2. 7 days Trade Volume Snapshot:** 7 days trade volume of each pair per Epoch. The 7 days trade volume snapshot is exactly like 24 hour trade volume snapshot but with a different time window. **3. 24 hours Top Pairs Snapshot:** Top pairs by 24 hour trade volume per Epoch. The 24 hours top pairs snapshot looks something like this ```python reference https://github.com/PowerLoom/snapshotter-computes/blob/6fb98b1bbc22be8b5aba8bdc860004d35786f4df/utils/models/message_models.py#L83-L93 ``` -**4. 7 days Top Pairs Snapshot:** Top pairs by 7 days trade volume per Epoch. The 7 days top pairs snapshot very similar to 24 hour top pairs snapshot but with a different time window. +**4. 7 days Top Pairs Snapshot:** Top pairs by 7 days trade volume per Epoch. The 7 days top pairs snapshot is very similar to 24 hour top pairs snapshot but with a different time window. **5. 24 hours Top Tokens Snapshot:** Top tokens by 24 hour trade volume per Epoch. The 24 hours top tokens snapshot looks something like this ```python reference diff --git a/docs/build-with-powerloom/use-cases/existing-implementations/uniswapv2-dashboard/index.md b/docs/build-with-powerloom/use-cases/existing-implementations/uniswapv2-dashboard/index.md index fa4a73c..277d648 100644 --- a/docs/build-with-powerloom/use-cases/existing-implementations/uniswapv2-dashboard/index.md +++ b/docs/build-with-powerloom/use-cases/existing-implementations/uniswapv2-dashboard/index.md @@ -6,14 +6,14 @@ sidebar_position: 0 ## Pooler - UniswapV2 Data Market -Pooler is a Uniswap-specific implementation within the Powerloom ecosystem, designed as a snapshotter. It functions by synchronizing with other snapshotter peers over a smart contract on the Powerloom Protocol testnet. This architecture, guided by state transitions, is both easily comprehensible and modifiable. +Pooler is a framework built around the core snapshotter modules that power different varieties of Snapshotter nodes that participate in Powerloom Protocol. This document details out a Uniswap-specific implementation of this framework, designed as a snapshotter. It functions by synchronizing with other snapshotter peers over a smart contract on the Powerloom Protocol testnet. This architecture, guided by state transitions, is both easily comprehensible and modifiable. :::tip **Pooler in a Nutshell:** Forex, the foreign exchange market, involves currency trading and is known for its high liquidity and 24/7 operation. Pooler, in a parallel sense, operates continuously, capturing snapshots of Uniswap trades. Like Forex traders who analyze currency fluctuations to make profits, Pooler users can analyze trade volumes, liquidity reserves, and other metrics to understand market trends and potential profits in the Uniswap market. -In essence, Pooler is to Uniswap what Forex platforms are to currency trading – a tool for real-time tracking and analysis, facilitating better understanding and potentially profitable decision-making in the dynamic world of cryptocurrency trading. +In essence, Pooler is to Uniswap and other DeFi product what Forex platforms are to currency trading – a tool for real-time tracking and analysis, facilitating better understanding and potentially profitable decision-making in the dynamic world of cryptocurrency trading. ::: @@ -42,4 +42,4 @@ Data points are key metrics sourced from Uniswap V2 pair contracts, detailing ho Snapshotter Node's design enables extensions and custom use case implementations. A developer can extend the pooler compute files found in [snapshotter-computes](https://github.com/PowerLoom/snapshotter-computes/tree/eth_uniswapv2) and config files found in [snapshotter-configs](https://github.com/PowerLoom/snapshotter-configs/tree/eth_uniswapv2) to build their own custom use case implementations. We have a dedicated section in the documentation which walkthrough the details on further implementation and usecases extensions. -Check out our guide on [Extending Pooler](/docs/build-with-powerloom/use-cases/building-new-usecase/extending-uniswapv2-dashboard) +Check out our guide on [Extending Uniswap V2 dashboard usecase.](/docs/build-with-powerloom/use-cases/building-new-usecase/extending-uniswapv2-dashboard) diff --git a/static/images/aavev3-dashboard-powerloom.png b/static/images/aavev3-dashboard-powerloom.png new file mode 100644 index 0000000..623ae47 Binary files /dev/null and b/static/images/aavev3-dashboard-powerloom.png differ