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

[Tracking] Feature parity with legacy core network subgraph #46

Open
6 tasks done
chriswessels opened this issue Jul 25, 2023 · 2 comments
Open
6 tasks done

[Tracking] Feature parity with legacy core network subgraph #46

chriswessels opened this issue Jul 25, 2023 · 2 comments
Labels
p1 High priority size:large Large type:tracking Tracking issues with related scope

Comments

@chriswessels
Copy link
Member

chriswessels commented Jul 25, 2023

Feature parity with the existing core network subgraph to the extent that core workloads (e.g. indexer-agent, gateway, etc) require.

  • 1
type Allocation {
  ageInEpochs: Int!
  signalledTokens: BigInt!
  status: AllocationStatus
  createdAtEpoch: number
  createdAtBlockHash: string
  createdAtBlockNumber: number
  closedAtEpoch: number
  closedAtEpochStartBlockHash: string 
  previousEpochStartBlockHash: string
  closedAtBlockHash: string
  poi: string
}
  • 2
type GraphNetworks {
    isPaused: Bool!
}
  • 3
type SubgraphVersion {
  version: Int!
  createdAt: Int!
  deployment: String!
}
  • 4
type Subgraph {
  id: String!
  versionCount: Int!
  versions: [SubgraphVersion]!
}
  • 5
type SubgraphDeployment {
  ipfsHash: String!
  deniedAt: Int!
  indexerAllocations: [Allocation]!
}
  • 6
type Epoch {
  id: number
  startBlock: number
  startBlockHash: string | undefined
  endBlock: number
  signalledTokens: number
  stakeDeposited: number
  queryFeeRebates: number
  totalRewards: number
  totalIndexerRewards: number
  totalDelegatorRewards: number
}

Related spike: #45

@juanmardefago
Copy link
Contributor

L2 transfer tools support:

  • Agent will require at least startedTransferToL2At (timestamp) and transferredToL2 (boolean) for SubgraphDeployment (small caveat, SubgraphDeployment doesn't have startedTransferToL2At in the network subgraph, so I already pinged Tiago about this, waiting on his response)
  • Unsure about Gateway requirements, as I don't have the code at hand. Most likely going to be using a combination of the transferredToL2-like booleans and auxiliary fields (timestamp, block number, transaction hash, etc)
  • L2 transfer tools also cause some side effects due to how they manage GRT balance changes due to transfers into and out of L1-L2. For the L2 side, the transfer tools trigger the normal code paths for inflows, so probably not a lot to do there, but for the L1 side, not a single one of the events for withdrawals are triggered, so they have to be handled manually within the L2 transfer tool events to get the correct values that are left over in L1. (i.e. to know the balances left over in L1 for Indexers, Delegators, Curators and Subgraphs)

@juanmardefago
Copy link
Contributor

Fields we need to have regarding L2 transfer tools:

  • id
  • idOnL1
  • idOnL2
  • startedTransferToL2
  • startedTransferToL2At
  • startedTransferToL2AtBlockNumber
  • startedTransferToL2AtTx
  • transferredToL2
  • transferredToL2At
  • transferredToL2AtBlockNumber
  • transferredToL2AtTx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p1 High priority size:large Large type:tracking Tracking issues with related scope
Projects
None yet
Development

No branches or pull requests

3 participants