Splitfare

SplitFare is a crypto-native expense splitting platform that makes it effortless to track shared expenses and settle debts using USDC across multiple blockchains.

THE PROBLEM: Splitting expenses with friends is common for dinners, trips, rent, and utilities, but settling up is painful. Traditional apps like Splitwise track debts but require manual bank transfers. Crypto solves this, but current solutions force users to deal with complex wallet addresses, single-chain limitations, and fragmented liquidity.

THE SOLUTION: SplitFare combines intuitive expense tracking with seamless blockchain-based settlement:

• CREATE GROUPS & TRACK EXPENSES Create groups for any shared expense scenario. Add expenses with automatic equal-split calculation. The app uses a debt simplification algorithm to minimise the number of transactions needed if Alice owes Bob $10 and Bob owes Alice $5; it simplifies to Alice owes Bob $5.

• SETTLE INSTANTLY ACROSS ANY CHAIN Using Avail Nexus, users can settle debts with USDC from any supported chain (Base, Optimism, Arbitrum, Polygon, Ethereum Sepolia, Monad testnet) to any other chain. No manual bridging required—Nexus intelligently aggregates your USDC balance across all chains and routes payments through the optimal path.

• HUMAN-READABLE IDENTITIES Instead of sharing "0x4f3a2b8c..." wallet addresses, every user gets a personalised ENS subdomain (e.g., alice.splitfare.eth) created automatically during onboarding via The Namespace. Send payments to @alice, not to a cryptic string.

• SEAMLESS AUTHENTICATION Privy handles authentication with embedded wallets, supporting email, Google, Twitter, and wallet logins. Users can onboard without existing crypto knowledge—the wallet is created automatically.

• PROGRESSIVE WEB APP SplitFare works as a PWA, installable on mobile devices and functional offline. It brings traditional app UX to Web3.

WHY IT'S INNOVATIVE:

• Multi-chain by default: Most expense apps are single-chain; SplitFare leverages Avail's cross-chain liquidity infrastructure
• Automated ENS identity: Web3 identity creation as a core feature, not an add-on
• Real-world utility: Solves a genuine everyday problem with blockchain technology
• Complete product: Production-ready with frontend, backend, database, and blockchain integration

Built with Next.js 16, Tailwind CSS, Supabase (database), Privy (auth), Avail Nexus (cross-chain USDC), The Namespace (ENS subdomains), and Wagmi/Viem (Ethereum libraries).

SplitFare proves that crypto can be accessible, practical, and fun, making bill splitting as simple as sending a text, but with the power of decentralised finance.

CORE ARCHITECTURE

SplitFare is built on Next.js 16 with React 19, using the App Router for file-based routing and API routes. The frontend uses Tailwind CSS 4 for styling and Radix UI primitives for accessible components. TypeScript provides end-to-end type safety, with Zod schemas for runtime validation.

AUTHENTICATION & WALLET MANAGEMENT - PRIVY

Privy powers the entire authentication layer. We use the @privy-io/react-auth SDK to provide flexible login options including email, Google, Twitter, and direct wallet connections. The key benefit of Privy is its embedded wallet feature, users without crypto wallets get one created automatically during onboarding, making the experience seamless for non-crypto natives.

The integration works through a PrivyProvider wrapping the entire app, exposing hooks like usePrivy() and useWallets(). When users authenticate, Privy returns an Ethereum provider that we pass to Wagmi and the Nexus SDK for blockchain interactions. This abstraction layer means we never have to handle private keys or wallet connection logic directly.

One notable implementation: we store the Privy user ID in Supabase alongside wallet addresses, creating a bridge between Web2 authentication and Web3 identity. The /src/app/api/auth/callback route syncs Privy user data to our database after successful authentication.

CROSS-CHAIN USDC SETTLEMENT - AVAIL NEXUS

Avail Nexus is the core innovation that enables multi-chain settlement. Traditional expense-splitting apps are limited to single payment rails (bank transfers, Venmo, single-chain crypto). Nexus unlocks liquidity across 6+ testnet chains simultaneously.

The implementation has three key parts:

1. BALANCE AGGREGATION: The useNexusBalance hook (209 lines) queries USDC balances across all supported chains (Base Sepolia, Optimism Sepolia, Arbitrum Sepolia, Polygon Amoy, Ethereum Sepolia, Monad Testnet). It uses the Nexus SDK's getUnifiedBalance() method, which returns both per-chain balances and a unified total. This data populates the balance display in the settlement modal.

2. TRANSFER EXECUTION: When a user clicks "Settle Up", the settle-up-modal.tsx component initializes the NexusSDK with the user's Ethereum provider from Privy. The SDK handles the complex multi-step process:

   • Identifies source chains with sufficient USDC
   • Determines optimal destination chain
   • Prompts for chain switching if needed
   • Requests USDC spending approval
   • Executes the transfer transaction
   • Optionally bridges funds if source/destination differ

3. TRANSACTION RECORDING: After a successful transfer, we store the transaction hash, source chain ID, destination chain ID, amount, and timestamp in Supabase. The settlement record links to the specific debt being paid, enabling the debt simplification algorithm to correctly net out completed payments.

The hacky part: Nexus widgets require specific chain configurations and RPC URLs. We maintain a custom chain config in /src/lib/blockchain/chains.ts that maps testnet chain IDs to their RPC endpoints, block explorers, and USDC contract addresses. This config is passed to both Wagmi and NexusSDK to ensure consistency.

ENS SUBDOMAIN CREATION - THE NAMESPACE

The Namespace provides gasless ENS subdomain creation via their offchain-manager SDK. During onboarding, after users enter their desired username, we call /src/app/api/ens/create/route.ts, which:

1. Validates username availability (alphanumeric, 3-20 chars)
2. Initializes OffchainManager with our API key
3. Calls createSubdomain() with the username and user's wallet address
4. Receives the full ENS name (e.g., alice.splitfare.eth)
5. Stores it in the Supabase users table

The benefit: users get on-chain identities without gas fees or blockchain transactions. The offchain registry maps subdomains to addresses, enabling resolution via standard ENS tooling. We display these ENS names throughout the app instead of truncated wallet addresses, making the experience human-friendly.

One challenge: The Namespace API is server-side only (requires API key). We had to implement the creation flow as a Next.js API route rather than client-side, then handle the async response with proper loading states and error handling in the onboarding form.

DATABASE & BACKEND - SUPABASE

Supabase provides PostgreSQL database hosting with real-time subscriptions and Row Level Security (RLS). The schema includes:

• users: Privy ID, wallet address, ENS subdomain, email, name
• groups: Group metadata, created_at
• group_members: Junction table with user_id, group_id, role (admin/member)
• expenses: Amount, description, paid_by user_id, group_id
• expense_splits: Who owes what for each expense (amount per user)
• settlements: Transaction records with tx_hash, chain_id, status

RLS policies ensure data isolation—users can only query groups they're members of. This is critical for security since the API routes use the Supabase client with user credentials, not a service role key.

The hacky part: Settlement creation requires writing to settlements and reading from expenses/expense_splits to calculate debts. RLS policies must allow reads across group_members to verify the payer and payee are both in the group. The /supabase/migrations/002_rls_policies.sql file contains complex policy logic using EXISTS clauses to check membership.

DEBT SIMPLIFICATION ALGORITHM

The most algorithmically interesting piece is the debt simplification logic in /src/app/groups/[id]/page.tsx (lines 241-335). When displaying "Who Owes What", we:

1. Create a debt matrix: debt[userA][userB] = amount A owes B
2. Iterate through all expenses in the group:
   • If Alice paid $60 for a group of 3, everyone except Alice owes $20
   • Add $20 to debt[Bob][Alice] and debt[Charlie][Alice]
3. Subtract completed settlements:
   • If Bob already paid Alice $15, reduce debt[Bob][Alice] by $15
4. Net mutual debts:
   • For each pair of users, if A owes B and B owes A, offset them
   • debt[A][B] -= debt[B][A], set debt[B][A] = 0
5. Output only non-zero debts

This minimizes the number of settlement transactions needed. For N users with M expenses, naive settlement would require up to N×M transactions. The algorithm reduces this to at most N-1 transactions (proven optimal for debt simplification).

The only tricky part: ensuring we only subtract "completed" settlements from the debt matrix, not "pending" ones. The query filters by settlement.status = 'completed' and joins on transaction hash existence.

PROGRESSIVE WEB APP

We use @ducanh2912/next-pwa to configure service worker generation. The next.config.ts file includes PWA config with:

• Offline fallback pages
• Icon manifests (72x72 through 512x512)
• Caching strategies for static assets
• Background sync for pending settlements (if offline when settling)

The hacky part: Next.js webpack configuration needed polyfills for Node.js crypto modules (crypto-browserify, stream-browserify, buffer) because the Namespace SDK and Wagmi use cryptographic functions. The webpack config in next.config.ts explicitly provides these polyfills for client-side bundles.

BLOCKCHAIN INTEGRATION - WAGMI & VIEM

Wagmi provides React hooks for Ethereum operations (useAccount, useBalance, useSendTransaction). We configure it in /src/lib/blockchain/wagmi-config.ts with:

• Custom testnet chains (Base Sepolia, Optimism Sepolia, etc.)
• Alchemy RPC transports for reliability
• Privy connector via @privy-io/wagmi

Viem powers the low-level Ethereum interactions. We use it for:

• Formatting addresses and transaction hashes
• Parsing contract events (future feature: listening for USDC transfer confirmations)
• Chain-specific utilities (block explorer URLs)

The integration works through a WagmiProvider wrapping the app, which receives the Ethereum client from Privy. This ensures the same wallet instance is used across Privy, Wagmi, and Nexus SDK.

NOTABLE HACKS & CHALLENGES

1. WEBPACK POLYFILLS: Browser-based Web3 apps need polyfills for Node.js modules. We had to explicitly configure webpack to provide crypto, buffer, stream, process, and util polyfills. Without this, the app crashes on client-side hydration.

2. CHAIN ID MAPPING: Different libraries use different chain ID formats (hex vs decimal). We maintain a single source of truth in /src/lib/blockchain/chains.ts and convert as needed.

3. SETTLEMENT STATUS TRACKING: Nexus SDK transfers are async and can fail silently. We implemented a polling mechanism that checks transaction status on the block explorer API every 2 seconds, updating the UI from "pending" to "completed" or "failed" based on confirmations.

4. INVITE LINK GENERATION: Group invite links use the group ID as the slug (/invite/[groupId]). We initially used UUIDs, but switched to a shorter base62-encoded ID for shareable links. The /src/lib/utils/generate-invite-code.ts function creates collision-resistant 8-character codes.

5. REAL-TIME UPDATES: Supabase real-time subscriptions enable live updates when group members add expenses. The useGroups hook subscribes to the groups table and refetches when it detects INSERT or UPDATE events, keeping the UI in sync across devices.

DEVELOPMENT WORKFLOW

We used pnpm for package management, ESLint for linting, and TypeScript strict mode for type checking. The project structure follows Next.js App Router conventions with route groups for organization (auth, marketing, app).

Supabase local development with Docker enabled rapid iteration on database schema without touching production. The supabase/migrations folder contains version-controlled SQL files for schema changes.

WHAT MADE THIS POSSIBLE

The combination of Privy, Avail Nexus, and The Namespace made this project feasible in a hackathon timeframe:

• Privy eliminated weeks of wallet connection logic
• Nexus provided cross-chain USDC without building bridge infrastructure
• The Namespace gave ENS identities without deploying smart contracts
• Supabase handled backend without writing a REST API from scratch

Without these partner technologies, this project would require 10x the development time and deep blockchain expertise. The integrations enabled focusing on product features rather than infrastructure.