peggyjv / il-loss-charts Goto Github PK
View Code? Open in Web Editor NEWπ· The Finest Liquidity Management tools for LPs.
Home Page: https://app.sommelier.finance/
License: Apache License 2.0
π· The Finest Liquidity Management tools for LPs.
Home Page: https://app.sommelier.finance/
License: Apache License 2.0
react-dom.production.min.js:209 TypeError: Cannot read property 'on' of undefined
at use-wallet.js:28
at Je (App.js:32)
at Ja (react-dom.production.min.js:153)
at xu (react-dom.production.min.js:261)
at vl (react-dom.production.min.js:246)
at ml (react-dom.production.min.js:246)
at ul (react-dom.production.min.js:239)
at nl (react-dom.production.min.js:230)
at Hl (react-dom.production.min.js:281)
at react-dom.production.min.js:284
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.
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
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:
Make code styling and formatting easier by configuring ESLint and prettier. Lint staged files and run prettier --write in a precommit hook.
The repo should have a Readme file and I suggest apache2 license.
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:
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:
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:
startDate
is a valid timestampendDate
is a valid timestampwindow
depending on available windows (decided by subgraph) - window
should default to 1d
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.
Add this to the sentiment modifier buttons - should also respect price flip
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:
The inputs for an add liquidity experience are:
Additionally, when making their decision, the user should be able to have this information in an accessible context:
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:
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:
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
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.
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:
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:
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).
Roadmap for communication re: Subgraph development.
Monday 4/2:
Comms work lead to two work streams:
Monday 4/2-Thursday 4/7:
Development work will lead us to Milestone 1: having a partial core subgraph deployed.
Thursday 4/7:
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:
Comms work lead to two work streams:
Monday 4/12-Thursday 4/15:
Development work will lead us to Milestone 3: having both finalized periphery and core subgraphs deployed.
Friday 4/16:
It would be good to be able to pass in a token pair like https://app.sommelier.finance/?KEEP_WETH
App should be usable on mobile - both portrait and landscape mode
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:
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:
packages/server/src/services/uniswap-v3.ts
exists in the API codebaseThis 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:
This task should also cover the needed contract interactions and approvals, if needed.
Acceptance Criteria:
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:
Acceptance Criteria:
schema.graphql
defined in PeggyJV/uniswap-v3-subgraph representing the defined entitiesBasic 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.
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
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
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:
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:
src/mappings
to map events to the defined entities.subgraph.yaml
, including necessary ABIs, linkings of events to handlerscodegen
, build
, create-local
, and deploy-local
Acceptance Criteria:
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.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
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:
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:
subgraph.yaml
with the correct contract address and starting blockWe should do this with a dry run BEFORE launch day, so things are as smooth as possible on May 5.
Acceptance Criteria:
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)
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:
0 < count < 1001
sort=volumeUSD | sort=reserveUSD
count=100
and sort=volumeUSD
API integration tests for server and Basic UI tests to start.
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
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 app needs to be responsive, especially for mobile viewports. Things to look at:
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:
cargo
environmentTasks #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 OTHER STATS ARE OUT OF SCOPE, as are 'position details' screen with time series data like the IL calculator.
Acceptance Criteria:
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.
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.
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:
packages/sommelier-types
sommelier-types/README
on data modelUX: 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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.