Splitsy
Splitsy is a Next.js prototype for splitting shared costs and collecting them in
USDC on Arc. You can state a debt in one sentence, scan a
receipt into a full split, or set up a tab that repeats — and settle any of it
from a wallet you get by signing in with X, Discord, Google, or an email code.
It runs on Arc Testnet with test USDC. One variable
(NEXT_PUBLIC_ARC_NETWORK=mainnet) moves a deployment to Arc mainnet; nothing in
this repo asserts that flip has happened, and it has not. Every network-dependent
word on the site follows the same switch as the addresses — ARC_LABEL,
USDC_LABEL and MONEY_NOTE in lib/arc-chain.ts — so the flip changes "Arc
Testnet · no real funds" into "Arc · real USDC" everywhere at once rather than
leaving the risk disclosure behind. See Networks.
What it does:
- IOUs — one sentence is the whole bill. "@dani owes me $42" files a
one-participant on-chain bill; "I owe @dani $42" sends the USDC straight to
them. The contract forces which rail is which, because
claim only ever pays
the wallet that created the bill.
- Pay someone who has no wallet yet — tag a handle nobody has signed in as
and the money goes into
HandleEscrow instead of nowhere. Their first sign-in
releases it to the wallet they actually sign in with; until then the depositor
can take it back with reclaim.
- Receipt scanning by an autonomous OCR agent ("Scout") that pays for its own
AI tooling in USDC fractions over x402 (Circle Nanopayments).
- Social sign-in via X, Discord, Google, or a one-time email code — each one
provisions a wallet, with no seed phrase and nothing to install.
- FX conversion into USD, then equal or manual splitting.
- Onchain bill submission, wallet-based debt discovery, and Arc transaction memos
for reconciliation.
- Circle Gateway for cross-chain USDC payments from Avalanche, Base, or
Ethereum directly to Arc.
- Recurring USDC tabs with cycle settings and allowance-based collection.
- Net-settlement treasury — every open position collapsed to one net figure
per counterparty, then discharged through the registry's own
settle call.
- Debtor-side autopay — each account gets its own user-funded agent that
settles that account's shares as ERC-8183 jobs, audited by a second Splitsy
agent that is paid over x402 to check the work.
Networks
NEXT_PUBLIC_ARC_NETWORK is the only Arc switch, and the match is exact: only
the literal string mainnet selects mainnet, so a typo, a capitalised value or
an unset variable all land on testnet, where being wrong is free
(resolveArcProfile, lib/arc-chain.ts).
| Arc Testnet (default) | Arc mainnet |
|---|
NEXT_PUBLIC_ARC_NETWORK | unset, or anything but mainnet | mainnet |
| Chain id | 5042002 | 5042 |
| RPC | https://rpc.testnet.arc.io | https://rpc.mainnet.arc.io |
| Explorer | https://testnet.arcscan.app | https://explorer.arc.io |
| USDC | 0x3600…0000 | 0x3600…0000 (the same) |
| Money | test USDC, no value | real USDC |
Chain id, RPC, explorer, USDC and the two Gateway addresses all follow from that
one switch and are no longer settable one by one.
Deployment addresses are not properties of a chain, so they are not in
lib/arc-chain.ts. They follow the switch by a naming rule instead: the
unsuffixed variable is the testnet slot, and a _MAINNET twin is the
mainnet slot (forArcNetwork()). So a testnet deployment needs nothing renamed,
mainnet is configured by adding variables rather than editing them, and both
sets can sit there fully populated with one variable deciding which is live.
Mainnet never falls back to the testnet slot. A _MAINNET address left unset
resolves to the zero address, which every consumer already reads as "not
configured" and refuses on (isBillRegistryConfigured(),
isHandleEscrowConfigured(), isMandateConfigured()). Quietly using a testnet
address on chain 5042 is the exact failure that rule exists to stop.
One thing mainnet does not have, and it is not a bug:
- ERC-8183
AgenticCommerce is absent, so NEXT_PUBLIC_AGENTIC_COMMERCE_ADDRESS
stays unset there, isJobsConfigured() is false, and the job-market half of
autopay is off.
x402 batching used to be the second one, and no longer is.
@circle-fin/x402-batching shipped exactly one Arc entry, arcTestnet, so
getScoutGateway() and getSettlerGateway() refused on mainnet rather than
batching real-money nanopayments onto a test chain. Version 3.5.0 added arc to
both CHAIN_CONFIGS and GATEWAY_DOMAINS, so the chain now follows
ARC.x402Chain and Scout runs on whichever network the deployment is on.
ERC-8004 is live on both networks, at different addresses, and is opt-in on
both (see Payment Reputation).
docs/deployments.md is the operational companion to this section: which host
runs which arrangement, and everything about it that is done by hand.
Wallets
Two wallet stacks live in one repo, selected per deployment rather than per user.
WALLET_PROVIDER decides who holds the wallet; WALLET_UI decides who
asks the user to approve a payment. Both match exactly and both default to the
older stack, so a typo or an unset variable in a new environment can only ever
land on the Circle path.
| WALLET_PROVIDER=privy + WALLET_UI=privy | unset (Circle) |
|---|
| Wallet | Privy embedded wallet, an EOA the user owns from creation | Circle developer-controlled wallet (SCA) |
| Login door | Privy's modal (X, Discord, Google, email) | Splitsy's own OAuth routes |
| Approving a payment | Privy's confirmation prompt, per transaction | a PIN that unlocks sends for five minutes |
| Settle net | 1 approve + 1 settle | 1 atomic executeBatch |
| Key export / claim ceremony | not applicable — it is already the user's | WALLET_CLAIM_ENABLED, off by default |
여기까지가 README 앞부분입니다. 나머지는 원문에서 읽을 수 있습니다. README 전문 보기 ↗
