Skip to content

perf: Batch Stellar Horizon balance queries instead of sequential per-token calls #60

Description

@YaronZaki

Problem Statement

StellarClient.get_token_balances() in blockchain_call.py:94-114 iterates over tokens and calls get_balance() sequentially for each token. This results in N HTTP requests to Horizon for N tokens when a single account query would return all balances.

Evidence

# quantara/web_app/contract_tools/blockchain_call.py:94-114
async def get_token_balances(self, holder_address: str) -> dict[str, str]:
    balances: dict[str, str] = {}
    for token in TokenParams.tokens():  # Sequential per-token calls!
        bal = await self.get_balance(
            asset_code=token.asset_code,
            holder_address=holder_address,
        )
        balances[token.name] = bal
    return balances

Meanwhile, get_balance() already fetches the full account from Horizon (/accounts/{holder_address}) but then discards all balances except the requested one.

Impact

Medium — unnecessary latency. N sequential HTTP round-trips where 1 would work. Page load time scales linearly with number of supported tokens. Currently 3 tokens = 3 sequential calls; adding more tokens worsens the problem.

Proposed Solution

Refactor get_token_balances() to make a single Horizon /accounts/{holder_address} call, extract all balances from the response, and filter to supported tokens. This reduces N sequential calls to 1.

Acceptance Criteria

  • get_token_balances() makes single Horizon call per invocation
  • All supported token balances extracted from single account response
  • Same return type preserved: dict[str, str]
  • Error handling preserved (returns empty balances on failure)
  • All existing tests pass

File Map

  • quantara/web_app/contract_tools/blockchain_call.py:94-114 — refactor to single call

Dependencies

  • Related: REPO-018 (caching layer complements batching)

Testing Strategy

  • Unit: Test with mocked account response containing multiple balances
  • Integration: Compare results of old sequential vs. new batched approach for same account

Security Considerations

No security impact. Pure performance optimization.

Definition of Done

  • Code implemented and peer-reviewed
  • Tests written and passing
  • PR linked and merged

Labels: performance
Priority: Medium
Difficulty: Intermediate
Estimated Effort: 3h

Metadata

Metadata

Assignees

Labels

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions