Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FiDi DotSight: Refined scope for M3, updated address #1971

Merged
merged 1 commit into from
Sep 18, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 16 additions & 15 deletions applications/fidi-dotsight-analytics.md
Original file line number Diff line number Diff line change
Expand Up @@ -174,9 +174,9 @@ Our decentralized platform will enable analysts and power users to interactively

### Legal Structure

**Registered Address:** 400 NW 7th Ave, #14310, Ft. Lauderdale, FL 33311, USA
**Registered Address:** Unit 2A, 17/F, Glenealy Tower, No.1 Glenealy, Central, Hong Kong SAR

**Registered Legal Entity:** FiDi Tech, Inc
**Registered Legal Entity:** FiDi Tech Ltd

### Team's experience

Expand Down Expand Up @@ -219,14 +219,14 @@ All infrastructure deliverables belong to the teams’ domains of expertise and
- **Full-Time Equivalent (FTE):** 3.5 FTE
- **Total Costs:** 25,000 USD

### Milestone 1 — Data Interface API
### Milestone 1 — Data Interface

- **Estimated duration:** 1mo
- **FTE:** 4
- **Costs:** 7,500 USD

- Summary: This milestone covers a complete data interface connected to GiantSquid and FiDi dashboards. It also includes fully productionized custom Squids and FiDi views for Astar staking dApp analytics.
- Success: an open-sourced data interface as well as fully operational dashboards for two selected parachains
- Summary: This milestone covers a complete data interface connected to GiantSquid and any arbitrary data provider.
- Success: an open-sourced data interface with customizable middleware, mappers, aggregation logic, and data sources.

| Number | Deliverable | Specification |
| -----: | ----------- | ------------- |
Expand All @@ -238,30 +238,28 @@ All infrastructure deliverables belong to the teams’ domains of expertise and
| **1c.** | Off-chain sourced addresses support | We will provide rudimentary support for additional data materialization parameters, e.g., pricing via liquidity pool addresses. This will be extended to any off-chain data in an oracle-like fashion in future milestones. |
| **2a.** | Data Interface for developers | We will provide a configuration-based interface (initially via git pull requests, then automated in Milestone 2) with key specifications for the new views. We will leverage React and Typescript on the frontend and Typescript with Nest and PGSQL on the backend.
| **2b.** | Schema mapping and morphing | We will provide a configuration-based paradigm for specifying: the desired metrics mapping, aggregation logic, upstream GiantSquid URI, and desired materialized view.|
| **2c.** | Data interface: view construction | We will provide developers with the ability to select a desired analytical dashboard from the pre-selected collection (see five views explained in the architecture section; fully customizable views will make it to future milestones). These UI components will also be implemented via React and Typescript.|
| **2d.** | Data interface: Deployment | We will provide developers with the ability to schedule their customer view’s deployment (automatically at recurring times in the future milestones). The deployment action will be a UI module, and the propagation/consensus will occur via GitHub at first and via a PGSQL query in future milestones.|
| **3a.** | Dashboards: Default Analytical Views | We will integrate the default views, i.e., pie chat, 1/3-metrics view, and list of assets, with the data interface and make it available for the ad-hoc developer deployment. For 3a-c UI components, we will similarly rely on React + Typescript.|
| **3b.** | Dashboards: Advanced Staking View | We will integrate the advanced staking view, e.g., the dApps names, nominator TVLs, balances, rewards, and ranks, with the data interface and make it available for ad-hoc developer deployment. |
| **4a.** | Lighthouse use cases: Squids for Wallet-specific metrics | We will implement new squids in GraphQL surfacing wallet-specific metrics for two parachains with the following metrics that need to be surfaced via GiantSquid: Free tokens, Vesting, EVM Deposits, and dApp names. |
| **4b.** | Lighthouse use cases: Squids for dApp-specific metrics | We will implement new squids in GraphQL surfacing wallet-specific metrics for two parachains with wallet-specific metrics for dApps: TVL change per dApp, Active (UAW) and net new wallets per dApp (x2), historical Transactions / Volume / Balance per dApp (x3). |
| **4c.** | Lighthouse use cases: customized dApp views | As the first two use-cases, a feasibility proof and an accelerator, we will provide the community with a fully integrated customized dApp analytics dashboard leveraging the data interface (2a-2c), the advanced staking view (3b), and the data aggregation module (1a-1c). |


### Milestone 2 — Views with Network- and dApp-level Metrics
### Milestone 2 — POC Dashboards with Network-, dApp-level and custom Metrics

- **Estimated Duration:** 1mo
- **FTE:** 2.5
- **Costs:** 5,000 USD

- Summary: This milestone covers support for essential metrics at the parachain and dApp level under each chain. Many would require custom squids built as a part of this scope.
- Summary: This milestone covers support for essential metrics at the parachain and dApp level under each chain. Many would require custom pipelines built as a part of this scope.
- Success: developer UI supports views with newly sourced metrics.

| Number | Deliverable | Specification |
| -----: | ----------- | ------------- |
| **0a.** | License | Apache 2.0
| **0b.** | Documentation | We will provide documentation on every supported metrics class and an educational tutorial explaining the typical way to interpret the data, navigate the developer UI, specify the required metadata, deploy a data interface configuration, and select the desired dashboard. |
| **0c.** | Testing | Core functions will be fully covered by a unit and integration tests suite to ensure robustness, deployment, and serving times. |
| **1a.** | dApp-level signals: collator metrics | We will generalize prior work from Milestone 1 to span collator/nominator activity and make metrics such as uptime, block production rate, block processing time, rank/nominator rank, name, and value locked available in the views. For 1a-2a, the respective in GraphQL squid query and GiantSquid's code are also in scope; the UI components will be written in React + Typescript and the backend code in Typescript + Nest + PGSQL.|
| **1a.** | dApp-level signals: collator metrics | We will generalize prior work from Milestone 1 to span collator/nominator activity and make metrics such as uptime, block production rate, block processing time, rank/nominator rank, name, and value locked available in the views. For 1a-2a, the respective GraphQL squid query and GiantSquid's code are also in scope; the UI components will be written in React + Typescript, and the backend code in Typescript + Nest + PGSQL.|
| **1b.** | dApp-level signals: user activity | Additionally, the dApp-specific user activity metrics will be surfaced, e.g., UAW, net new wallets, historical transactions, volume, and balance per dApp. Respective squid query and GS code are also in scope. |
| **2a.** | Network-level signals | We will generalize prior work from Milestone 1 to span L1-level metrics and activity made available in the developer UI, e.g., UAW per network, number of new wallets, adoption rates, unstaked tokens currently in wallets, tokens in circulation, and tokens staked or locked. Respective squid query and GS code are also in scope. |

Expand All @@ -272,18 +270,21 @@ All infrastructure deliverables belong to the teams’ domains of expertise and
- **FTE:** 2.5
- **Costs:** 5,000 USD

- Summary: This milestone covers a no-code option for developers to productionize new views on FiDi via specific squids on GiantSquid.
- Summary: This milestone covers a no-code option for developers to productionize new views on FiDi via arbitrary data sources including squids on GiantSquid.
- Success: developer UI launched, and new users are able to productionize new views without any code.

| Number | Deliverable | Specification |
| -----: | ----------- | ------------- |
| **0a.** | License | Apache 2.0
| **0b.** | Documentation | We will provide documentation on every supported metrics class and an educational tutorial explaining the typical way to interpret the data, navigate the developer UI, specify the required metadata, deploy a data interface configuration, and select the desired dashboard. |
| **0c.** | Testing | Core functions will be fully covered by a unit and integration tests suite to ensure robustness, deployment, and serving times. |
| **1a.** | dApp-level signals: collator metrics | We will provide an intuitive web interface for specifying the desired metrics mapping, aggregation logic, upstream GiantSquid URI, and desired materialized view. The UI will be an extension of the one built in M2 and also leverage Typescript + React; and Nest + CloudSQL (PGSQL) + Typescript on the backend. |
| **1b.** | Online testing & deployment | We will provide an intuitive web interface for querying the new view for deployment and validating its configuration. The UI's part technology choices is same as 1a.|
| **2a.** | Deployment validation & View status | We will implement testing and validation layers to ensure the user-inputted configurations for newly spun-up views and GS queries are performant. We will surface the view “status,” e.g., up, down, missing data, and similar. |
| **2a.** | Automated and ad-hoc deployment | We will decouple the existing infrastructure to support ad-hoc and scheduled deployments for newly created views. The CI/CD and automation for 2a-b will rely on schedule App Engine workers. |
| **1a.** | dApp-level signals: collator metrics | We will provide an intuitive web interface for specifying the desired metrics mapping, aggregation logic, upstream data provider, and desired materialized view (dashboard). The UI willleverage Typescript + React; and Nest + CloudSQL (PGSQL) + Typescript on the backend. |
| **1b.** | Online testing & deployment | We will provide an intuitive web interface for querying the new view for deployment and validating its configuration. The UI's part technology choices is the same as 1a.|
| **2a.** | Deployment validation & View status | We will implement testing and validation layers to ensure the user-inputted configurations for newly spun-up views and queries are performant. We will surface the view “status,” e.g., up, down, missing data, and similar. |
| **2b.** | Automated and ad-hoc deployment | We will decouple the existing infrastructure to support ad-hoc and scheduled deployments for newly created views. The CI/CD and automation for 2a-b will rely on scheduled App Engine workers. |
| **2c.** | Data interface: view construction | We will provide developers with the ability to select a desired analytical dashboard from the pre-selected collection (see five views explained in the architecture section; fully customizable views will make it to future milestones). These UI components will also be implemented via React and Typescript.|
| **2d.** | Data interface: Deployment | We will provide developers with the ability to schedule their customer view’s deployment (automatically at recurring times in the future milestones). The deployment action will be a UI module, and the propagation/consensus will occur via GitHub at first and via a PGSQL query in future milestones.|


### Milestone 4 — Interactive SQL Query Engine for Views

Expand Down