mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-08-09 16:14:40 +00:00
Claude
45aa6044b7
Audit findings from an independent code review: - HIGH: When the user zaps their own post (a common flow), every split that included the post author put the sender on the recipient list, and OnchainZapBuilder.buildSplit refused the whole tx with "cannot zap yourself". Fix: new OnchainZapSplitter.prepare() filters the sender's pubkey out of the splits before they reach the builder. - HIGH: NIP-57 lets the same pubkey appear in zap-split tags more than once (additive weights). buildSplit rejected duplicate recipients. Same prepare() helper merges duplicates by summing weights, in first-seen order. - HIGH: The dialog's live preview only showed amounts for recipients whose share was BELOW dust (because DustRecipientException only carries belowDust). Fix: parent composable computes shares with a zero dust threshold for the preview, gating the Send button on a separate belowDustShares check so the user can see all amounts and can't tap Send into a guaranteed BUILDING-stage failure. - MEDIUM: OnchainZapSendResult.Failure didn't carry the ids of receipts that successfully published before a partial-publish failure. Added publishedReceiptEventIds: List<HexKey>. - LOW: useSplits state was keyed by zappedEvent reference; re-emitted bundles would silently reset the toggle. Now keyed on the event id. Tests added: - splitter: prepare() drops sender, merges duplicates, filters non-positive weights; floating-point weights (0.1 + 0.2) sum exactly - builder: buildSplit produces N recipient outputs + 1 change at index N, conserves sats, rejects duplicates and below-dust shares - sender: sendSplit publishes one receipt per recipient sharing the txid with correct per-recipient amount; partial-publish failure carries the broadcast txid and the ids of receipts that did publish