Start Porter Subgraph about v1-core HOT 10 CLOSED

aren't subgraphs automatically generated from our contract abis? what additional effort is there?

I'm not really sure - It seems uniswap and compound have quite a few commits to their subgraphs.

• https://github.com/Uniswap/v2-subgraph/commits/master
• https://github.com/compound-finance/compound-v2-subgraph/commits/master

What are they doing in those?

seems like uniswap is just updating token whitelist & price mapping

and compound is updating functions that take events to save them with addtl data

compound-finance/compound-v2-subgraph@e9cc55b

subgraphs take the events from contracts and store their data automatically afaik

Historical data as well? Or only data after the subgraph has been created?

historical as well, it'll index the contract by checking past events (if what i read is correct)

so with regards to "Note down what data we'd need to expose from our smart contracts for the subgraph to enable our frontend" i believe this is just whatever our contracts has set to external / public, will auto become available

I was viewing this more from the perspective of "Based on our frontend mocks - what are the events and external variables that our smart contracts will need to expose"

Some example questions:

• How would we query for a list of all bonds that exist?
• How would we query for all bond auctions?
• How would we query for total amount borrowed by all borrowers?

The answer to questions like those would help inform the smart contract design decisions. For example:

• Does the broker contract need to store an array of all the bonds that have been created? Or can that information be gathered from the events emitted upon bond creation?

it can all be gathered from The Graph, storing an array in the contract isn't necessary, and in fact it's advised to avoid this behavior

Since we are going to be wrapping EasyAuction and will have access to all of their data, it might make sense to deploy an auto generated subgraph for https://github.com/gnosis/ido-contracts/blob/main/contracts/EasyAuction.sol and we can learn about the data that's accessible and the limitations.

done! https://github.com/porter-finance/subgraph

from v1-core.

• Figure out how exactly we can use this in our protocol - I'm thinking that we create a subgraph then query the subgraph to get the information needed on each of our product screens: https://github.com/porter-finance/product/tree/main/spec/pages

Looks like a good step forward

• Note down what data we'd need to expose from our smart contracts for the subgraph to enable our frontend

tbd

• Made a subgraph repo (public)

Repo made, requires a deployed contract to work tho. Tried to get it deployed locally via node and graph-cli and ganache-cli but ended up failing

• What would the costs of using the Graph be?

When deploying a brand new subgraph, you will consume between 125,000 and 150,000 gas

Then, once the initial Curator comes to signal on this subgraph, that transaction will
initialize the curation share tokens
initialize the bonding curve
transfer tokens into the Graph Proxy
burn 2.5% of those tokens
issue the curation shares

This will consume roughly 1,300,000 gas, so about 10 times the amount of simply deploying.

https://streamingfastio.medium.com/streamingfacts-understanding-the-costs-of-upgrading-a-subgraph-fedf5d61223#:~:text=Gas%20Costs%20%E2%80%94%20Ethereum%20Network%20Fees,between%20125%2C000%20and%20150%2C000%20gas.

• Estimate level of work to build out the full subgraph

Seems to be easy, we just provide it with a contract address and it gives us a good enough working subgraph

• Any better alternatives?

https://bitquery.io/

https://moralis.io/

from v1-core.

https://thegraph.com/hosted-service/subgraph/gnosis/protocol does this give us the auction data we need? Looks like there are some subgraphs for gnosis auction already built.

We might need one on top of this / that integrates with this - but I'd be great if we can get auction data from that

from v1-core.

#32 (comment)

@luckyrobot Did you figure out the answer to this? I'm curious if we can leverage one of the already existing gnosis graphs

from v1-core.

yeah, we can totally use https://github.com/gnosis/dex-subgraph/blob/master/subgraph.yaml.mustache

their whole repo looks very forkable for us @RusseII

from v1-core.

yeah, we can totally use https://github.com/gnosis/dex-subgraph/blob/master/subgraph.yaml.mustache

I think thats actually for a different contract - not gnosis auction.

I saw that ribbon seemed to deploy a subgraph for gnosis auction that we may be able to leverage:

https://thegraph.com/hosted-service/subgraph/stevenwal/gnosis-auction
https://github.com/ribbon-finance/ribbon-subgraph/tree/main/v2/generated/GnosisAuction

from v1-core.

I saw that ribbon seemed to deploy a subgraph for gnosis auction that we may be able to leverage:

Hmm - they actually modify it quite a bit to fit their use case. I saw another gnosis graph made by ribbon as well that seems closer to native: https://thegraph.com/hosted-service/subgraph/cjinghong/gnosis-auction-fast-index

from v1-core.

i'm a little confused on the work required here

aren't subgraphs automatically generated from our contract abis? what additional effort is there?

subgraphs take the events from contracts and store their data automatically afaik

for example https://github.com/Uniswap/v2-subgraph/blob/master/subgraph.yaml

even the schema.json is created automatically for gql, graph codegen --output-dir ./generated

and a very basic example here, https://github.com/compound-finance/compound-v2-subgraph

you can check out their scripts for a better understanding

  "scripts": {
    "codegen": "graph codegen --output-dir src/types/",
    "build": "graph build",
    "create-local": "graph create compound-finance/compound-v2 --node http://127.0.0.1:8020",
    "deploy-local": "graph deploy compound-finance/compound-v2 --debug --ipfs http://localhost:5001 --node http://127.0.0.1:8020/",
    "deploy": "graph deploy compound-finance/compound-v2 --debug --ipfs https://api.thegraph.com/ipfs/ --node https://api.thegraph.com/deploy/",
    "prodtest": "graph deploy davekaj/compound-v2 --debug --ipfs https://api.thegraph.com/ipfs/ --node https://api.thegraph.com/deploy/",
    "deploy-staging": "graph deploy --debug --ipfs https://api.staging.thegraph.com/ipfs/ --node https://api.staging.thegraph.com/deploy/ davekaj/compoundv2",
    "watch-local": "graph deploy compound-finance/compound-v2 --watch --debug --node http://127.0.0.1:8020/ --ipfs http://localhost:5001",
    "prettier": "./node_modules/.bin/prettier —-write '**/*.ts'"
  },

so with regards to "Note down what data we'd need to expose from our smart contracts for the subgraph to enable our frontend" i believe this is just whatever our contracts has set to external / public, will auto become available

let me know if im missing something, perhaps im not understanding the amoutn of work involved @RusseII

from v1-core.

aren't subgraphs automatically generated from our contract abis? what additional effort is there?

I'm not really sure - It seems uniswap and compound have quite a few commits to their subgraphs.

• https://github.com/Uniswap/v2-subgraph/commits/master
• https://github.com/compound-finance/compound-v2-subgraph/commits/master

What are they doing in those?

subgraphs take the events from contracts and store their data automatically afaik

Historical data as well? Or only data after the subgraph has been created?

so with regards to "Note down what data we'd need to expose from our smart contracts for the subgraph to enable our frontend" i believe this is just whatever our contracts has set to external / public, will auto become available

I was viewing this more from the perspective of "Based on our frontend mocks - what are the events and external variables that our smart contracts will need to expose"

Some example questions:

• How would we query for a list of all bonds that exist?
• How would we query for all bond auctions?
• How would we query for total amount borrowed by all borrowers?

The answer to questions like those would help inform the smart contract design decisions.
For example:

• Does the broker contract need to store an array of all the bonds that have been created? Or can that information be gathered from the events emitted upon bond creation?

Since we are going to be wrapping EasyAuction and will have access to all of their data, it might make sense to deploy an auto generated subgraph for https://github.com/gnosis/ido-contracts/blob/main/contracts/EasyAuction.sol and we can learn about the data that's accessible and the limitations.

from v1-core.

closing, seems like we have most answers here but pls reopen if not

from v1-core.