Skip to main content

Optimism Manifest File

SubQuery TeamAbout 5 min

Optimism Manifest File

Important

We use Ethereum packages, runtimes, and handlers (e.g. @subql/node-ethereum, ethereum/Runtime, and ethereum/*Handler) for Optimism. Since Optimism is an EVM-compatible layer-2 scaling solution, we can use the core Ethereum framework to index it.

The Manifest project.yaml file can be seen as an entry point of your project and it defines most of the details on how SubQuery will index and transform the chain data. It clearly indicates where we are indexing data from, and to what on chain events we are subscribing to.

The Manifest can be in either YAML or JSON format. In this document, we will use YAML in all the examples.

Below is a standard example of a basic Optimism project.yaml.

specVersion: "1.0.0"

name: "subql-example-optimism-airdrop"
version: "0.0.1"
runner:
  node:
    name: "@subql/node-ethereum"
    version: "*"
  query:
    name: "@subql/query"
    version: "*"
description: "This project can be use as a starting point for developing your new Optimism SubQuery project. It indexes all claim events from the Optimism airdrop"
repository: "https://github.com/subquery/subql-example-optimism-airdrop"

schema:
  file: "./schema.graphql"

network:
  # chainId is the EVM Chain ID, for Optimism this is 10
  # https://chainlist.org/chain/10
  chainId: "10"
  # This endpoint must be a public non-pruned archive node
  # We recommend providing more than one endpoint for improved reliability, performance, and uptime
  # Public nodes may be rate limited, which can affect indexing speed
  # When developing your project we suggest getting a private API key
  # You can get them from OnFinality for free https://app.onfinality.io
  # https://documentation.onfinality.io/support/the-enhanced-api-service
  endpoint:
    [
      "https://optimism.api.onfinality.io/public",
      "https://mainnet.optimism.io",
      "https://endpoints.omniatech.io/v1/op/mainnet/public",
      "https://opt-mainnet.g.alchemy.com/v2/demo",
      "https://rpc.ankr.com/optimism",
    ]
  # Recommended to provide the HTTP endpoint of a full chain dictionary to speed up processing
  dictionary: "https://api.subquery.network/sq/subquery/optimism-dictionary"

dataSources:
  - kind: ethereum/Runtime # We use ethereum runtime since Optimism is a layer-2 that is compatible
    startBlock: 100316590 # When the airdrop contract was deployed https://optimistic.etherscan.io/tx/0xdd10f016092f1584912a23e544a29a638610bdd6cb42a3e8b13030fd78334eba
    options:
      # Must be a key of assets
      abi: airdrop
      address: "0xFeDFAF1A10335448b7FA0268F56D2B44DBD357de" # this is the contract address for Optimism Airdrop https://optimistic.etherscan.io/address/0xfedfaf1a10335448b7fa0268f56d2b44dbd357de
    assets:
      airdrop:
        file: "./abis/airdrop.abi.json"
    mapping:
      file: "./dist/index.js"
      handlers:
        - handler: handleClaim
          kind: ethereum/LogHandler # We use ethereum handlers since Optimism is a layer-2 that is compatible
          filter:
            topics:
              ## Follows standard log filters https://docs.ethers.io/v5/concepts/events/
              - Claimed(uint256 index, address account, uint256 amount)
              # address: "0x60781C2586D68229fde47564546784ab3fACA982"

Overview

Top Level Spec

FieldTypeDescription
specVersionStringThe spec version of the manifest file
nameStringName of your project
versionStringVersion of your project
descriptionStringDescription of your project
runnerRunner SpecRunner specs info
repositoryStringGit repository address of your project
schemaSchema SpecThe location of your GraphQL schema file
networkNetwork SpecDetail of the network to be indexed
dataSourcesDataSource SpecThe datasource to your project
templatesTemplates SpecAllows creating new datasources from this templates

Schema Spec

FieldTypeDescription
fileStringThe location of your GraphQL schema file

Network Spec

If you start your project by using the subql init command, you'll generally receive a starter project with the correct network settings. If you are changing the target chain of an existing project, you'll need to edit the Network Spec section of this manifest.

The chainId is the network identifier of the blockchain. In Optimism it is 10. See https://chainlist.org/chain/10.

Additionally you will need to update the endpoint. This defines the (HTTP or WSS) endpoint of the blockchain to be indexed - this must be a full archive node. This property can be a string or an array of strings (e.g. endpoint: ['rpc1.endpoint.com', 'rpc2.endpoint.com']). We suggest providing an array of endpoints as it has the following benefits:

  • Increased speed - When enabled with worker threads, RPC calls are distributed and parallelised among RPC providers. Historically, RPC latency is often the limiting factor with SubQuery.
  • Increased reliability - If an endpoint goes offline, SubQuery will automatically switch to other RPC providers to continue indexing without interruption.
  • Reduced load on RPC providers - Indexing is a computationally expensive process on RPC providers, by distributing requests among RPC providers you are lowering the chance that your project will be rate limited.

Public nodes may be rate limited which can affect indexing speed, when developing your project we suggest getting a private API key from a professional RPC provider like OnFinalityopen in new window.

There is a dictionary for Optimism which is https://api.subquery.network/sq/subquery/optimism-dictionary.

FieldTypeDescription
chainIdStringA network identifier for the blockchain
endpointStringDefines the endpoint of the blockchain to be indexed - This must be a full archive node.
portNumberOptional port number on the endpoint to connect to
dictionaryStringIt is suggested to provide the HTTP endpoint of a full chain dictionary to speed up processing - read how a SubQuery Dictionary works.
bypassBlocksArrayBypasses stated block numbers, the values can be a range(e.g. "10- 50") or integer, see Bypass Blocks

Runner Spec

FieldTypeDescription
nodeRunner node specDescribe the node service use for indexing
queryRunner query specDescribe the query service

Runner Node Spec

FieldTypeDescription
nameString@subql/node-ethereum We use the Ethereum node package for Optimism since it is compatible with the Ethereum framework
versionStringVersion of the indexer Node service, it must follow the SEMVERopen in new window rules or latest, you can also find available versions in subquery SDK releasesopen in new window

Runner Query Spec

FieldTypeDescription
nameString@subql/query
versionStringVersion of the Query service, available versions can be found hereopen in new window, it also must follow the SEMVER rules or latest.

Datasource Spec

Defines the data that will be filtered and extracted and the location of the mapping function handler for the data transformation to be applied.

FieldTypeDescription
kindstringethereum/Runtime We use the Ethereum runtime for Optimism since it is compatible with the Ethereum framework
startBlockIntegerThis changes your indexing start block, set this higher to skip initial blocks with less data
mappingMapping Spec

Mapping Spec

FieldTypeDescription
handlers & filtersDefault handlers and filtersList all the mapping functions and their corresponding handler types, with additional mapping filters.

Data Sources and Mapping

In this section, we will talk about the default Optimism runtime and its mapping. Here is an example:

dataSources:
  - kind: ethereum/Runtime # We use ethereum runtime since Optimism is a layer-2 that is compatible
    startBlock: 100316590
    # startBlock: 9277162 # When the airdrop contract was deployed https://optimistic.etherscan.io/tx/0xdd10f016092f1584912a23e544a29a638610bdd6cb42a3e8b13030fd78334eba
    options:
      # Must be a key of assets
      abi: airdrop
      address: "0xFeDFAF1A10335448b7FA0268F56D2B44DBD357de" # this is the contract address for Optimism Airdrop https://optimistic.etherscan.io/address/0xfedfaf1a10335448b7fa0268f56d2b44dbd357de
    assets:
      airdrop:
        file: "./abis/airdrop.abi.json"
    mapping:
      file: "./dist/index.js"
      handlers:
      ...

Mapping Handlers and Filters

The following table explains filters supported by different handlers.

Your SubQuery project will be much more efficient when you only use TransactionHandler or LogHandler handlers with appropriate mapping filters (e.g. NOT a BlockHandler).

HandlerSupported filter
ethereum/BlockHandlermodulo, timestamp
ethereum/TransactionHandlerfunction filters (either be the function fragment or signature), from (address), to (address)
ethereum/LogHandlertopics filters, and address

Default runtime mapping filters are an extremely useful feature to decide what block, event, or extrinsic will trigger a mapping handler.

Only incoming data that satisfies the filter conditions will be processed by the mapping functions. Mapping filters are optional but are highly recommended as they significantly reduce the amount of data processed by your SubQuery project and will improve indexing performance.

The modulo filter allows handling every N blocks, which is useful if you want to group or calculate data at a set interval. The following example shows how to use this filter.

filter:
  modulo: 50 # Index every 50 blocks: 0, 50, 100, 150....

Real-time indexing (Block Confirmations)

As indexers are an additional layer in your data processing pipeline, they can introduce a massive delay between when an on-chain event occurs and when the data is processed and able to be queried from the indexer.

SubQuery provides real time indexing of unconfirmed data directly from the RPC endpoint that solves this problem. SubQuery takes the most probabilistic data before it is confirmed to provide to the app. In the unlikely event that the data isn’t confirmed and a reorg occurs, SubQuery will automatically roll back and correct its mistakes quickly and efficiently - resulting in an insanely quick user experience for your customers.

To control this feature, please adjust the --block-confirmations command to fine tune your project and also ensure that historic indexing is enabled (enabled by default)

Bypass Blocks

Bypass Blocks allows you to skip the stated blocks, this is useful when there are erroneous blocks in the chain or when a chain skips a block after an outage or a hard fork. It accepts both a range or single integer entry in the array.

When declaring a range use an string in the format of "start - end". Both start and end are inclusive, e.g. a range of "100-102" will skip blocks 100, 101, and 102.

network:
  chainId: "1"
  endpoint: "https://optimism.api.onfinality.io/public"
  bypassBlocks: [1, 2, 3, "105-200", 290]

Validating

You can validate your project manifest by running subql validate. This will check that it has the correct structure, valid values where possible and provide useful feedback as to where any fixes should be made.