128de3037e
* fix: Misc improvements Make module_name optional and default to map_protocol_changes Add build instructions for the DB image inside of the docker-compose Improve error message Remove unnecessary module_name from yaml files #time 39m * fix: Bring back module_name in balancer v3 tests #time 8m * fix: Fix balance and allowance overwrites For tokens with proxies we need to use the address that is returned by the detector #time 13m
Instructions
The run command for our substream is a little different here due to the inclusion of the dynamic parameters for manually admitted pools.
This command will add extra parameters to the map_components module via the python params.py script. This embeds
directly in the bash/zsh compatible command here. If python is not ideal, the script can be easily converted into
bash but it would require the jq executable (I've used AI to convert it just fine in testing).
$ substreams run -e mainnet.eth.streamingfast.io:443 substreams.yaml map_protocol_changes --start-block 11507454 --stop-block +100 -p map_components=`python params.py`
params.json
This json file is a top-level array containing objects that describe a specific ProtocolComponent. Each object
contains the following fields:
name: Just for documentation purposesaddress: The lowercase address of the componenttx_hash: The hash of the transaction where the component was emittedtokens: A list of token addresses ordered in the exact same way as the Poolstatic_attributes: A nested object of key to value that represents the static attributes of the component.attributes: A nested object of key to value that represents attributes.
Please see the included 3 examples for 3pool, steth, and tricrypto2.
Open tasks
Add underlying tokens in metapools
Currently, metapools are not working properly due to the way we override token balances. The issue arises because when we modify token balances, we end up changing the token contract code and storage. This issue will be resolved once we implement a flexible method to adjust token balances without affecting the contract’s functionality. We will also need to index additional contract such as the base pool lp token.
Handle rebasing, ERC4644 and others special kind of tokens
At the moment, we are unable to manage certain types of tokens, such as rebasing tokens or ERC4644 tokens, because they have unique behavior or specific logic that complicates simulations. To handle these tokens properly, we will likely need to use the dynamic contract indexer (DCI), which can track and index the full state of the token contract, allowing us to deal with their complexities effectively.
Static Attributes
| name | type | description |
|---|---|---|
| pool_type | str | A unique identifier per pool type. Set depending on the factory. |
| name | str | A string representing the name of the pool, set if there is one. |
| factory_name | str | A string representing the name of the factory that created the pool. "na" if the pool was manually created. |
| factory | bytes | The address of the factory that created the pool. "0x000..." if the pool was manually created. |
| lp_token | bytes | The pool lp token, set if the lp token is not the pool itself |
| base_pool | bytes | The base pool related to this pool, set only for metapools. |