Subgraphs for the Rubicon Protocol 🌏📖
🔨 = In Progress.
🛠️ = Complete. Additional testing required.
🦖 = Complete, with tests.
💀 = Soon to be deprecated.
| Subgraph | Status | Description |
|---|---|---|
| RubiconV2 | 🦖 | a subgraph to support the Rubicon application |
| RubiconV2_Optimism | 🦖 | a subgraph to support the Rubicon application, with legacy events for the v1 protocol data on Optimism |
| MarketAid | 🛠️ | a subgraph to support the tracking of asset balances on a market aid instance |
| Metrics | 🔨 | a subgraph to track usage metrics of the Rubicon protocol |
| RubiconLogs | 🔨 | a subgraph to track low level events for the protocol, regardless of version |
| RubiconMarketLight | 💀 | a subgraph that was used within the rubi-py sdk, soon to be replaced by RubiconV2 |
check out some good first issues here. there aren't any contributing guidelines, as needed that will change 📈, for now please just try to leave it better than you found it :) pull requests will be accepted ASAP. any contributions will be rewarded with a hand drawn NFT.
please check out our grants program here 🚀
Deploying a subgraph is a straightforward process. Deployment scripts lie within the package.json file at the root of the relevant subgraphs directory. The deployment process adheres to the following pattern:
- Prepare the subgraph for the relevant network:
npm run prepare:<network name>:<optional identifier> - Ensure the subgraph compiles relevant files correctly:
npm run codegen - Deploy the subgraph to the relevant endpoint:
npm run deploy:<network>:<optional identifier>
There are three locations that a subgraph is typically deployed to: 1) the hosted service, 2) a remote indexer, 3) a local indexer. When deploying to options 2 & 3, while the deployment pattern will be the same as above, there can be additional steps to take if that is the first time deploying the subgraph. These include:
- Creating the subgraph namespace on the indexer:
npm run create:cloud:<network>:<optional identifier> - Deploy to the subgraph namespace on the indexer:
npm run deploy:cloud:<network>:<optional identifier>When deploying a subgraph to an existing namespace, its helpful to follow a semantic versioning pattern. - Removing the subgraph namespace on the indexer:
npm run remove:cloud:<network>:<optional identifier>
Adding a new network is a very simple process. To do so one must simply: 1) create a new config/<network>.json file and 2) update the package.json to include the relevant deployment scripts. Please follow the established pattern when adding new deployment scripts.
An in depth overview on debugging can be found here. For debugging the hosted service, this interface is incredibly helpful for doing. You can provide the query query below, supplemented with the relevant deployment_id, to help identify what the error is.
query HostedServiceDebug {
indexingStatuses(subgraphs: ["deployement_id"]) {
node
subgraph
synced
health
entityCount
fatalError {
message
block {
number
}
}
}
}For checking the status of any subgraph, an easy query for doing is below. It should provide you the relevant details needed to identify where an error is being caused in your subgraph, enabling you to identify the event or function call that is cauing your problem.
{
_meta{
deployment
hasIndexingErrors
block{
number
timestamp
hash
}
}
}An overview of the design principles in place within this repo can be found here. In short, the Rubicon protocol emits events which correspond to relevant actions that are occuring on the protocol. These events are defined within the subgraph.template.yaml, along with details regarding the smart contracts the originate from. src/mappings defines how those events are handled in relation to the schema.graphql, which is the underlying database architecture that the sugbraph is populating. Types corresponding to the events and smart contracts are generated when codegen is ran, and stored within the generated/ file. The config/ file contains relevant information to the network that is being indexed, and populates the subgraph.yaml based upon the subgraph.template.yaml when you run npm run prepare:<network>.
.
├── abis
│ ├── RubiconMarket.json
│ └── RubiconRouter.json
├── config
│ ├── arbitrum.json
│ ├── arbitrum_goerli.json
│ ├── base.json
│ ├── base_goerli.json
│ └── polygon_mumbai.json
├── generated
│ ├── RubiconMarket
│ │ ├── ...
│ │ └── RubiconMarket.ts
│ ├── RubiconRouter
│ │ ├── ...
│ │ └── RubiconRouter.ts
│ └── schema.ts
├── package.json
├── schema.graphql
├── src
│ ├── mappings
│ │ ├── RubiconMarket.ts
│ │ └── RubiconRouter.ts
│ └── utils
│ ├── constants.ts
│ └── entities
│ ├── candles.ts
│ ├── pair.ts
│ ├── transaction.ts
│ └── user.ts
├── subgraph.template.yaml
├── subgraph.yaml
└── tests
├── constants.ts
├── rubicon.test.ts
└── utils.ts