AppBlog

Configuring YAML

The studio.yaml is the entry point to your project. It defines the smart contracts you index, which events/functions from these contracts to pay attention to, and how to map their data to entities that are stored and allowed to query. 

Version: 2.0.0
Type: instance
Metadata:
  name: Project Apollo
  description: A top-secret research project to the moon
Auth:
  userId: process.env.USER_ID
  projectId: process.env.PROJECT_ID
  accessKey: process.env.ACCESS_KEY
  secretKey: process.env.SECRET_KEY
Path:
  schema: ./studio.schema.ts
  docker: ./docker-compose.yml
Environment:
  testing:
    startBlock: latest
    network: Ethereum
    execution: parallel
    rpc: ENTER_YOUR_RPC_HERE
    range: 10
  deployment:
    startBlock: latest
    network: Ethereum
    execution: parallel
Resources:
  - name: usdc
    type: contract/event
    abi: src/abis/usdc.json
    address: '0xdAC17F958D2ee523a2206206994597C13D831ec7'
    triggers:
      - event: Transfer(address indexed,address indexed,uint256)
        handler: src/handlers/usdc/Transfer.TransferHandler

Key Sections:

  • Version: This is a mandatory field for CLI version 2.0.0 or higher. It specifies the template version used to define the project template.

  • Type: Indicates whether the project template contains api or instance resources, which dictates how testing and deployment processes will be handled.

  • Metadata: Contains project metadata such as the project name and description. This information is useful for identifying and documenting your project.

  • Auth: Stores your Blockflow credentials, including the access key, secret key, user ID, and project ID. These are required for authentication and authorisation within the project.

  • Path: Specifies the file paths for important project files, such as the schema (studio.schema.ts) and Docker Compose configuration (docker-compose.yml).

  • Environment: Defines the environment settings for testing and deployment. This includes the blockchain network, execution mode (e.g., parallel), the RPC endpoint, and block range.

  • Resources: Specifies the smart contracts you want to index or the APIs you intend to build, depending on the template type. For example, it includes contract addresses, ABI files, and event handlers associated with the contract.

Supported Network

The command-line interface (CLI) supports multiple networks for deployment and interaction. When using the CLI, you can specify the target network environment for your operations.

export const SUPPORTED_NETWORK = [
  "Ethereum",
  "Linea",
  "Optimism",
  "Polygon",
  "Avalanche",
  "Base",
  "Arbitrum",
  "Manta",
  "Zkevm",
  "Scroll",
  "Bsc",
];

You can use Blockflow CLI to run instance tests on any network with an available RPC endpoint. Choose a network with an accessible RPC endpoint and use Blockflow CLI to run your instance tests on that network.

Note: Currently, we only support deployments to above networks. However, we are actively expanding our supported chain list.

Resources

Within the resources section, you can define one or more data sources. Blockflow allows you to define the type of resource you want to index based on the triggers you need. The platform supports a wide range of resources types, enabling you to customize your instances according to your specific requirements.

  1. contract/event: This resource type allows you to set up a trigger that executes an action when a specific event is emitted by a smart contract. For example, you can index the data associated with a token transfer event or track updates to a particular state variable in a contract.

  2. contract/function:With this resource type, you can execute an action when a particular function in a smart contract is called. This can be useful for indexing the input and output data of a function call, tracking state changes, or monitoring specific smart contract interactions.

  3. transaction/event: This resource type enables you to set up a trigger based on transactions occurring on the blockchain. This can be helpful for tracking and indexing data related to specific types of transactions, such as token transfers, contract deployments, or any other relevant transaction events.

  4. api/rest: Allows you to create a RESTful API interface for accessing and manipulating data in your existing databases.

  5. api/graphql: Enables the creation of a custom GraphQL API endpoint to interact with your project's databases.

Field
Description

name

The name of the source data.

type

The type of resource.

abi

The path to the smart contract's ABI file. The ABI defines the contract’s interface and is used to interact with it.

address

The address of the source data.

triggers

It contains an array of configurations linking smart contract events/functions to their corresponding handler functions.

Triggers

The triggers section contains an array of configurations linking smart contract events/functions to their corresponding handler functions. Each configuration maps an event/function to the handler executed when triggered.

It vary according to Type of resource.

  • contract/event

Triggers:
      - Event: Transfer(address indexed,address indexed,uint256)
        Handler: src/handlers/usdt/Transfer.TransferHandler

  • contract/function

Triggers:
      - Function: approve(address,uint256)
        Handler: src/handlers/usdt/approve.approveHandler

  • transaction/event

Triggers:
      - Event: Transfer(address indexed,address indexed,uint256)
        Handler: src/handlers/usdt/Transfer.TransferHandler

You don't need to define address in Resources for transaction/event type.

Once you define the name, address, type, and ABI path for your smart contracts in the resources section, you can use the blockflow generate command to automatically populate the trigger configurations.

Points to Consider While Writing studio.yaml

  1. Handler File Paths: Ensure handler file paths in the Triggers section match the actual file locations. Incorrect paths will cause webpack errors.

  2. Handler Definition: Define all handler functions at their respective file paths specified in the subgraph.yaml. Missing handlers will result in errors.

  3. Event Parameter Formatting: Write event parameter types without spaces, e.g., MessageReceived(address indexed,uint32,uint64 indexed,bytes32,bytes). Improper formatting can lead to indexing errors. Same for functions.

After completing your YAML file, it's recommended to run the blockflow validate command before proceeding. This command ensures that your studio.yaml file is correctly configured and free of errors.

PreviousBuilding BlocksNextSetting up Database Schema

Last updated