feat: add Balancer V3 reclamm pool types

[johngrantuk]

Adds support for Balancer V3 reClamm pools (rebranded as AutoRange).
Initial test pool can be found here: https://balancer.fi/pools/ethereum/v3/0xda66e8ddf9959e4db759bfd06256730d8a8b2d13

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[zach030]

Hi! Thanks for the work.

This part wasn’t changed by you, but I suspect the logic here might be wrong.
I don’t think we should use wrapped_token as the component_id to look up the related tokens.

I have a rough idea you could use as a reference. You can look at the previous liquidityBuffer integration PR I worked on. The flow would be:

1. Detect the liquidityBuffer creation: 1_map_components.rs
2. Write the mapping (wrapped_token->underlying_token) into a store: 4_store_token_mapping.rs
3. When updating vault reserves, read the wrapped_token / underlying_token relationship from that store:
   7_map_protocol_changes.rs

[zach030]

Hey @johngrantuk! I debugged it and pushed some updates.
There were mainly two issues:

• Reading balances from Swap, LiquidityAdded, and LiquidityRemoved can drift, because Balancer-v3 has some fees that don’t show up in those events.
• The reservesOf update logic also had issues. The previous wrapped_token / underlying_token handling couldn’t update balances correctly.

I changed the balance logic to decode the _poolTokenBalances mapping instead, and added a token mapping store to track the wrapped_token -> underlying_token relation. The tests pass locally now.

Could you review whether this matches the balancer-v3 design, especially around token balance handling, and try running more test cases?

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

Since your pull request originates from a forked repository, GitGuardian is not able to associate the secrets uncovered with secret incidents on your GitGuardian dashboard.
Skipping this check run and merging your pull request will create secret incidents on your GitGuardian dashboard.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
-	-	Generic High Entropy Secret	357e94f	protocols/substreams/ethereum-balancer-v3/substreams.yaml	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}