SparkX

SparkX is a "Global Venmo" supporting BTC and 1:1-backed USD - enabling cheap and instant payments, with a proof‑of‑reserves. To be globally accessible, SparkX is built with a11y-supported UX.

Comment

Inspiration

Moving money across borders is still slow, opaque and expensive; SparkX attacks cost, accessibility and transparency head‑on. The following 3 problems inspired this project:

1. High Cross‑Border Payment Costs

  • Average remittance fee is 6–7 %.
  • Many users have no reliable banking rails to onboard and off-board to platforms.
  • Fintechs hide solvency and FX spreads.
  • Opaque token backing makes users distrust stablecoin options.
  • People with little in savings feel that Bitcoin is too volatile to use.

2. Bitcoin Accessibility

  • No standard UI component library for Bitcoin apps.
  • Inconsistent accessibility & design patterns slow adoption.

3. Spark SDK Validation

  • Spark is still un-proven: can Spark support payments in a scalable, resilient, and private manner?
  • Spark offers inner-platform transfers but not cross-platform transfers
  • Spark's tokens are not provably backed nor discoverable
  • Spark has no privacy - Operators can see all balances and transfers; third parties can spy on wallets

What it does

SparkX offers:

  • Instant, Borderless Payments – BTC or USD in sub‑second transfers (< 1 % fee).
  • Double‑Lock Proof‑of‑Reserves – live Stripe balance + nightly Bitcoin‑anchored Merkle tree.
  • Spark Invoices (New SIP) – Lightning‑style request format for cross‑app UX.
  • Network‑Wide Directories – global User & Issuer registries for trust & discovery.
  • Spark Privacy Improvements – privacy proposals to obscure transfers and enable interoperability
  • Accessibility‑First Bitcoin Design Kit – reusable Bitcoin Design & A11y React components.

How we built it

SparkX is built as a Vercel-hosted NextJS/Typescript web app.

SparkX has a Stripe integration to enable instant bank transfers for payments (similar to Venmo). These Stripe payments auto-mint to Spark USD tokens. We expose Stripe's readonly balance-specific API to enable Proof of Reserves, along with a regularly run Merkle Tree proof to provide Proof of Liabilities.

I worked closely with the Spark team (travelled to SF to work with them in-person) to integrate Spark into the app and help them squash production bugs I identified along the way.

The web app currently uses PSQL for a database for the proof of concept, although we aim to migrate to Nostr in the future.

I used shadcn, Chrome's Lighthouse tool, and jest-axe tests to enforce accessibility throughout the app.

Challenges we ran into

At the start of the hackathon, my goal was to build a "Global Venmo" using Spark's new SDKs. I quickly realized a few challenges:

  • Global discovery – we needed a way to find users and tokens outside our own app; directories + Spark Invoices solved it.
  • Transparency vs. privacy – Proof of Reserves was straightforward, but hiding balances required the Blind Statechain SIP.
  • Design & a11y standards: abiding by Bitcoin Design & Accessibility standards was challenging without a plug-and-play NPM library; built one to solve this.

Accomplishments that we're proud of

This project proves that a Bitcoin-rail peer-to-peer payments app with stablecoins is possible!

The project also solves three critical limitations in Spark's protocol. I ran them by the Spark team and they requested I propose them as protocol improvements in their repository:

  1. Spark Invoices: Lightning-inspired payment request standard to enable users to securely and seamlessly request payments from others cross-platform without risk of man-in-the-middle attacks or miscommunication (Proposal)
  2. Blind Statechain Transfers: Eliminates Spark‑operator visibility into sender, receiver, and transfer linkage while retaining Spark’s core properties: instant finality, near‑zero fees, and self‑custody. (Proposal)
  3. Nostr Integration Layer: Enables decentralized, private discovery and messaging (Proposal)

What we learned

Lessons Learned

  1. Protocol vs. Product Trade-offs
    Building on a bleeding-edge protocol (Spark) means you sometimes hit “missing primitives” before you hit UI hurdles. Drafting Spark Improvement Proposals early turned blockers into features.

  2. Transparency ≠ Privacy
    Proof-of-Reserves was easy; keeping balances private was not. We learned that true user privacy will require blinded statechain ownership baked into Spark core rather than front-end duct tape.

  3. Regulated Rails Still Matter
    Bitcoin rails are great for finality, but fiat on/off-ramps and KYC are table-stakes for mainstream users. Initial integration exploration with Brale showed us how licensing impacts architecture decisions. (Brale is a licensed U.S. Money‑Transmitter (27 state MTLs; NMLS #2376957) that mints Spark-native digital dollars and publishes monthly third‑party attestations.)

  4. Design Kits Accelerate Bitcoin UX
    A reusable bitcoin-ui component library cut front-end time in half and surfaced accessibility issues earlier. We’ll push this to NPM so future Bitcoin devs can start at “step 2.”

  5. Vibe coding makes hackathons ultra-productive
    Using AI-powered development via Cursor, I was able to build an end-to-end product with multiple integrations and protocol design proposals that would've otherwise taken several months.

What's next for SparkX

SparkX won't be a one-off hackathon demo - it started at B25 Hackathon but will be an ongoing initiative aimed at driving long-term impact across the Bitcoin ecosystem.

Launch Roadmap

  • ✅ Start working on Brale onboarding for compliant USD issuance
  • ☐ Release iOS/Android Flutter client when Spark Flutter SDK lands
  • ☐ Production‐grade Proof of Reserve dashboard with on‑chain mainnet anchor

Help improve Spark's protocol

  • ✅ Submit SDK feedback to Spark team for bug fixes (see SPARK.md in repository)
  • ✅ Submit protocol improvement proposals for Invoices, Blind Statechains, and Nost Privacy Layer.
  • ☐ Continue protocol improvement discussions with Spark to improve privacy and inter-operability
  • ☐ Work with Spark to explore global, open-source directory for users and issuers
  • ☐ Prototype Nostr messaging layer for private directory lookups

Help improve Bitcoin Design & Accessibility Standards

  • ☐ Review Bitcoin Design and Accessibility NPM package idea with Bitcoin Design community
  • ☐ Publish open-source NPM package for other Bitcoin devs to adopt & SparkX UI sandbox for reference

Built With

Share this project:

Updates