Only track balances of tokens with internal buffer trading

[MartinquaXD]

Description

The protocol allows to do internal buffer trading which means a solver is allowed to use the settlement contract's token balances as if it was an AMM. To enable solvers to make use of this the driver continuously monitors the settlement contract's token balances and writes them into the auction instance.
However, so far the driver kept monitoring token balances for every token it ever needed to fetch metadata for despite only a couple of tokens actually being allow listed for internal buffer trading.

This oversight leads to tons of RPC requests being wasted. The number scales with the tokens_seen_by_driver * block_interval which leads to especially wasteful traffic on chains like BNB which have a good amount of traffic and are very fast.
For example here we can see that after 4 days of running the driver we continuously use ~4 times as many RPC requests for fetching token balances for the settlement contract as for the traders. At the peak roughly half of the driver's RPC requests were dedicated to that when it actually should be 0 because as it turns out there aren't even any tokens on BNB where internal buffer trading is currently allowed.

Changes

Instead of monitoring the balances for every tokens the driver ever saw we explicitly mark tokens for monitoring whenever we build a new auction.
Since the set of tokens to monitor is not expected to change often I tried to make this logic as zero overhead as possible by first taking a read lock to see which tokens need updating at all (on average 0) and I also avoided allocating vectors as much as possible.

[claude]

Claude finished @MartinquaXD's task in 1m 45s —— View job

---

PR Review: Only track balances of tokens with internal buffer trading

• Read the diff and surrounding code
• Analyze correctness of the new monitoring logic
• Post inline findings

Nice, targeted optimization — the read-lock-first / avoid-allocation approach in keep_track_of_balances is clean, and gating get→keep_track_of_balances ordering guarantees the trusted tokens are already cached before the flag is set. 👍

I found one issue (posted inline):

• update_balances write-back loop logs every non-monitored token each block (crates/driver/src/infra/tokens.rs:139). balances now only holds monitored tokens, but the loop still iterates the whole cache, so every non-monitored token lands in keys_without_balances and gets logged at info! on every block. Filtering the loop to monitor_balance entries fixes the spam and makes it cheap in the common case. Fix →

Minor (non-blocking) observations, no change required:

• A trusted token whose metadata fetch fails in get won't be present in the cache and so will never be monitored — pre-existing edge case, fine to leave.
• monitor_balance is monotonic (a token that stops being trusted keeps being monitored), which matches the PR's "set doesn't change often" assumption.

[gemini-code-assist]

Code Review

This pull request introduces continuous balance monitoring for trusted tokens by adding a monitor_balance flag to token metadata and registering these tokens during solve requests. A critical issue was identified where filtering the updated balances to only monitored tokens causes unmonitored tokens to be incorrectly flagged as missing during the cache update loop, which would spam the logs on every block. The feedback suggests updating the cache iteration logic to only check and report missing balances for tokens that are actually being monitored.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[jmg-duarte]

LGTM, but couldn't we pass the list of trusted tokens to Inner and set monitor_balance accordingly right on insert instead of continuously updating the monitor_balance field?

[MartinquaXD]

couldn't we pass the list of trusted tokens to Inner and set monitor_balance accordingly right on insert instead of continuously updating the monitor_balance field?

The set of trusted tokens is defined by the protocol so configuring them in the driver means everyone has to keep those settings in sync.
For context the list of trusted tokens has 27 items on mainnet at the moment so in practice we are only paying the cost of 27 hashmap lookups which I think justifies this simpler logic.