Inspiration
Shared expenses are usually coordinated through chats, rough calculations, screenshots, and incomplete context. Even a simple dinner, trip, gift, or group purchase can become confusing when participants are unsure who paid, how much each person owes, or whether the proposed split is correct.
Split_it was inspired by the need for a clearer, review-first workflow: turn an informal shared-expense description into a structured request that people can inspect before anything happens.
What it does
Split_it is a GPT-5.6-assisted Web3 application for creating clear, reviewable shared-expense requests with wallet authentication on Base.
A user can:
- connect a supported Web3 wallet;
- authenticate using Sign-In with Ethereum;
- describe a shared expense in natural language or enter it manually;
- receive a structured split proposal;
- review names, amounts, payer context, and ambiguity flags;
- edit the proposal before confirmation;
- create and inspect the authenticated split request.
Split_it creates reviewable requests only. No funds are moved. It does not execute payments, transfers, settlement, escrow, swaps, investments, or contract approvals.
How we built it
The application uses Next.js, React, and TypeScript for the product experience.
Wallet connectivity is implemented with Wagmi and viem. Supported desktop wallet paths use MetaMask or the Coinbase Wallet browser extension on Base chain ID 8453. Authentication is completed through a SIWE message and Supabase Web3 Auth.
Supabase provides authenticated sessions, profile resolution, PostgreSQL-backed application data, protected operations, and Row Level Security.
GPT-5.6 powers the optional server-side split composer. It converts a natural-language expense description into a structured proposal. The model output is validated by the server and remains a draft until the user reviews and explicitly confirms it.
The application is deployed on Vercel.
How Codex and GPT-5.6 were used
Codex supported implementation, repository analysis, debugging, test execution, browser and runtime verification, release checklists, documentation, and submission preparation.
It accelerated the engineering workflow, while product direction and final decisions remained human-controlled. These decisions included the review-first product model, Base-focused wallet strategy, authentication boundaries, security requirements, UX priorities, and approval of commits and releases.
Codex and GPT-5.6 had separate roles:
- Codex supported the engineering and release workflow.
- GPT-5.6 is part of the user-facing application and produces structured split proposals for human review.
GPT-5.6 does not authenticate wallets, authorize database access, create records without confirmation, or move funds.
Challenges we faced
Making wallet connection and authentication feel like one experience
Connecting a wallet and establishing an authenticated application session are technically separate steps. A major UX challenge was preventing this from feeling like a confusing double login.
Split_it now presents one wallet-first account state while preserving the underlying SIWE and Supabase security boundaries.
Supporting different wallet environments
Injected desktop wallets, mobile wallet browsers, Safari without an extension, Coinbase Wallet, MetaMask, and Base Account do not all expose identical capabilities.
The verified judging path is Chrome desktop with MetaMask or the Coinbase Wallet extension. Mobile Safari and Chrome provide a wallet-handoff experience, with MetaMask’s in-app browser as the supported mobile authentication path.
Base Account signature compatibility
Coinbase Wallet’s injected EOA authentication path is different from Base Account smart-wallet authentication.
Base Account smart-wallet sign-in is intentionally deferred because its signature format is not currently supported by the Supabase Web3 authentication verifier used by this release. Split_it avoids presenting this unsupported path as working.
Keeping AI assistance review-first
The composer needed to be useful without giving the model authority over identity, authorization, persistence, or financial execution.
The final design treats GPT-5.6 output as a proposal. The user must review and confirm it before a request is created.
What we learned
We learned that wallet connection alone is not sufficient product identity. A reliable Web3 application also needs clear session management, backend authorization, network validation, and data-access controls.
We also learned that AI is most useful here when it reduces formatting and interpretation work while keeping important decisions visible to the user.
Finally, testing across wallets and browsers showed that capability-aware UX is more reliable than assuming every wallet or mobile environment behaves the same way.
Accomplishments
- Built a working GPT-5.6-assisted shared-expense composer.
- Implemented SIWE authentication through Supabase Web3 Auth.
- Added explicit MetaMask and Coinbase Wallet desktop-extension support.
- Targeted Base chain ID 8453.
- Added authenticated profile and split-request data flows.
- Protected application data with Supabase Row Level Security.
- Added server-side authentication to the GPT-5.6 composer route.
- Created a mobile wallet-handoff experience.
- Preserved explicit human review and confirmation.
- Maintained a clear no-funds-moved boundary.
What is next
Future work may include:
- smart-wallet-compatible authentication for Base Account;
- broader mobile wallet support;
- participant invitation and request-sharing workflows;
- collaborative review and status updates;
- notifications and richer split history;
- clearer manual and AI-assisted creation modes;
- carefully reviewed execution features only after security, authorization, and product requirements are established.
Built With
- base
- codex
- coinbase
- github
- gpt-5.6
- level
- metamask
- next.js
- openai
- outputs
- postgresql
- react
- row
- security
- siwe
- structured
- supabase
- typescript
- vercel
- viem
- wagmi
- wallet
- web3
Log in or sign up for Devpost to join the conversation.