Score the fee-bump outer account, not just the inner transaction's destination

[knytcomics-ui]

Summary

extractDestination correctly unwraps FeeBumpTransaction.innerTransaction to find the payment destination (decodeTransaction.ts:39), but never considers the fee-bump's own fee-source account, which is a distinct trust signal.

Current Behavior / Relevant Code

• src/decode/decodeTransaction.ts:39 -- tx.innerTransaction extraction discards parsed.feeSource entirely.

Why This Matters

Fee-bump sponsorship is an underused but real signal -- a dApp or third party silently sponsoring your transaction fee is exactly the kind of 'unusual signal' the 'Elevated' tier (README.md:43) is meant to catch, and today it's invisible.

Proposed Solution

• When the parsed transaction is a FeeBumpTransaction, additionally capture parsed.feeSource and pass it through as supplementary context (surfaced in the popup at minimum, not necessarily scored the same way as a payment destination).
• Add fixtures/tests for fee-bumped transactions with a fee source distinct from the transaction's own source account.

Acceptance Criteria

• Fee-bump fee-source is captured and available to the popup/scoring layer.
• Existing fee-bump destination-extraction behavior (inner tx) is unchanged and still tested.

Definition of Done

• npm run lint, npm run typecheck, npm test, and npm run build all pass locally and in CI
• New or changed behavior is covered by unit tests (and integration/E2E tests where the change touches interception, background messaging, or the popup)
• Any user-facing or architectural change is reflected in README.md
• No regressions to the existing test suite or existing tier/interception behavior

How to Claim This Issue (Application Process)

1. Comment first. Post a short implementation plan on this issue — your proposed approach, the files you expect to touch, and any open questions — before writing code. This prevents duplicate effort and lets a maintainer flag concerns early, which matters especially for an issue at this complexity level.
2. Wait for assignment. A maintainer will review your plan and assign the issue to you, typically within 48 hours. Please do not open a draft PR before you're assigned.
3. Stay active. If there's no visible activity (commits or comments) for 10 days after assignment, the issue may be unassigned and reopened to other contributors.
4. Submit a scoped PR. Reference this issue (Closes #<issue-number>), keep the diff scoped to the acceptance criteria above, and ensure all CI gates pass before requesting review.
5. Engage with review. Respond to review feedback within a reasonable timeframe; PRs with no response after 7 days may be closed pending resubmission when you're ready to pick it back up.

---

Category: Transaction Decoding Coverage
Estimated effort: S (small, ~1-2 days)
Difficulty: Advanced — this issue assumes familiarity with the codebase's MV3 service-worker architecture, the Freighter interception protocol, and/or the Stellar SDK.

[devfoma]

Hello, I would love to take on this issue. I'm a software engineer with over 4 years experience. and i'm confident I can resolve this issue

[DevALVIN-24]

Hi, I'd like to work on this issue! because I am very conversant with solving problems like this, and i can submit the pr with 48hr

[grantfox-oss]

🦊 GrantFox — @devfoma has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #22)
2. Your PR will be reviewed by the Gryd-lock maintainers

Good luck! Track your progress on GrantFox.