Problem

processTransaction (pkg/stellar/stellar.go) calls getOperationEffect(tx.Hash) inside the per-effect loop. When a single Stellar transaction credits the bridge account more than once (multiple account_credited effects), this refetches the same operation data from Horizon once per matching effect — redundant API calls that slow down processing.

This is the remaining ask from #1051. The correctness parts of that issue (per-payment asset/issuer validation; not dropping payments after non-payment ops) were already resolved by #1094; this completes it.

Fix

Hoist the Horizon operations fetch to a lazy, fetch-at-most-once read, reused across all matching effects:

• The fetch still happens only when a matching TFT credit is present (no extra call for unrelated transactions).
• On a fetch error, behaviour is unchanged (the effect is skipped).
• Per-effect MintEvent emission is unchanged, so observable behaviour is preserved — only the redundant refetch is eliminated.

Note / possible follow-up

When a transaction has N matching credited effects, the loop still emits N identical MintEvents (each built from the same operations). These are de-duplicated downstream by the mint idempotency check (IsMintedAlready on tx.Hash), so this is behaviourally correct but does N passes over the same ops. Collapsing to a single MintEvent per transaction is a safe further cleanup, deliberately left out here to keep this change focused on the redundant API calls the issue calls out.

Verification

• go build ./..., go vet ./pkg/stellar/, gofmt — clean.
• Existing bridge tests pass.
• No unit test added: processTransaction fetches effects/operations directly from Horizon (no injection seam), so it isn't unit-testable without a mock Horizon server — consistent with the rest of this file. The change is behaviour-preserving and verified by build + review.

Closes #1051

🤖 Generated with Claude Code