LogoLogo
Package RegistryThe Graph
  • Introduction
  • Getting Started
  • Tutorials
    • Develop Your First Substreams
      • on EVM
      • on Solana
        • Transactions & Instructions
        • Account Changes
      • on Cosmos
        • Injective
        • MANTRA
      • on Starknet
      • on Stellar
    • Publishing a Substreams Package
  • How-To Guides
    • Developing Substreams
      • on EVM
        • Exploring Ethereum
          • Mapping Blocks
          • Filter Transactions
          • Retrieve Events of a Smart Contract
      • on Solana
        • Explore Solana
          • Filter Instructions
          • Filter Transactions
        • SPL Token Tracker
        • NFT Trades
        • DEX Trades
      • on Cosmos
        • Injective
          • Simple Substreams Example
          • Foundational Modules
          • Dojo DEX USDT Volume Subgraph Example
    • Using a Substreams Sink
      • Substreams:SQL
      • Substreams:Subgraph
        • Triggers
        • Graph Out
      • Substreams:Stream
        • JavaScript
        • Go
      • Substreams:PubSub
      • Community Sinks
        • MongoDB
        • Files
        • Key-Value Store
        • Prometheus
    • EVM Extensions
      • Making eth_calls
    • Getting Started Using Rust and Protobuf
      • Rust
        • Option struct
        • Result struct
      • Protobuf Schemas
    • From Yellowstone to Substreams
  • Reference Material
    • Chains and endpoints
      • Ethereum Data Model
    • Never Miss Data
    • Development Container Reference
    • Substreams CLI
      • Install the CLI
      • Authentication
      • Substreams CLI reference
    • Substreams Components
      • Packages
      • Modules
        • Module types
        • Inputs
        • Output
        • Module handlers
        • Module handler creation
        • Indexes
        • Keys in stores
        • Dynamic data sources
        • Aggregation Windows
        • Parameterized Modules
      • Manifests Reference
    • Substreams Architecture
    • Graph-Node
      • Local Development
      • Publish to The Graph Network
    • Indexer Reference
      • Test Substreams Locally
    • Logging, Debugging & Testing
    • Change log
    • FAQ
  • Decentralized Indexing
    • What is The Graph?
Powered by GitBook
On this page
  • inputs overview
  • Input type source
  • Input type params
  • Input type map
  • Input type store
  • Store access mode
  • Store constraints
  • get mode
  • delta mode

Was this helpful?

Edit on GitHub
  1. Reference Material
  2. Substreams Components
  3. Modules

Inputs

StreamingFast Substreams module inputs

PreviousModule typesNextOutput

Last updated 14 days ago

Was this helpful?

inputs overview

Modules receive inputs of three types:

  • source

  • map

  • store

  • params

Input type source

An inputs of type source represents a chain-specific, Firehose-provisioned protobuf object. Learn more about the supported protocols and their corresponding message types in .

Note: The different blockchains reference different Block objects. For example, Solana references its Block object as sf.solana.type.v1.Block. Ethereum-based Substreams modules specify sf.ethereum.type.v2.Block.

The source inputs type __ is defined in the Substreams manifest. It is important to specify the correct Block object for the chain.

modules:
- name: my_mod
  inputs:
  - source: sf.ethereum.type.v2.Block

Clock object

The sf.substreams.v1.Clock object is another source type available on any of the supported chains.

The sf.substreams.v1.Clock represents:

  • Block number

  • Block ID

  • Block timestamp

Input type params

An inputs of type params represents a parameterizable module input. Those parameters can be specified either:

  • in the params section of the manifest,

  • on the command-line (using substreams run -p for instance),

  • by tweaking the protobuf objects directly when consuming from your favorite language

Input type map

An input of type map represents the output of another map module. It defines a parent-child relationship between modules.

Important: The graph built by input dependencies is a Directed Acyclic Graph, which means there can be no circular dependencies.

Define the map input type in the manifest and choose a name for the map reflecting the logic contained within it.

manifest excerpt
  inputs:
    - map: my_map

Input type store

A store inputs type represents the state of another store used by the Substreams module being created.

The developer defines the store inputs type in the Substreams manifest and gives the store a descriptive name that reflects the logic contained within it, similar to a map.

Store modules are set to get mode by default:

manifest excerpt
  inputs:
    - store: my_store # defaults to mode: get

Alternatively, set stores to deltas mode by using:

manifest excerpt
  inputs:
    - store: my_delta_store
      mode: deltas

Store access mode

Substreams uses two types of mode for modules:

  • get

  • delta

Store constraints

  • A store can only receive inputs as read-only.

  • A store cannot depend on itself.

get mode

get mode provides a key-value store readily queryable and guaranteed to be in sync with the block being processed.

Tip: get mode is the default mode for modules.

delta mode

delta mode enables you to loop through keys and decode values mutated in the module.

store deltas

The protobuf model for StoreDeltas is defined by using:

message StoreDeltas {
  repeated StoreDelta deltas = 1;
}

message StoreDelta {
  enum Operation {
    UNSET = 0;
    CREATE = 1;
    UPDATE = 2;
    DELETE = 3;
  }
  Operation operation = 1;
  uint64 ordinal = 2;
  string key = 3;
  bytes old_value = 4;
  bytes new_value = 5;
}

See the for more details.

The object's type is defined in the attribute of the map module.

Learn more about maps in the section.

delta mode modules are containing all the changes occurring in the store module available in the same block.

chains and endpoints
Modules
protobuf objects
Manifest's params manifest section of the Reference & specs
output.type