Implement privacy-preserving transaction pooling and mixing

[Just-Bamford]

Description

Problem

Sorokit transactions are fully linkable through their on-chain inputs, outputs, and timing. There is no abstraction for coordinating privacy-preserving transaction batches or separating individual transfers from a shared submission flow.

Solution

Introduce an optional transaction mixing layer that groups compatible transfers into coordinated batches before submission. The system should maintain participant state, shuffle eligible transactions, calculate the resulting execution cost, and expose the privacy trade-offs of joining a pool without changing the default transaction flow.

Acceptance Criteria

• Mixing pools support multiple participants and pending transactions
• Eligible transactions are shuffled before batch construction
• Pool state prevents duplicate or already-submitted transactions
• Privacy and execution costs are calculated before participation
• Failed or expired participants can be removed without corrupting the pool
• Participation remains explicitly opt-in
• Tests cover pooling, shuffling, cancellation, failure, and empty-pool scenarios
• Existing non-mixed transaction flows remain unchanged
• Public APIs are exported through src/transaction/index.ts and src/index.ts

Note for Contributors

Keep the mixing layer isolated from normal transaction builders. Define clear lifecycle states for pooled transactions and avoid exposing participant relationships through public results. Include tests for partial failures and pool cleanup.

[GoabDev]

@GoabDev has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi Maintainer, I’d love to work on this issue. I’m a full-stack developer with several years of experience, and I’m comfortable working with backend/SDK architecture, transaction lifecycle management, and automated testing.

I’ll implement the opt-in transaction pooling and mixing layer with safe participant state management, transaction shuffling, duplicate protection, cost calculation, and proper cleanup for failed or expired participants, along with comprehensive test coverage.

ETA: 10–12 hours.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @GoabDev to this issue.

[Machundii]

@Machundii has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi. I would like to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Machundii to this issue.

[drips-wave]

Congratulations, @Machundii! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @Machundii: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊