Split

I built Split from scratch, owning the product design, frontend, smart contracts, event indexing, and wallet integration. Wallet providers supply account access and signing; Stellar provides the transaction network.

Split starts with a familiar problem: a group organizes rent, dinner, dues, or an event in a chat, then the creator chases payment screenshots and maintains a manual checklist. I wanted one shared record that makes the amount, participants, and payment status understandable.

The product stays focused on collecting equal contributions. Payments move directly from participants to the creator, while Stellar contract state records who has paid. V2 builds on that foundation with a more approachable interface and embedded onboarding.

V1 connected collection creation, sharing, wallet-signed payments, paid and pending status, and indexed transaction receipts. It proved the core product workflow on Stellar Testnet and provided a stable baseline for the redesign.

The interface still asked users to handle wallet setup and technical concepts early. A long creation form and competing payment panels made a working system harder to understand. The archived screens below show the starting point, rather than the current V2 interface.

In a live review with UX professional PV, the central recommendation was to remove distractions: explain the outcome plainly, let a disconnected visitor start creating a Split, and introduce wallet connection when identity is needed. We discussed familiar payment-product patterns and a receipt-like view of purpose, amount, people, and payment status. These recommendations informed V2’s action-first entry, staged creation, and receipt hierarchy.

Tester feedback exposed a separate trust problem: one respondent saw a successful transaction on the explorer while Split still showed the payment as pending. Others reported confusing wallet setup, unclear participant-address entry, missing balance information, and errors far from the action that caused them. Reports also covered wallet disconnection, activity-history loading, and a crash when reopening a collection route.

This made V2 more than a visual redesign. The work needed to address task clarity, wallet control, and trustworthy payment feedback. The captures below show changes to creation and payment presentation; confirming that the reported reliability and recovery issues are resolved requires separate regression evidence.

V2 puts the payment task first: begin creating a Split, authenticate when the action needs an identity, review the details, then approve the transaction. Addresses remain authoritative for assignment, while readable names help people scan payment status.

The captured creation flow separates purpose and amount, participant entry, final review, and transaction approval. The participant screen brings the amount owed and Pay your share into one view. These screens demonstrate the implemented hierarchy; whether people complete the task more easily still needs follow-up testing.

The access model distinguishes a disconnected wallet, a connected but unassigned wallet, and an assigned participant or creator. Gating the interface helps avoid exposing unrelated payment details in the app; it does not make the blockchain private. Titles, names, and payment records remain queryable through the current contract. Actual data privacy would require a separate storage or contract redesign.

Removing the extension requirement also required an architectural change. Instead of importing one wallet provider throughout the product, V2 introduces a Split-owned adapter for session and signing behavior. Blux is the embedded Testnet path; Freighter remains available for existing-wallet users.

Split validates, constructs, and simulates the transaction; the wallet provider supplies the signature. Split then submits the signed transaction and waits for confirmation before presenting the result. Keeping this lifecycle in the application preserves a shared transaction path across wallet providers.

The Soroban contract continues to validate participants, shares, payment state, and creator-only closure. Supabase indexes events and transaction hashes for durable receipts; the contract remains the source of payment state.

The report of explorer success alongside a pending app status makes consistency a user-facing requirement: submission, confirmation, contract reads, and indexed activity must remain distinguishable. A successful payment capture demonstrates that example’s result; it does not establish that delayed indexing, refresh, and interrupted sessions always recover correctly.

Early October testing encountered a Blux HTTP 400 signing failure when decoding Soroban transaction data with extension version 1, plus a separate passkey sign-in failure. An outdated backend XDR schema was the compatibility hypothesis. Later captures show creation confirmation for Split #21 and a successful payment state for Split #22. These are separate Testnet examples. The exact fix remains undocumented; recovery and full wallet regression still need validation.

V2 brings the same focused payment workflow into a clearer experience, with embedded onboarding, wallet choice, transaction review, and session restoration. It remains pre-launch on Stellar Testnet; follow-up task testing will establish whether the redesign makes creation and payment easier to complete.

The roadmap calls for comparing V1 and V2 on the same tasks: create a Split, add participants, identify the amount owed, pay, and locate the receipt. Completion, onboarding abandonment, address errors, time to understand status, and requests for assistance are proposed measurements, not reported results.

Before moving beyond Testnet, wallet recovery, same-wallet re-login, cross-wallet payments, and interrupted signing need deliberate validation against the current integration. Earlier roadmap notes describe recovery limitations in a previous SDK version; those notes are historical evidence, rather than verified behavior of the current build.