[trungkien1992]

Account.get_transactions currently fetches every block timestamp from Ethereum mainnet and keys the mapping only by block height. A transfer on Base can receive Ethereum's timestamp, and a Base height above Ethereum's head can fail on a null block response. It also performs a separate block request for each globally distinct height even though Alchemy can include timestamps in transfer metadata.

This change requests withMetadata on every transfer page, uses the supplied UTC timestamps, and falls back on the originating chain only for missing, unusable or conflicting metadata. Fallbacks are deduplicated by (chain_id, block_number). Existing output fields, signed amounts, cache behavior and block-height sorting are preserved; the account documentation now describes the actual output.

Related to status-im/status-go#7883. This is an interim SDK improvement; it does not implement that issue's native wallet_ endpoint or add token addresses.

Validation:

• Python 3.12.2: all 18 credential-free regression tests pass against both the source checkout and the built 1.4.1 wheel.
• Three loopback HTTP scenarios, repeated three times each, pass all timestamp, schema, signed-amount, direction and request-count checks.
• In the one-chain fixture with 80 transfers across 40 blocks, requests fall from 42 to 2; the separate block requests fall from 40 to zero.
• Equal-height Ethereum/Base fixture: incorrect timestamps fall from 1 to zero. Mixed-metadata fixture: 3 to zero, with six total requests unchanged.
• The same tests and benchmark run against upstream commit 6eddfc2 fail the candidate acceptance criteria, retaining the observed incorrect timestamps.
• Wheel build, repository version/changelog check, compilation and whitespace checks pass locally. The existing CI workflow now runs the tests and benchmark on Python 3.11 and 3.12; the upstream Tests workflow currently reports action_required, so no remote test pass is claimed.

Rerun:

python -m pip install .
python -m unittest discover -s tests -v
python -m benchmarks.transaction_history --repeats 3 --output transaction-history.json

The benchmark uses actual requests HTTP transport to synthetic responses on 127.0.0.1. It needs no credentials or Status backend. These measurements establish controlled request counts and output correctness, not live Alchemy latency or availability. Network/category coverage across all configured chains and existing provider error/retry policies remain unchanged. Baseline import instructions and bounds are in docs/transaction-history-testing.md.

[nickninov]

@trungkien1992 thank you for the issue but the underlying issue of get_transactions is different. Currently we rely on external calls to fetch the data instead of using status-go natively. @friofry and I are currently working on resolving the issues.

[trungkien1992]

Thanks for clarifying, @nickninov. Would focused regression testing help with your native status-go changes? If so, which cases would be most useful to cover?