You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: exclude offer-locked holdings from indexed balances (#340)
* feat(indexer): exclude offer-locked holdings from balances
Offer-based transfers (USDCx/AllocationFactory) lock the sender's holding when
an offer is created; the locked amount is escrowed, not spendable. The indexer
derived balances purely from holding create/archive, so the sender's balance
only dropped at accept — the offered amount still showed as available while the
offer was pending.
Capture the holding's `lock` field in the decoder and skip locked holdings in
the processor (neither stored nor counted). Because a locked holding is never
stored, its later archive is a no-op, and the matching unlocked holding — created
for the receiver on accept or returned to the sender on claim-back — drives the
balance change. Net effect: the sender's balance is reduced when the offer locks
the funds, credited to the receiver on accept, and restored to the sender on
claim-back. Direct CIP-56 transfers are unaffected (their holdings are unlocked).
No migration: locked holdings are simply not persisted.
Implements #338.
* test(e2e): assert offer-time balance deduction in P1↔P1 USDCx transfer
Extend TestUSDCx_InternalTransfer_P1HolderToP1Holder: after User1 offers 10 of
its 15 USDCx to User2 (and before User2 accepts), assert User1's spendable
balance has already dropped to 5 — confirming the indexer excludes the locked
(escrowed) holding from balances at offer time, not only on accept.
Adds WaitForAPIBalanceExact (the existing >= helper can't detect a decrease).
0 commit comments