Atomic multi-operation batching with single passkey approval

[Just-Bamford]

Description

Problem

Each action is a separate tx + passkey prompt. Composing several operations (approve + swap, or multi-send) into one signed transaction improves UX and atomicity.

this pr Closes #277

Solution

Implemented batch() API that collects multiple Soroban invocations into a single transaction, builds one auth payload, and gathers a single passkey assertion covering all auth contexts.

Changes

• SDK: Added batch() method and BatchOperation/BatchResult types to useInvisibleWallet.ts
• Contract: Updated __check_auth in lib.rs to validate all auth contexts in batch
• Tests:
  • 4 contract tests in batch_tests.rs (atomicity, nonce consumption, context validation, replay protection)
  • 5 SDK integration tests in batch.test.ts

Acceptance Criteria Met

✅ Multiple operations succeed/fail atomically (all-or-nothing)
✅ One passkey assertion authorizes all contexts
✅ Partial failure rolls back the entire batch
✅ Nonce advanced only once per batch
✅ Full test coverage

Files Modified

• sdk/src/useInvisibleWallet.ts
• sdk/src/__tests__/batch.test.ts (new)
• contracts/invisible_wallet/src/lib.rs
• contracts/invisible_wallet/src/batch_tests.rs (new)

Usage

const result = await wallet.batch(signerKeypair, [
  { target: tokenAddress, function: 'approve', args: [...] },
  { target: swapAddress, function: 'swap', args: [...] }
]);
// Single passkey prompt authorizes both operations atomically

[vercel]

@Just-Bamford is attempting to deploy a commit to the miracle656's projects Team on Vercel.

A member of the Team first needs to authorize it.

[drips-wave]

@Just-Bamford Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[Miracle656]

This is really good work — the design is correct and the test coverage is excellent. The __check_auth change is the right approach: iterating _auth_contexts and relying on the fact that Soroban's single signature_payload commits to every context, so one WebAuthn assertion atomically authorizes the whole batch with the nonce consumed once. And batch_tests.rs covers exactly the cases I'd want — multi-context single signature, nonce-consumed-once atomicity, rejection of invalid context types, and replay protection. The BatchOperation/BatchResult SDK API is clean too.

One blocking issue before I can merge: sdk/src/useInvisibleWallet.ts has been fully reformatted (Prettier), so the diff is +1763/−1282 — but only ~1000 of those lines are real; the rest is whitespace/line-wrapping churn. Because this file contains the security-critical client signing path (signAuthEntry, low-S handling, auth-entry assembly), I can't safely confirm that nothing in the signing logic changed underneath a reformat that large. The repo also has no Prettier config, so this is your editor's default style rather than the project's.

Please revert the formatting-only hunks and keep just the batch additions (the new types + the batch() method), so the diff shows only the functional change. Once useInvisibleWallet.ts is a clean, minimal diff I'll re-review and merge — the feature itself is basically there. Thanks! 🎯

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

Since your pull request originates from a forked repository, GitGuardian is not able to associate the secrets uncovered with secret incidents on your GitGuardian dashboard.
Skipping this check run and merging your pull request will create secret incidents on your GitGuardian dashboard.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
34267434	Triggered	Generic High Entropy Secret	544dec5	frontend/wallet/lib/tests/backup.test.ts	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}