Tracking Contract Storage
This implementation pattern is, by default, used in both the ethereum-template-factory and the ethereum-template-singleton templates.
In VM implementations, accurately identifying and extracting relevant contract changes is essential.
The tycho_substreams::contract::extract_contract_changes
helper function simplifies this process significantly.
Note: These contract helper functions require the extended block model from substreams for your target chain.
Factory protocols
In factory-based protocols, each contract typically corresponds to a unique component, allowing its hex-encoded address to serve as the component ID, provided there is a one-to-one relationship between contracts and components.
The example below shows how to use a component store to define a predicate. This predicate filters for contract addresses of interest:
Other protocols
For protocols where contracts aren't necessarily pools themselves, you'll need to identify specific contracts to track. These addresses can be:
Hard-coded (for single-chain implementations)
Configured via parameters in your substreams.yaml file (for chain-agnostic implementations)
Read from the storage of a known contract (hardcoded or configured)
Here's how to extract changes for specific addresses using configuration parameters:
Last updated