Context

For holders of milestone-based SV grants to mint their milestone based rewards, they need to prove that they haven't minted before. This requires the foundation and grant holder to run the scripts/unclaimed_rewards.py script for the time interval from SV granting to the current time to check that nothing has yet been minted.

When running the following call on my dev machine connected to VPN, I observe a timing of ~30s per hour of txs:

./unclaimed_sv_rewards.py https://scan.sv-1.global.canton.network.sync.global \
      --beneficiary 23d169c2-0909-4c70-81d1-1922de6febaa::12200e2eb783da98a6c55a9ea7a6415cf36582c3f2f031a02e54d07033610782abb5 \
      --begin-migration-id 3 \
      --begin-record-time 2025-08-01T00:00:00Z \
      --end-record-time 2025-11-18T22:15:00Z \
      --weight 2 \
      --already-minted-weight 0

Thus a total of 26h or more is to be expected for the full computation. Likely more, as the tx volume increases over time.

I've also observed the script dying on a 503 error.

Problems

• performance: the script is too slow. 1h per month of data would be acceptable
• robustness: the script dies on a 503 error, and likely other HTTP errors
• deprecated endpoints: the script uses the deprecated /v0/updates endpoint. It should use the /v1/updates endpoint.
• insufficient logging:
  • timestamps are missing in log messages
  • log messages are not detailed enough to determine progress
• docs are hidden in a PR instead of shared as part of normal splice docs