Search
⌃K

Inputs

StreamingFast Substreams module inputs

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 the Chains and inputs documentation.
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.
The object's type is defined in the output.type attribute of the map module.
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
Learn more about maps in the Modules section.

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 modules are protobuf objects containing all the changes occurring in the store module available in the same block.
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;
}
Previous
Module types
Next
Output
Last modified 2mo ago