Skip to content

[PR #33] fetch_position_inner issues 3+ serial eth_calls per (borrower, vToken) — Multicall3 batching required #101

@obchain

Description

@obchain

PR: #33 (feat/08-venus-adapter)
File: crates/charon-protocols/src/venus.rs
Lines: 253-279, 341-349

Problem: fetch_position_inner issues at minimum 3 sequential eth_calls per (borrower, vToken): borrowBalanceStored, balanceOfUnderlying, getUnderlyingPrice. After issue #1 fix drops to 3 view calls but remains sequential. fetch_positions at lines 341-349 iterates borrowers sequentially, no concurrency. 50 borrowers × 8 markets = ~1,200 round-trip RPC calls per block, each paying full round-trip latency (~300ms BSC median).

Impact: BSC block cadence 3s; 1,200 serial calls at 50ms each = 60s scan. 20× block time. Scanner perpetually falls behind. Liquidation opportunities expire before bot acts. Scalability blocker for any production deploy with non-trivial borrower list.

Fix: Use Multicall3 (0xcA11bde05977b3631167028862bE2a173976CA11, deployed on BSC mainnet) to batch per-market calls for single borrower into one eth_call. Process borrowers concurrently with futures::stream::FuturesUnordered or tokio::task::JoinSet. alloy multicall feature provides ergonomic batching. Minimum: batch 3 per-vToken calls; ideal: batch all borrowers' getAccountLiquidity calls in single Multicall3 aggregate.

Metadata

Metadata

Assignees

No one assigned

    Labels

    layer:rustRust crates (core / scanner / protocols / executor / cli)pr-reviewFindings from PR review processpriority:p1-coreCore MVP scope

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions