Choose the package and output module your stream runs, and keep that choice fixed in production. A Substreams package is the data pipeline: it decides which blocks are read, how they are transformed, and the output type your consumer decodes.
What a package contains
A package is a compiled .spkg file. You can reference one from the Substreams registry, by URL,
or from a local file.
| Term | Meaning |
|---|---|
| Package | A compiled .spkg containing a manifest, modules, Protobuf descriptors, and metadata. |
| Manifest | The source configuration that defines modules, inputs, binaries, and outputs. |
| Module | A map or store function in the package. |
| Map module | Emits transformed data for each block. |
| Store module | Maintains keyed state that other modules read. |
| Output module | The module a consumer streams from. |
Find a package
substreams.dev is the public package registry. Use it to find package names, versions, modules, output types, and package documentation. In the GraphOps platform, Discover Substreams lists popular packages for supported networks and shows a pinned release's modules and output types.
You do not upload packages to GraphOps. When you run a package against a GraphOps endpoint,
standard Substreams tooling resolves the package reference, whether it is a registry package or an
unpublished .spkg. Publish packages through the standard Substreams workflow and the
substreams.dev registry.
Keep your pipeline on a known version
Pin an explicit package version or .spkg reference in your consumer configuration so a package
update does not change your pipeline unexpectedly. GraphOps does not pin the package for you.
- Record the package reference, module name, start block, and endpoint in deployment config.
- Confirm the package supports a network before you run it there.
- Regenerate Protobuf types when you move to a release with a different output type.
- Keep the manifest and output type available to the team maintaining your consumer.