Transaction signing safety — validate simulation auth entries before presenting to user

[prodbycorne]

Problem

The current (stub) unlockAssets and the planned lockAssets / configureBoost flows build a Soroban transaction and immediately pass it to walletApi.signTransaction. They do not inspect the simulateTransaction response's auth array before signing.

A compromised RPC node or a man-in-the-middle could return a simulation response with injected auth entries that authorise additional contract calls beyond what the user intended. The user would see the Freighter dialog and sign without knowing.

Expected Behaviour

Before presenting any transaction to Freighter for signing, the app verifies that the simulation response contains exactly the expected number and type of auth entries. Any unexpected auth entry causes the transaction to be aborted and a clear warning is shown.

Acceptance Criteria

• A validateSimulationAuth(simResult, expected: { contractId: string; functionName: string }[]) utility is added to src/lib/soroban.ts
• The utility inspects simResult.result?.auth (a SorobanAuthorizationEntry[]), decodes each credentials field, and asserts the contractFn.contractAddress and contractFn.functionName match the expected list
• If the auth array is longer than expected, or any entry targets an unexpected contract/function, the utility throws a SecurityError with a user-facing message
• lockAssets, unlockAssets, and configureBoost all call validateSimulationAuth before assembling the final transaction
• The error is surfaced to the user via the useErrorHandler toast (not swallowed silently)
• A unit test provides a mock simResult with an extra unexpected auth entry and asserts the function throws

Relevant Files

• src/lib/soroban.ts — add validateSimulationAuth; call it inside unlockAssets, lockAssets, configureBoost
• src/context/ErrorContext.tsx — useErrorHandler for user-facing error display
• src/lib/error-handler.ts — may need a new SecurityError class

[clintjeff2]

Hello, I have 6 years of experience working on tasks like this and handling similar challenges across backend, frontend, and smart-contract development. I have carefully read and fully understood the task requirements, and I am confident I can deliver a clean, efficient, and well-tested solution promptly. I always ensure high-quality implementation, maintainability, and adherence to best practices.

Pull request in 5 hours.

[Sparexonzy95]

Hi team, I’d like to work on this issue.

I understand this as a transaction-signing security problem. The current unlockAssets flow, along with the planned lockAssets and configureBoost flows, builds a Soroban transaction and sends it to Freighter for signing without first validating the authorization entries returned from simulateTransaction.

The risk is that a compromised RPC node or man-in-the-middle could inject additional or unexpected auth entries into the simulation response. If the frontend does not inspect those entries before signing, the user may approve a Freighter signing request that authorizes contract calls beyond the action they intended.

My approach will be to add a dedicated validation layer before any simulated transaction is assembled and presented to Freighter.

I plan to:

1. Add a validateSimulationAuth(simResult, expected) utility inside src/lib/soroban.ts.
2. Inspect simResult.result?.auth and verify that the number of SorobanAuthorizationEntry items matches the expected contract/function list.
3. Decode each auth entry enough to confirm that contractFn.contractAddress and contractFn.functionName match the intended SmartDrop action.
4. Reject any unexpected, missing, or extra authorization entry before the transaction reaches walletApi.signTransaction.
5. Add or extend a SecurityError class in src/lib/error-handler.ts with a clear user-facing warning message.
6. Call validateSimulationAuth inside unlockAssets, lockAssets, and configureBoost before final transaction assembly/signing.
7. Ensure the error is surfaced through the existing useErrorHandler toast flow so the user gets a clear warning instead of a silent failure.
8. Add unit coverage with a mocked simulation result containing an extra unexpected auth entry and assert that validation throws correctly.

This should make the signing flow safer by ensuring the user only signs authorization scopes that match the intended contract action.

I’ll keep the PR focused on the stated acceptance criteria, include test results, and document the validation assumptions clearly in the PR description.

[grantfox-oss]

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

Next steps:

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

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign campaign!

@Sparexonzy95's PR #56 was approved and merged by @prodbycorne.

🏆 @Sparexonzy95: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (48 total points). Track your full progress on GrantFox.

👏 Great work, @Sparexonzy95! Keep contributing to SmartDropLabs.