Overview
release_funds iterates over all recipients in a loop, each requiring a storage read and a token transfer. For invoices with 20 recipients this approaches the compute limit. Optimize the iteration pattern.
Acceptance Criteria
- Recipients stored as a contiguous
Vec in a single storage key instead of one key per recipient
- Single
env.storage().get to load the full recipient list; single env.storage().set to write paid flags
- Token transfers batched where the asset contract supports multi-transfer (SEP-41 check)
- Benchmark:
release_funds with 20 recipients must stay under 50% of the Soroban instruction limit
- No change to the external API —
get_invoice still returns the same recipient shape
- Migration: existing invoices with old storage layout handled by a one-time migration helper in the upgrade path
- Integration tests: 1 recipient, 5 recipients, 20 recipients — verify instruction counts
Overview
release_fundsiterates over all recipients in a loop, each requiring a storage read and a token transfer. For invoices with 20 recipients this approaches the compute limit. Optimize the iteration pattern.Acceptance Criteria
Vecin a single storage key instead of one key per recipientenv.storage().getto load the full recipient list; singleenv.storage().setto write paid flagsrelease_fundswith 20 recipients must stay under 50% of the Soroban instruction limitget_invoicestill returns the same recipient shape