🟠 `scValToString` renders contract addresses as raw hex, not StrKey — event filtering and history display are broken

[Ejirowebfi]

Area: Frontend · frontend/src/services/stellar-impl.ts (scValToString, getTokenInfoByAddress, getTokenEvents)

Description

For scvAddress values of contract type, scValToString returns the raw 32-byte contract ID as a
hex string instead of the canonical C... StrKey encoding (stellar-impl.ts:254-256,
StrKey.encodeContract is never used). Every event field that holds a token contract address
(created.tokenAddress, mint.tokenAddress, burn.tokenAddress, meta.tokenAddress) is therefore
stored in an encoding no other part of the system uses. Downstream:

• getTokenInfoByAddress(tokenAddress) compares e.data.tokenAddress === tokenAddress where the
  argument is a C... StrKey — the comparison never matches, so every token falls into the
  fallback branch (name = raw address, decimals = 7, no creator, no metadata).
• getTokenEvents filters the same way — the per-token history view is always empty.
• Transaction History and CSV export show meaningless hex blobs where addresses should be, and
  explorer links built from them are dead.

Tasks

• Encode contract addresses with StrKey.encodeContract(addr.contractId()) in scValToString
  (and audit the account branch for muxed-account handling while there).
• Prefer scValToNative + a thin formatting layer over the hand-rolled decoder where possible, to
  lean on the SDK's canonical conversions.
• Add unit tests with real XDR fixtures asserting C.../G... outputs for contract and account
  addresses respectively.
• Add regression tests for getTokenInfoByAddress and getTokenEvents proving a created token's
  events are found by its StrKey address.
• Verify explorer links, AddressDisplay truncation, and CSV output render the canonical encodings.

Acceptance criteria

• All addresses surfaced in events, history, CSV, and explorer links are canonical StrKey strings.
• getTokenInfoByAddress returns real name/symbol/creator data for a token found in events, and the
  per-token history view is populated — both proven by tests.

---

Issue 11 of 20 from the codebase audit tracked in ISSUES.md.

[mayborn005]

Hello @maintainer, I’ve gone through the requirements and I’m confident I can implement a proper solution that matches the acceptance criteria. Kindly assign this issue to me. And I will deliver at the shortest possible time.

[DDefiBoy]

Thanks for opening this issue.

After going through the description, I have a good idea of the work involved and would be interested in taking it on. I've worked on similar problems before, particularly around investigating root causes, implementing maintainable fixes, and validating changes through thorough testing.

My plan would be to first understand the current behavior, identify the source of the issue, and then submit a well-tested PR with any necessary documentation updates.

If no one is currently assigned, I'd be happy to work on this and keep the discussion updated with my progress.

[yahia008]

hi team kindly assign me i can work on this issue i have experience in smart contract development

[grantfox-oss]

🦊 GrantFox — @yahia008 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 #1015)
2. Your PR will be reviewed by the Favourorg maintainers

Good luck! Track your progress on GrantFox.