Add Transaction Inspector Support for Squads Vault Transactions (#2)

[ngundotra]

Description

Adds support for viewing Squads VaultTransactions in the transaction inspector. This is an additional layer of safety when using Squads, since users will be able to use the Explorer to verify a proposed transaction's contents on an independent platform.

Type of change

• New feature

Screenshots

• Modified the card title to Inspector Input
• Appended Squads support to placeholder text
• Added a bullet point to Instructions section describing how to get the squads transaction id

Testing

• in progress

Related Issues

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
• have updated documentation as needed
• CI/CD checks pass
• I have included screenshots for protocol screens (if applicable)
• For security-related features, I have included links to related information

Additional Notes

---

Important

Adds support for Squads Vault Transactions in the transaction inspector, including UI updates and tests.

• Behavior:
  • Adds support for Squads VaultTransaction in InspectorPage.tsx.
  • Introduces SquadsProposalAccountData type and isSquadsProposalAccountData() function.
  • Updates decodeUrlParams() to handle squadsTx parameter.
  • Implements SquadsProposalInspectorCard to fetch and display Squads transaction data.
• UI Changes:
  • Modifies RawInputCard.tsx to accept Squads vault transaction accounts.
  • Updates placeholder text and instructions in RawInputCard.tsx.
• Testing:
  • Adds tests in InspectorPage.spec.tsx for Squads transaction handling.
• Dependencies:
  • Adds @sqds/multisig to package.json.

^{This description was created by for 4220460. It will automatically update as commits are pushed.}

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
explorer	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 18, 2025 8:17pm

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to 2fdb91b in 2 minutes and 54 seconds

More details

• Looked at 623 lines of code in 4 files
• Skipped 1 files when reviewing.
• Skipped posting 9 drafted comments based on config settings.

1. app/components/inspector/InspectorPage.tsx:110

• Draft comment:
  Consider adding a brief inline comment here to explain the purpose of validating the 'squadsTx' URL parameter (and returning a SquadsProposalAccountData) using PublicKey. This will help future maintainers understand the added safety layer.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

2. app/components/inspector/RawInputCard.tsx:163

• Draft comment:
  The clearInput callback clears URL params for 'message' and 'transaction', but not for 'squadsTx'. To maintain consistency with the reset logic in TransactionInspectorPage (which clears 'squadsTx'), consider also deleting 'squadsTx' from the URL here.
• 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%

1. The comment references behavior in another file that I can't verify. 2. There's no evidence in this file that 'squadsTx' is a valid parameter that needs clearing. 3. The new code adds Squads vault transaction support, but handles it through the 'account' field in InspectorData, not through URL parameters. 4. Without seeing TransactionInspectorPage, I can't verify if this consistency is actually needed.
   I might be missing important context from TransactionInspectorPage that would make this comment valid. The addition of Squads-related functionality in this PR could mean the comment is relevant.
   Even with the Squads additions, there's no clear evidence that 'squadsTx' is a URL parameter that needs handling here. We should not make assumptions about cross-file consistency without seeing the other file.
   Delete the comment as it makes assumptions about cross-file consistency that cannot be verified from the available context.

3. app/components/inspector/__tests__/InspectorPage.spec.tsx:75

• Draft comment:
  The test mocks 'VaultTransaction.fromAccountInfo' and accesses the first element of the returned array. Ensure that this mocking accurately represents production behavior, and consider adding a check in the test to handle cases where the returned array might be empty.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 50% <= threshold 50%
  The comment suggests ensuring that the mocking accurately represents production behavior, which is against the rules as it asks the author to ensure something. However, it also suggests adding a check in the test for an empty array, which is a specific code suggestion and is allowed.

4. app/components/inspector/InspectorPage.tsx:209

• Draft comment:
  Consider verifying that the conversion logic in convertVaultTransactionToMessage (lines 210–229) correctly preserves the original message data. In particular, using a static zero-filled recentBlockhash may not reflect the actual vault transaction; if the original message contains a valid blockhash, reusing it might be preferable.
• 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 is speculative - it suggests there "may" be an issue and asks for verification rather than pointing out a definite problem. The zero-filled blockhash appears to be intentional as this is just for display/inspection purposes, not for actual transaction execution. The conversion logic seems appropriate for its purpose of displaying transaction details in the UI.
  I could be wrong about the purpose of the blockhash - perhaps it is important to preserve the original for some functionality I'm not aware of.
  Even if preserving the original blockhash might be useful, the comment is still speculative and asks for verification rather than pointing out a clear issue. The code works as intended for its display purpose.
  Delete the comment as it is speculative and asks for verification rather than pointing out a clear issue requiring changes.

5. app/components/inspector/InspectorPage.tsx:110

• Draft comment:
  In decodeUrlParams, the squadsTxParam is processed without checking for empty strings. Consider validating that the parameter is non-empty before treating it as a public key.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

6. app/components/inspector/RawInputCard.tsx:120

• Draft comment:
  The onInput logic first attempts to parse the input as an account address. This might mistakenly interpret a valid base64 transaction message (if it contains no whitespace) as an account address. Consider adding further validation to distinguish between a vault transaction account and base64-encoded data.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

7. app/components/inspector/RawInputCard.tsx:163

• Draft comment:
  In clearInput, URL parameters for 'message' and 'transaction' are cleared, but the 'squadsTx' parameter is not removed. For complete cleanup of transaction-related params, consider deleting 'squadsTx' as well.
• 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 makes an assumption about a 'squadsTx' parameter without any evidence of its existence or use in the codebase. While there is a mention of Squads in the placeholder text and instructions, there's no indication that it uses a 'squadsTx' URL parameter. We should be conservative and not add parameter handling without clear evidence it's needed.
  The comment could be correct if there's code in other files that uses the 'squadsTx' parameter. The presence of Squads-related UI text suggests this might be a real parameter.
  Even if the parameter exists elsewhere, we should follow the rule to ignore cross-file issues. We can only make decisions based on what we see in this file.
  Delete the comment because it makes assumptions about URL parameters that aren't evidenced in this file, and we should ignore cross-file issues.

8. app/components/inspector/__tests__/InspectorPage.spec.tsx:102

• Draft comment:
  The test hardcodes the expected fee payer address. For better maintainability, consider deriving the expected value from MOCK_SQUADS_ACCOUNT_INFO or a similar source, so the test remains accurate if the underlying data changes.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

9. app/components/inspector/InspectorPage.tsx:84

• Draft comment:
  Typographical error: The module is imported as 'bs58' but 'base58.decode' is used within decodeSignatures. Please update it to 'bs58.decode'.
• 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.

Workflow ID: wflow_pADPvmWwd6JEEwmR

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on 6302665 in 1 minute and 12 seconds

More details

• Looked at 30 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 5 drafted comments based on config settings.

1. app/components/inspector/InspectorPage.tsx:15

• Draft comment:
  Good job removing the unused Suspense import.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

2. app/components/inspector/__tests__/InspectorPage.spec.tsx:102

• Draft comment:
  Using getByRole to select the Fee Payer row depends on proper ARIA roles. Ensure that the rendered table row has the role and accessible name set, otherwise this test might be brittle.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50%
  None

3. app/components/inspector/InspectorPage.tsx:17

• Draft comment:
  Good cleanup: the unused Suspense import was removed. If Suspense is not needed, this keeps the bundle lean.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  This comment is purely informative, as it simply states the benefit of removing an unused import. It doesn't provide a suggestion or ask for confirmation about the code change.

4. app/components/inspector/__tests__/InspectorPage.spec.tsx:103

• Draft comment:
  Nice improvement: using getByRole with a name query for the fee payer row increases test reliability and accessibility compared to using getByText + closest('tr').
• Reason this comment was not posted:
  Comment looked like it was already resolved.

5. app/components/inspector/InspectorPage.tsx:84

• Draft comment:
  Typographical error: 'base58.decode' is used here, but the module is imported as 'bs58' on line 16. Please update this to 'bs58.decode' to match the import.
• 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.

Workflow ID: wflow_CPaUJQ3HyXbnqJMe

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on 4220460 in 1 minute and 31 seconds

More details

• Looked at 13 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 2 drafted comments based on config settings.

1. app/components/inspector/InspectorPage.tsx:83

• Draft comment:
  Good change switching from base58 to bs58 for decoding signatures. Ensure that your error message and test coverage fully capture invalid base58 inputs.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

2. app/components/inspector/InspectorPage.tsx:84

• Draft comment:
  Good fix: Using bs58.decode (which is properly imported) instead of base58.decode prevents undefined errors. Ensure that the error handling works correctly for invalid signatures.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 50% <= threshold 50%
  The comment suggests using bs58.decode instead of base58.decode to prevent undefined errors, which is a specific code suggestion. However, the latter part of the comment asks to ensure that error handling works correctly, which violates the rule against asking the author to ensure behavior is intended or tested. The first part is useful, but the second part is not allowed.

Workflow ID: wflow_hBpO08RO5tRdPZ74

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.