From "What do I owe you?" to a single transaction

Sunday evening. Four friends are heading home from a weekend away. Camille booked the place, Alex bought groceries and Lou paid for parking. Sam asks how much to send.

The characters and amounts are invented. Let’s work through the accounts. To keep the numbers consistent all the way to payment, the expenses in this example are already denominated in USDC, the token Spliz uses for settlement.

Camille paid 120. Alex paid 60, Lou paid 20 and Sam hasn’t paid anything yet. The total is 200 USDC, split equally: 50 each.

Camille needs to receive 70 and Alex 10. Sam needs to pay 50, Lou 30.

Sam has his number. He still needs to know where to send it. And Camille has just found another receipt in her pocket.

Building Spliz meant making room for each of these moments. The late receipt, the agreed amount, the money sent. They might happen seconds apart or drag on for weeks. The app has to keep an accurate account of where things stand.

Four balances, three transfers

The friends could settle their current balances with these payments:

After those transfers, each person will have paid their 50 USDC share. Of the 200 spent on the trip, only 80 still needs to move. For this first calculation, we’re leaving settlement fees aside.

This is netting. Work out what each person paid, subtract their share, then match the people who need to pay with those who need to receive.

There are different ways to choose the transfers. Reducing the total amount moved and reducing the number of transfers are separate objectives. David Vávra’s 2012 thesis describes at most N−1 transfers for N participants, without guaranteeing the minimum.

This work has a history. In 2018, Adrien Arcuri described an Ethereum contract for shared expenses, including participant agreements and repayments in Ether.

Those projects establish the foundations. Our arithmetic fits in a few lines. Moving the 80 USDC still requires something that arithmetic can’t supply.

A number on a screen isn’t permission to charge

Suppose Sam agrees to pay his 50 USDC. Before settlement, Camille adds the forgotten receipt: another 40 USDC for the group. Everyone’s share goes up by 10. Sam now owes 60.

Agreeing to 50 obviously doesn’t authorize 60.

That gives the confirmation button a specific job. In Spliz, settlement approval is a signed message. Its fields include the Spliz identifier, the participant, whether they are paying or receiving, their amount and a fee ceiling. A timestamp limits how long the approval is valid.

The format, EIP-712, specifies how to sign structured data. A contract, the program that will execute settlement on Base, can check who signed and detect changes to the signed fields. The signing context also identifies the network and the contract involved.

Entering an expense in the app therefore never grants permission to move money by itself.

In the application flow, a change that alters the balances clears the existing confirmations. The group has to approve the new calculation. This invalidation happens on the server: removing an approval from a database doesn’t erase the bytes of a signature that already exists.

That boundary matters. The contract checks the authorizations and the consistency of the transfers submitted to it. It doesn’t read Camille’s receipt or recalculate every expense. Connecting the expense record to the settlement remains the application’s responsibility.

Permission to spend comes next

Back to our original calculation, before the forgotten receipt. Sam agrees to pay 50, Lou 30, Camille expects 70 and Alex 10.

The contract has their agreements. It also needs permission to transfer USDC from the payers’ wallets.

That second authorization uses a permit, defined by ERC-2612. Sam and Lou sign a spending authorization for the contract, with an amount and a deadline. The amount covers their payment and applicable fees. A counter prevents repeated submission of the same permit.

So a payer signs two distinct objects: approval of the settlement and permission to spend the token. This is worth explaining whenever a confirmation button stands for both.

The signatures are created offchain. Friends can confirm at different times. A server, called a relayer, collects the required signatures and submits the transaction to Base. It pays the network fee, known as gas, for that transaction.

The USDC stays in each person’s wallet until it moves. This settlement doesn’t require the group to deposit funds into a shared pool first.

1. The app calculates balances from the expenses.
2. Participants approve the settlement. Payers also sign a permit.
3. The relayer submits the authorizations to the contract on Base.
4. The contract checks them, then executes the transfers in the same transaction.

Covering gas doesn’t make every cost disappear. The version described here charges 0.1% of the amount transferred, with a 0.10 USDC minimum. Our 80 USDC example therefore adds 0.10 USDC in fees, shared between the payers. Buying USDC or converting it back can also cost money.

The last transfer can undo the first

Suppose Lou only has 25 USDC left when execution begins. The contract starts the transfers. Sam’s 50 goes through. Lou’s 20 to Camille goes through too. Lou has 5 left: the transfer of 10 to Alex fails.

In Spliz’s atomic settlement, that failure rolls back the effects of the earlier transfers in the same transaction. Camille doesn’t keep a partial settlement while Alex waits for the rest.

That’s the precise meaning of atomic: the transfers in this transaction succeed together or none of them takes effect. The relayer still pays for gas consumed by a failed transaction.

Before executing the transfers, the contract checks the signatures. It also verifies that outgoing and incoming amounts match the approvals, that participants aren’t duplicated and that this Spliz hasn’t already been settled. USDC moves directly from each payer’s wallet to the recipient’s wallet.

One transaction contains several transfers. Bundling them also reduces the number of transactions to submit, but the property that matters here is their shared outcome.

There’s another detail that rarely makes it into a demo: a phone can lose its connection after submission. Silence from the phone says nothing about the result on Base. The app has to find the transaction and check its status before reporting success or preparing another attempt.

Signing, submitting and confirming are separate stages. Confusing them can put "paid" on a screen before a payment has succeeded.

The payment happened. Zero is no longer enough.

After a repayment, Sam’s balance reaches zero. The next day, he wants to leave the Spliz.

A rule sounds reasonable: a zero-balance entry has no debt left, so it can be deleted. This was one of the problems encountered while designing Spliz’s ledger.

Yet zero can tell two different stories. Sam repaid 50 USDC. Someone else never had an expense or a payment. A deletion rule that only looks at the balance treats both situations alike.

Sam’s entry contains evidence he may need later. If Camille thinks a repayment is missing two weeks from now, he should be able to show what happened.

The events that explain a balance have to survive. An expense records an advance and how it is shared. A payment records money moving. The balance is calculated from those records; it can’t replace them.

This distinction also changes how errors get corrected. If the friends revise an expense split after an individual repayment, that payment still counts. The new calculation has to include it.

Vávra also reports edits to 25% of entries from February to April 2012. How often that happens in Spliz will need to be measured in actual use.

Our design check is now concrete: after an action, can someone still find the amount they owe, its recipient and the entries that explain it? If one of those answers disappears, the model has lost something.

A blockchain can’t read the receipt

Camille’s forgotten receipt might be right. It might also include something she bought for herself. No signature settles that question.

A contract executes authorizations according to rules. It doesn’t know who was at dinner. It also can’t supply a friend’s missing funds or make anyone confirm.

In a 2017 article about late payments, Matteo Pelati proposed netting debts between companies. The idea reduces the money needed where obligations offset each other. Any remaining amounts still have to be paid.

For our friends, waiting for every approval has a cost: collective settlement depends on the last person being ready to pay. That’s a reason to keep an individual repayment path available.

The same care applies to payments made elsewhere. If Lou pays back in cash, the app can record her statement. It mustn’t present that statement as a transfer it observed on the network. Someone reading the history needs to understand what each entry establishes.

Other dependencies remain, too. Spliz uses a server for its ledger and an authorized relayer to submit settlements. The contract can be paused. Transfers on a public chain are visible. A wallet address can also be linked to a person, as the French data protection authority, CNIL, points out. Moving execution to Base doesn’t make the entire app autonomous or its payments private.

The remaining trip to a bank account

Why USDC? Issued by Circle, the token targets a value of one US dollar. It can move through contracts, including Spliz’s. Circle describes its backing and operation.

That avoids denominating repayments in an asset such as Ether, whose price can move sharply. Other constraints remain: USDC depends on its issuer, and USDC amounts aren’t euro amounts. Our example deliberately leaves currency conversion out.

A group that already holds USDC on Base can settle from those funds. Someone who wants to pay from a bank account and receive into a bank account still faces a purchase or conversion, sometimes identity verification, and potentially a withdrawal.

That entire route has to be useful. The speed of the final transaction alone can’t tell us how much time and effort the friends spent getting there.

The next weekend

Netting, signatures and atomicity are established mechanisms. Putting them together in Spliz raises questions that can be checked in code. Whether people want to use the app takes a different kind of evidence.

We want to watch groups enter expenses, catch a mistake and repay each other without needing us to explain. Measure where they hesitate. See whether they open Spliz again for another occasion.

Camille should be able to add her receipt. Sam should understand why his amount changed before he accepts it. Once his repayment is complete, he should be able to find its record without asking Camille to reconstruct the accounts.

Next weekend, we’d like the message to be: "I’ve created the Spliz."

Sources

• David Vávra (2012): algorithms and usage, sections 2.4 and 5.2.2.
• Adrien Arcuri, Manage group expenses on Ethereum blockchain with Solidity (March 22, 2018): expense sharing, agreements and payments.
• Matteo Pelati, Solving the late payment problem with the blockchain (July 8, 2017): netting debts between companies.
• EIP-712 (2017): structured-data signatures and domain separation.
• ERC-2612 (2020): signed spending permissions, amounts, nonces and deadlines.
• Solidity documentation: error propagation and rollback of state changes in the affected calls.
• Ethereum.org: transactions, network fees and confirmation stages.
• Circle: how USDC works and the reserves held by its issuer.
• CNIL, the French data protection authority: blockchains, participant identification and personal data (in French).

Sources accessed on September 7, 2026.