Tracking Contract Storage
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:
use tycho_substreams::contract::extract_contract_changes;
// all changes on this block, aggregated by transaction
let mut transaction_changes: HashMap<_, TransactionChanges> = HashMap::new();
extract_contract_changes(
&block,
|addr| {
components_store
.get_last(format!("pool:{0}", hex::encode(addr)))
.is_some()
},
&mut transaction_changes,
);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