https://github.com/PeggyJV/dextick, our feeder, is going to populate a Cloud SQL Postgres database with necessary market data from both CoinGecko and Uniswap V2 (with a common data format).

We need to expose the contents of that PG DB in a way that is easily consumable by the app server. We've chosen to use GraphQL as a common language across all data sources, and https://hasura.io/ seems like a great solution for the use case - their product can expose a GraphQL wrapper for any Postgres DB.

We should use Hasura's docker deployment for this work: we can then build it via Cloud Build and deploy it using Container Optimized OS for GCE (the same way we run the app).

Prerequisites:

1. Dextick data populated in some Cloud SQL Postgres (with known IP and auth creds). Should probably sync with @jackzampolin on when this can be available (at least some subset of data)

On page load the app currently subscribes to Infura (via the server) to new block headers. Until we get a new block, the sidebar showing swaps and liquidity changes shows the text 'Awaiting New Blocks...'

We should make sure to explicitly fetch the latest block number on page load, since all other data fetched is from the latest block. This also gives us a cleaner safety net for cases where the Infura WS doesn't send updates (which I've seen happen a few times already).

Basic load testing of the app using artillery.io or similar. We should make sure that if we do get some traction the site can actually handle it.

This is a companion task to #52 - the 'remove liquidity' converse to 'add liquidity'. Users should be able to fully manage their liquidity lifecycle on Sommelier, which includes the removal step.

This will be much simpler than add liquidity - as an MVP, they should only be able to remove 100% of their liquidity, in essence, burn their NFLP.

Updating their position atomically is out of scope. Users can update their positions by removing liquidity and adding liquidity separately, which are flows we will already support.

The user needs a flow where they can:

1. Select a pool from their open positions
2. Choose to remove the liquidity
3. Confirm the details of their action and submit their transaction

This task should also cover the needed contract interactions and approvals, if needed.

Acceptance Criteria:

• An end-to-end flow where a user with a liquidity position can generate and send a transaction, and end up with their individual tokens from the pool.

Right now the client app is Javascript, we should migrate it to Typescript ASAP before it gets too big. We should also turn on strict null checks and disable implicit any's in both the client and the server.

We should document our API for the impermanent loss charts and make that documentation public. We already have OpenAPI/Swagger set up so we just need to write the docs.

The core to the 'simplifying LPing' experience on Sommelier for V3 Uniswap is strategy suggestion. Non-sophisticated LPs don't have the knowhow of resources to figure out economically optimal liquidity provision on their own, especially for pairs of floating price (e.g., non-stablecoin pairs). Sommelier will offer some basic strategies to help suggest how users might provision their liquidity.

We should aim for 3 data-driven strategies at launch. These do not need to be the ultimately economically optimal strategies, but should be unequivocally better than providing liquidity across the entire price curve. They will also not be self-updating, as they will exist without the help of a protocol.

Here are some basic strategies:

• Provide liquidity within 1 7-day standard deviation of current mid-price
• Provide liquidity that captures 80% of the trade distribution over the past 7 days
• Provide liquidity between the 7-day low and 7-day high price
• Provide liquidity at the mid price +/- 20%

The implementor of this task should decide on three strategies, document them, show how they can be calculated from our available data, and make a (simple) economic argument for their utility. The team can then review these strategies.

Acceptance Criteria:

• Three chosen strategies document on Notion and approved by the team

The repo should have a Readme file and I suggest apache2 license.

A subgraph is an ETL that ingests events from Ethereum and outputs an indexed database queryable via GraphQL.

This ticket involves the ingestion step; we need to know which events from the Uniswap V3 core contracts are relevant to us.

@jackzampolin has listed the raw events here - https://www.notion.so/Raw-Events-from-v3-core-36384c8c10a74f3f9191747fac244e75 - so this task would involve figuring out which ones are relevant and which ones we might want to track. This will also help us inform our eventual query architecture.

Acceptance Criteria:

• List of relevant events from the Uniswap defined in notion, on separate page from 'Raw Events' page

Right now we have two wholly separate NPM packages in the same repo. We should set up a proper monorepo setup with yarn workspaces to make setup and builds easier.

Akin to our v2 route /api/v1/uniswap/pairs/:pairId, we need a route for V3 to get greater details on a specific pair and associated metrics. This route should contain as-close-to-real-time as possible data about the pair, for powering pair details and Add Liquidity experiences in the UI.

This route may also have to calculate some derived stats based on available data and provide those as pair insights. We want at least the below stats:

• Contract address of the pool
• Current price of pool
• Liquidity distribution of pool
• Number of unique liquidity providers in pool
• Fee tier of pool
• Creation date of pool
• Trade volume of pool in notional USD value
• Trade volume of pool in # of trades
• Trade distribution of pool
• Current reserves of each asset in pool
• Metadata about each token in the pool (address, decimals, symbol, long name)

As with v2, the API route should validate that the passed id is a valid ETH address, and should return appropriate error events if the pool could not be found.

Acceptance Criteria:

• Route exposed to get pair details for v3
• Route validates pairId is a valid ETH address
• Route returns pair details with fields specified above
• API Integration tests written for route

As a user
I want to connect my Ethereum Wallet through Wallet Connect
So that I don't have to rely on Metamask to use the application

As a user who is using Sommelier Pairings, I want to enjoy sandwich attack liquidity protection for my transactions by using Sommelier to calculate minimum liquidity and set it as a parameter so that bots can't drain an order on Uniswap v2 when trying to do a 1-sided swap.

Acceptance Criteria

1. Use liquidity check feature from Sommelier V2 app into V3 Pairings orders.

Issues #41 and #42 will have the finished work products of a definition of input data (relevant events from Ethereum), and output data (an entity schema for our processed data). This issue should cover the activity of actually creating the mapping from events to data, and wiring up all supporting services for a working subgraph.

Again, the Uniswap v2 subgraph is a good working template to base this off of.

Work items within this task include:

• Writing the necessary mappings (a.k.a. event handlers) in src/mappings to map events to the defined entities.
• Generating and creating a directory for the necessary ABIs to decode the events
• Defining the rules of the subgraph within subgraph.yaml, including necessary ABIs, linkings of events to handlers
• Writing package.json to include the necessary scripts: codegen, build, create-local, and deploy-local
• Adding linting and prettier to the project (can copy from v2 subgraph)
• Writing a README to describe how to use and deploy this repo, using v2's readme as a template

Acceptance Criteria:

• A working repo at PeggyJV/uniswap-v3-subgraph that can be deployed on a local graph node
• Presentation to the Uniswap team for feedback/collaboration

OUT OF SCOPE:

• subgraph.yaml does not need to define the addresses or starting blocks for indexing the factory contract. This will be added at launch day once they are known, immediately before deploy. Placeholder values can be used.

As an Admin, I want to be able to track the user interaction of Pairings users so that I know how much demand the app receives and which features are most important to my users.

Acceptance Criteria
Add the following metrics to Mixpanel for tracking interactions

1. Number of pair Searches completed on Pairings
2. Number of pairs searched
3. Number of interactions with the Pairings indicators
4. Monthly Active Users (defined by Unique Metamask Connects)

After #44 we should have a graph node infrastructure ready for a Uniswap v3 subgraph deployment. On launch day, May 5, as soon as possible to deployment of the Unsiwap, we should apply the final configuration to our subgraph and deploy the subgraph to our local graph node.

This involves two things:

• Configuring subgraph.yaml with the correct contract address and starting block
• Pulling the subgraph repo onto the graph node infrastructure, running the build steps, and deploying

We should do this with a dry run BEFORE launch day, so things are as smooth as possible on May 5.

Acceptance Criteria:

• Working Uniswap V3 subgraph up, running, and queryable 🎉

The app is still a little flaky, particularly when we need to fetch data from The Graph. It's been unavailable a few times in dev. We should display a generic 'Please try again later' page if any data-fetching issues prevents us from rendering a coherent UI.

If we detect a mobile viewport, we should pop up a modal saying:

Sommelier is better on the web! Please view on a desktop.

This mobile should fill the whole screen minus some padding and should not be exitable

UX: As a user who doesn't have metamask installed, I want to be prompted to install metamask so that I am able to continue with a wallet and use Pairings to add liquidity on Unsiwap v3.

Acceptance Criteria

1. If a user doesn't have a wallet, prompt to install metamask to continue.

Once #42 is completed, we will know the query interface for our subgraph. Even before the subgraph is deployed, we should use these definitions to write our API client for the subgraph. This client should be responsible for querying the subgraph and transforming the data (if necessary) into the data types defined in #46.

This should follow a similar pattern to the v2 client described in packages/server/src/services/uniswap.ts.

In other words, it should:

• Be scoped to a single file
• Export a stateless query interface
• Define query API for each data type, including query parameters (limits/timestamps)
• Support the same queries as the V2 subgraph
• Do basic error handling (handle non-success status codes or malformed responses and throw errors)

In the future, we may expand or modify the queries, but getting to feature parity with V2 is a good place to start.

Acceptance Criteria:

• File packages/server/src/services/uniswap-v3.ts exists in the API codebase
• V3 integration exposes same API as v2 service
• All queries to the V3 subgraph implemented

Pair: https://app.sommelier.finance/pair?id=0xa9bd7eef0c7affbdbdae92105712e9ff8b06ed49

Console error:

react-dom.production.min.js:209 Error: Passed falsy value to USDValueWidget
    at he (usd-value-widget.tsx:13)
    at Ja (react-dom.production.min.js:153)
    at _u (react-dom.production.min.js:261)
    at vs (react-dom.production.min.js:246)
    at ms (react-dom.production.min.js:246)
    at us (react-dom.production.min.js:239)
    at react-dom.production.min.js:123
    at t.unstable_runWithPriority (scheduler.production.min.js:19)
    at Ko (react-dom.production.min.js:122)
    at Qo (react-dom.production.min.js:123)

The app needs to be responsive, especially for mobile viewports. Things to look at:

• Navigation sidebar - should collapse at smaller desktop-sized viewports and go to the top on mobile
• IL Overview table - might be impossible to prevent some horizontal scrolling, but should be looked at
• IL graph - Should be more parseable on mobile
• Component ordering - We should make sure the IL graph appears first on mobile, under the pair stats, before the swaps/liquidity changes sidebar component

UX: As a user I want to see the statement in white text, centered and above the Search bar "The easiest way to add liquidity to Uniswap v3" so that I will be able to know what the app does when I land on the page.

Acceptance Criteria
Mobile responsive tag line at the top of the search bar
The easiest way to add liquidity to Uniswap v3
See sample in the #design channel on slack.

Feature: As a user, I want IL Loss to limit USD volume to pools of $500K of USD Volume so that pools that are lower volume do not trigger alerts and will not show up for tracking price or yield appreciation.

App should be usable on mobile - both portrait and landscape mode

We need to expose a route on the API to list all Uniswap V3 pools. It should accept the parameter count and sort - one should be able to get a specific number of results via count (max 1000) and sort by either volumeUSD (highest-volume pools) or reserveUSD (highest-liquidity pools).

The route should then use the proper subgraph call exposed by the V3 integration written in #47 to fetch this data, and return it to the client. The route should also perform parameter validation.

Acceptance Criteria:

• Route exposed to get top pairs for v3
• Route validates 0 < count < 1001
• Route validates sort=volumeUSD | sort=reserveUSD
• Route defaults to count=100 and sort=volumeUSD
• Route returns an array of top pairs on Uniswap V3, with all pair metadata according to our defined data model
• API Integration tests written for route

Add this to the sentiment modifier buttons - should also respect price flip

Tasks #52 and #55 describe the 'action' space for the Uniswap V3 liquidity lifecycle - add and remove. But there is an intermediate, passive flow here as well - portfolio management. This is the ending page for the Add flow - seeing the stats of an open position - and the starting page for the Remove flow - seeing an open position and choosing to action it (i.e. remove the liquidity).

This is also where we have the chance to show unique stats and insights re: a liquidity position on Uniswap V3. For May 5, we will only do basic insights - increasing the 'business intelligence' narrative and providing advanced analytics (for instance, time-series data) will be a post May 5 effort.

As starting point, the 'portfolio manager' screen should show:

• All open and closed positions
• Amount of liquidity in the position
• Fees accrued in position
• Current price of pool
• Whether position is active or not

ALL OTHER STATS ARE OUT OF SCOPE, as are 'position details' screen with time series data like the IL calculator.

Acceptance Criteria:

• Page exists where user sees all open and closed positions
• For each position, user can see stats specified above
• For open positions, user has button where they can trigger the 'Remove liquidity' flow

In the market dropdown, I can select a token pair but I can't entire a token pair.

Token pairs don't appear to be sorted in an obvious way and it make it hard to find a token pair.

Roadmap for communication re: Subgraph development.

Monday 4/2:

• COMMS: Kevin to present entity schema to Uniswap team for core contract functionality (position data)
• DEPENDENCY: can we open up uniswap-v3-core-subgraph repo to Uniswap team?

Comms work lead to two work streams:

• A set of actionable entities we can start implementing mappings for core
• A set of entities we will need to iterate on based on feedback for core

Monday 4/2-Thursday 4/7:

• DEVELOPMENT: Kevin to implement mappings for actionable entities

Development work will lead us to Milestone 1: having a partial core subgraph deployed.

Thursday 4/7:

• COMMS: Kevin to present a live, deployed, queryable subgraph containing actionable entities for core contracts only, deployed against Uniswap's private testnet for feedback
• DEVELOPMENT: Kevin to use feedback to finalize and implement mappings for the rest of the core entities

Comms work will help us iterate on the deployed subgraph towards finalization on 4/12.
Development work will lead us to Milestone 2: having a the full core subgraph deployed.

Monday 4/12:

• RELEASE: Uniswap V3 core entities fully deployed to private testnet
• COMMS: Kevin to present entity schema to Uniswap team for periphery contract functionality (position data)

Comms work lead to two work streams:

• A set of actionable entities we can start implementing mappings for periphery
• A set of entities we will need to iterate on based on feedback for periphery

Monday 4/12-Thursday 4/15:

• DEVELOPMENT: Uniswap v3 periphery mappings to be iterated upon, implemented and deployed to private testnet

Development work will lead us to Milestone 3: having both finalized periphery and core subgraphs deployed.

Friday 4/16:

• RELEASE: Full uniswap v3 subgraphs for both core and periphery finalized and deployed to private testnet, modulo small tweaks

We need a 'starting point' for the Uniswap V3 Add Liquidity experience - the beginning of our user journey. Some users may navigate to Sommelier knowing exactly which pools they want to enter - but part of our value proposition is also to help users make that decision. We need 'discovery', which in its most basic sense, is the ability for users to see the universe of pools they can enter.

So we need a page to list available pools, somewhat like the V2 landing page. Unlike the V2 landing page, we should simply sort by the largest pools (by liquidity and/or volume across the entire price spectrum). Organizing pools by 'high APY' is out of scope for this task, since the calculation is not as straightforward in a world of discrete liquidity.

These 'lists' should be actionable - a user should be able to select a pool they are interested in from the list, and be taken to the 'Add Liquidity' experience described in #52.

Before this task is actioned, we should wireframe/storyboard what this experience looks like.

Acceptance Criteria:

• User can see the top 100 pool by volume
• User can see the top 100 pool by liquidity
• User can, in a summary view, see volume, liquidity, mid-price, and fee tier for each pool
• User can click on a pair and navigate to the 'add liquidity' experience

We have graph nodes running in GCP (for instance, currently indexing V2), but for V3 we want a dedicated graph node for reliability's sake. This graph node can share a turbo-geth instance with the other graph nodes - the private IP for this node is available in the Instances section of GCP.

The implementor of this task should create the node, start it, and make it ready for subgraph deployment.

Acceptance Criteria:

• Graph node infrastructure set up in GCP, with similar architecture as existing graph nodes (container-optimized OS)
• Graph node instance should also run IPFS
• Easy startup and process management script for the graph node, which includes connection string URLs for postgres, IPFS, and turbogeth
• Proper configuration and tuning, including target block range, pg pool size, and other needed environment variables.
• Build toolchain for the graph node, including local Rust and cargo environment

This API route will be the backbone of our 'Portfolio Management' feature, to be delivered in a 'basic' version on May 5th and to be one of our biggest priorities post-launch. The goal for this API route is to take a wallet address and return a summary of the positions for that address, both opened and closed.

Data for an individual position should contain:

• The pool associated with that position (pair + fee tier)
• Address of the position's NFLP
• The date the position was opened
• The date the position was closed (if applicable)
• Total liquidity of position at entry (including individual token amounts and notional USD)
• Tick range of position, including mid-pricce
• Price of each token at entry (in USD)
• Total liquidity of tick range of position at entry
• Total liquidity of tick range of position at close/current
• Total liquidity of pool at entry
• Total liquidity of pool at close/current
• Fees collected for position
• Impermanent loss for position (within the tick range)
• % of trade volume within position, over lifetime of position
• Notional USD gain of the position
• NICE TO HAVE: gas cost of entering the position

Acceptance Criteria:

Route exposed to get position details for v3
Route validates address is a valid ETH address
Route returns position details for each position, with fields specified above
API Integration tests written for route

After our Blep and V2 integrations, we have a sense of what different data models for indexing DEXes might look like. It's time to define our own. This is a big part of leadership and our competitive data moat: we should be opinionated about the best ways to model these facts, and be able to collect data from disparate data sources and unify them into one coherent entity structure that we've defined.

To make this happen, we need to define what this data model looks like. We should take inspiration from the Graph and Blep, but it does not to necessarily be the same - it's likely that we can improve, and provide convenient derived properties on the data that are built of our data primitives. For example: a 7-day moving average of price.

We should define these data models in two ways: 1) as TypeScript interfaces, and 2) as TypeScript classes, which implement those interfaces, and provide additional convenience methods on top. These methods should be read-only as we should consider our data immutable once fetched. See packages/sommelier-types/src/pair.ts for an example of this pattern.

Acceptance Criteria:

• Data model defined in packages/sommelier-types
• Documentation in sommelier-types/README on data model

We want the best 'simple' add liquidity experience for Uniswap V3 that exists. We've already discussed what this means in a V3 world - an intuitive UI and strategies that simplify the decision about where to provision liquidity.

We need to design and implement an experience that captures this flow. This flow is going to have multiple steps:

1. Choosing a pool to add liquidity
2. Choosing how to add liquidity (amount and strategy)
3. Confirming the action and making an on-chain transaction

The inputs for an add liquidity experience are:

• Pool (pair and fee level)
• Liquidity strategy (user will chose from pre-determined options)
• Amount of assets to add - will add both assets (no one-sided add as in our v2 product)
• Transaction speed

Additionally, when making their decision, the user should be able to have this information in an accessible context:

• Current price in the pool
• Fee tier of pool
• Liquidity distribution
• number of unique LPs
• Wallet balances of each token to add
• Any currently open position for pair

Once the user confirms their decision, we need to make the necessary contract interactions and Ethereum transactions to add liquidity according to the defined parameters.

Before this task is actioned, we should wireframe/storyboard what this experience looks like.

Acceptance Criteria:

• An end-to-end flow where a user brings their own tokens, uses the UI, and ends up with a liquidity position in a Uniswap V3 pool.

It would be good to be able to pass in a token pair like https://app.sommelier.finance/?KEEP_WETH

New User Story for Support: As a user who is on the sommelier site, I want to see a “Support” icon at the bottom right of the screen like https://image.flaticon.com/icons/png/512/69/69114.png that will link to our Support channel in Discord with the following link: https://discord.gg/VXyUgtnbtv so that I will be able to go to Discord and ask my support questions.

API integration tests for server and Basic UI tests to start.

Make code styling and formatting easier by configuring ESLint and prettier. Lint staged files and run prettier --write in a precommit hook.

Akin to our v2 API, we need to get historical data for a pair. Unlike our V2 API, we do not need to split this into different routes, but we likely want a time window query parameter, since in V3 we will have a greater range of time window aggregations.

This route should return the same data structure as in #49, but across a time series, specified in from and to parameters. Both from and to should be optional, which from defaulting to the creation date of the pool, and to defaulting to the current timestamp.

This route will help us populate charts and other UIs on the frontend, and we might also want to calculate time-series specific statistics. However it should not perform any calculations over the data - this should provide raw results only, with calculations provided in a different route.

Acceptance Criteria:

• Route exposed to get time series data for a pool for v3
• Route validates startDate is a valid timestamp
• Route validates endDate is a valid timestamp
• Route validates window depending on available windows (decided by subgraph) - window should default to 1d
• Route returns an array of time series data for the specified pool, with all pair metadata specified as in #49
• API Integration tests written for route

Issue #41 will enumerate the events that can are relevant to our data model - this task should actually do the work of defining that data model. This will require looking at prior art - the Uniswap V2 Subgraph, and defining the tables to be stored in our database.

Things to think about:

• At least data parity with V2 - may need additional columns to represent e.g. discrete liquidity concepts
• Possible time intervals - V2 supported daily and hourly. We may want to index intervals as tight at 1 minute.
• Should make sure that all entity columns are either directly reflected by or can be derived from the payload of our relevant events.

Acceptance Criteria:

• File schema.graphql defined in PeggyJV/uniswap-v3-subgraph representing the defined entities