feat: Display Token::Transfer, Token::TransferChecked and Token::SyncNative at Inspector

[rogaldh]

Description

PR fix parsing for TokenProgram's Instruction at Inspector:

• Transfer
• TransferChecked
• SyncNative

Several improvements also been made:

• Display "Program" field for several cards in all modes
• • Extended information about the owner program
• Mock ALTs to not fetch them
• Improve tests for Instruction Cards

Type of change

• Bug fix
• New feature

Screenshots

BEFORE	AFTER	Link
		Link
		Link
		Link

Testing

pnpm t

Related Issues

HOO-237

Checklist

• My code follows the project's style guidelines
• I have added tests that prove my fix/feature works
• All tests pass locally and in CI
• CI/CD checks pass
• I have included screenshots for protocol screens (if applicable)

---

Important

Add support for parsing and displaying Token::Transfer, Token::TransferChecked, and Token::SyncNative instructions in the Inspector, with additional improvements and tests.

• Behavior:
  • Add parsing for Token::Transfer, Token::TransferChecked, and Token::SyncNative in spl-token.parser.ts.
  • Display "Program" field in InspectorInstructionCard and UnknownDetailsCard.
• Components:
  • Add ProgramField component in ProgramField.tsx for displaying program information.
  • Update BaseRawDetails to handle loading state when ix is undefined or has no keys.
• Tests:
  • Add tests for BaseInstructionCard, AccountsCard, AssociatedTokenDetailsCard, ComputeBudgetDetailsCard, SystemDetailsCard, and TokenDetailsCard.
  • Add Storybook stories for BaseRawDetails and ProgramField.
• Misc:
  • Mock accounts in MockAccountsProvider.tsx to avoid network requests in tests.
  • Update BUILD.md with new route sizes and first load JS metrics.

^{This description was created by for 1a80ba9. You can customize this summary. It will automatically update as commits are pushed.}

[vercel]

@rogaldh is attempting to deploy a commit to the Solana Foundation Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
explorer	Ready	Preview, Comment	Dec 25, 2025 8:19pm

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 1a80ba9 in 5 minutes and 30 seconds. Click for details.

• Reviewed 2045 lines of code in 37 files
• Skipped 0 files when reviewing.
• Skipped posting 11 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. app/components/common/BaseRawDetails.tsx:23

• Draft comment:
  The BaseRawDetails component returns a loading spinner if the instruction (ix) is undefined or has no keys. Ensure that instructions with legitimately empty keys (if any exist) are not mistakenly treated as loading state.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment starts with "Ensure that..." which is a red flag according to the rules - we should not ask the PR author to confirm, verify, or ensure things. The comment is also speculative - it says "if any exist" which indicates uncertainty about whether this is actually a problem. The author changed the logic to show a loading state when ix.keys.length === 0, and the comment is questioning whether this is correct behavior. However, without seeing the broader context of how this component is used, we can't definitively say this is wrong. The comment doesn't provide strong evidence that this is definitely a bug - it's asking the author to double-check their logic. Perhaps there's legitimate context where instructions with zero keys exist and should be displayed differently than a loading state. The comment might be catching a real edge case that the author didn't consider. Even if this is a potential edge case, the comment violates the rule about not asking the author to verify or ensure things. The comment is speculative ("if any exist") and doesn't provide strong evidence that this is definitely wrong. If the author intended to show loading for empty keys, they likely had a reason. This comment should be deleted because it starts with "Ensure that..." which is explicitly called out as not useful in the rules. It's asking the author to verify/confirm their intention rather than pointing out a definite issue. The comment is also speculative about whether instructions with empty keys legitimately exist.

2. app/components/common/InspectorInstructionCard.tsx:77

• Draft comment:
  The component now renders a ProgramField with extended info when the raw view is toggled. Verify that the 'showExtendedInfo' prop correctly controls the display.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is asking the PR author to verify the behavior of a prop, which is against the rules. It doesn't provide a specific suggestion or point out a specific issue with the code.

3. app/components/inspector/into-parsed-data.ts:209

• Draft comment:
  The workaround for associated token 'create' instructions uses a buffer equality check. Ensure that the constant CREATE_ASSOCIATED_TOKEN_DISCRIMINATOR is defined consistently and that this edge case is well-tested.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

4. app/components/inspector/instruction-parsers/spl-token.parser.ts:17

• Draft comment:
  Consider adding inline comments in each 'case' block to clarify the mapping between the parsed instruction and the returned info.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

5. app/providers/accounts/index.tsx:154

• Draft comment:
  The check 'if (this.pubkeys !== undefined)' is redundant since 'pubkeys' is always defined. Consider removing this check to simplify the code.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

6. app/components/instruction/associated-token/CreateDetailsCard.tsx:37

• Draft comment:
  Ensure that the ordering of keys in 'raw.keys' for different roles (Source, Account, Mint, Wallet, etc.) is consistent with the expected layout.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

7. app/components/instruction/associated-token/CreateIdempotentDetailsCard.tsx:29

• Draft comment:
  Confirm that the 'info' prop contains valid PublicKey values for rendering addresses. The parsing logic should guarantee these fields are well-formed.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

8. app/entities/instruction-card/ui/stories/ProgramField.stories.tsx:27

• Draft comment:
  Ensure that the mocked extended info data for ProgramField matches expected values in AddressWithContext, including owner, balance, and size.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is asking the author to ensure that the mocked data matches expected values. It is not making a specific suggestion or pointing out a specific issue with the code. It falls under the rule of not asking the author to ensure behavior is intended or tested.

9. app/components/instruction/token/TokenDetailsCard.tsx:91

• Draft comment:
  The useEffect hooks for fetching token and mint info have empty dependency arrays disabled by eslint. Verify that these effects update correctly when tokenAddress or mintAddress changes.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

10. app/entities/instruction-card/ui/ProgramField.tsx:10

• Draft comment:
  The ProgramField component correctly differentiates between basic and extended info. Good use of AddressWithContext for extended info.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative and does not provide any actionable feedback or suggestions for improvement. It simply praises the current implementation without offering any constructive criticism or questions.

11. app/__tests__/stubs/EDDSpjZHrsFKYTMJDcBqXAjkLcu9EKdvrQR4XnqsXErH.json:1

• Draft comment:
  I noticed a potential typographical error in one of the addresses: "Sysvar1nstructions1111111111111111111111111". Did you intend to use "SysvarInstructions1111111111111111111111111" (with an 'I' instead of the digit '1')?
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 15% vs. threshold = 50% The comment is asking if there's a typo, using phrases like "Did you intend to use..." which is asking the PR author to confirm their intention. This violates the rule that says "Do NOT ask the PR author to confirm their intention, to explain, to double-check things, to ensure the behavior is intended, to make sure their change is tested, or similar." The comment is also speculative - it assumes there's an error without strong evidence. In Solana, "Sysvar1nstructions" could be an intentional address format. Without seeing how this data is used or having documentation about what the correct address should be, I cannot be certain this is actually wrong. The file is a test stub, so it could be intentionally using a specific address format for testing purposes. However, if "Sysvar1nstructions" is genuinely a typo and the correct Solana sysvar address is well-known to be "SysvarInstructions", this could be catching a real bug. Solana sysvar addresses are standardized, and using the wrong one could cause test failures or incorrect behavior. While it's possible this is a real issue, the comment is phrased as a question asking for confirmation rather than stating a definite problem. Without strong evidence that this is definitely wrong (like documentation or knowledge of the exact correct address), and given that this violates the "don't ask the author to confirm" rule, the comment should be deleted. If the tool was certain this was wrong, it should have stated it definitively rather than asking. Delete this comment. It asks the PR author to confirm their intention ("Did you intend to use..."), which violates the review rules. The comment is speculative without strong evidence that this is definitely incorrect.

Workflow ID: wflow_c8QkpHR1Xc62qMHd

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}