B9Lab exercise 1, with the lessons it actually taught
splitter is the first exercise in B9Lab's Ethereum developer course — write a contract that accepts ETH from one party and splits it between two specified recipients. Five kilobytes of Solidity. The course called it "Splitter 1" because they wanted you to do it twice, the second time with more careful failure handling. This is the first attempt.
It is the simplest possible contract that has nontrivial trust questions. Who sets the recipients? Can the recipients change them? What happens to dust amounts when the input isn't evenly divisible? What if a recipient address is a contract that reverts on receive? In 2019, when this was written, the typical answer to all of those was "do the obvious thing and find out during testing why it doesn't work."
I keep this repo around as a reminder of what's not in it. There's no reentrancy guard — at the time I hadn't internalized that pattern. There's no withdraw-instead-of-push for handling recipients — same. There's no event emission for off-chain observability — the importance of that wouldn't click for me until I tried to debug a deployed contract a few months later. The contract works for the happy path and falls over on edge cases that, at the time, I didn't know to look for.
That's exactly the point. Smart-contract development teaches you a kind of caution that you don't have a name for until you've been bitten. The list of patterns — pull-not-push, checks-effects-interactions, reentrancy guards, careful event design, careful access control — every one of these is a scar tissue from a category of bug. You read about them. You nod. You then write a five-kilobyte splitter contract, ship it to Ropsten, and discover one of them the hard way.
The repo is here because the first time through this loop is the version of you that should be preserved. The polished, audited, careful Solidity you write three years later is impressive but not interesting. The five kilobytes of "I just learned what a fallback function is" is interesting, in a museum-piece kind of way.
I also keep it as a reminder of how quickly the Ethereum tooling has moved. In 2019 this compiled with Truffle. Truffle is now deprecated; Foundry replaced it. In 2019 you tested with truffle test against a local ganache. Now you write Solidity tests in Solidity and use forge test. The ecosystem treats five years as deep history.
What becomes possible: I can pick up a Solidity codebase today and the questions I ask are because I once wrote a splitter that didn't handle them.