Most days building Shaka don’t look like anything. They look like a test suite running for the fourth time because I changed one line and wanted to make sure I hadn’t broken a guarantee I’d been relying on for three weeks. They look like me reading the same function for an hour, not because I don’t understand it, but because I’m trying to understand what someone who wants to misuse it might see.
That’s the job. This is what it actually is.
What Shaka is, for context
Shaka is a B2B onchain payment router built to run natively on Ethereum. The mechanical pitch is simple enough: a deal link is created with every recipient wallet and their split. The client shares it with the buyer — no bank involved, no back-office to manage. The buyer pays once. The smart contract routes every share simultaneously, to every wallet, in a single transaction.
No custody. No counterparty risk. Shaka never holds funds. The smart contract routes payment directly from sender to recipients the moment the deal is confirmed.
And the piece that concentrates the weight: the smart contract is fully immutable. No party — including Shaka LLC — can modify, pause, upgrade, or terminate it after deployment.
That’s the product. Kooky, the builder behind Shaka, is me. There’s no team. There’s no second pair of eyes on the contracts before they go out. The decisions I make become permanent, and they handle real money. That reality shapes everything about how I work.
The discipline of testing money code
There’s a version of software where a bug costs you embarrassment and a hotfix. There’s another version where a bug costs someone their money, and there is no hotfix because the contract is immutable by design. I work in the second version.
Smart contracts are stateful, adversarial, and often value-bearing. Bugs may only appear when inputs hit extreme ranges or unexpected combinations. That’s the testing problem stated plainly. The inputs you write tests for are the inputs you thought of. What breaks things, usually, are the ones you didn’t.
My approach to this isn’t elegant — it’s layered and paranoid. The discipline combines unit tests to prove expected behavior, fuzzing to explore wide input spaces automatically, and property-based or invariant testing to continuously validate protocol-level safety rules across many executions. None of these is optional. Each one catches something the others miss.
The invariant layer is where I spend the most deliberate time. Invariant tests are stateful fuzz tests that assert “rules” which must always hold true, even after any sequence of contract calls. For a payment router, the invariants that matter aren’t exotic. They’re things like: the sum of amounts routed to recipients must always equal the amount paid, minus the protocol fee. The fee must never exceed what the contract says it is. No recipient wallet can receive more than their allocated share. These statements are obvious when you write them down. The work is proving, exhaustively, that no sequence of inputs can violate them.
Rather than testing specific inputs, a fuzzer generates thousands of random transactions to find edge cases that violate specified invariants. Auditors write properties in Solidity that should always hold true, and the fuzzer attempts to break them. This approach excels at finding unexpected state transitions and complex multi-transaction bugs that static analysis might miss.
I’ve had invariant tests surface things that looked impossible on paper. A rounding behavior at a very specific split ratio. An edge case involving a recipient count I hadn’t explicitly thought through. These aren’t dramatic exploits — they’re the kind of quiet, boring bugs that live in production code for years unnoticed, until the one day they’re not.
Invariant tests can uncover issues that may not be evident through standard unit tests, especially with extreme values or unusual sequences of actions. They are not limited to testing isolated contract methods but rather observe how different functions interact with each other over time, ensuring that the core requirements of the protocol are respected under all circumstances.
The cost of being wrong here is specific and irreversible. That’s not a rhetorical point. The Shaka smart contracts are immutable. Once deployed, they cannot be modified, upgraded, or overridden by anyone — including Shaka LLC. No human intervention is possible in the execution of smart contract logic. That immutability is a feature — it’s the foundation of the trustlessness the protocol offers. But it means the testing phase isn’t a prelude to the real work. It is the real work.
The small decisions that mattered
Not every decision that shaped the protocol felt significant at the time. Some of the ones that mattered most came disguised as minor implementation choices.
The fee architecture is one. The Shaka protocol charges a 2% fee on each transaction, collected automatically by the smart contract at the moment of payment. This fee is hardcoded and immutable — it cannot be changed by anyone. That’s not just a pricing decision. It’s a trust decision. A fee that could be changed by an owner is a fee that will be changed, eventually, and users have to price in that uncertainty. A hardcoded fee is a promise that survives me.
The decision to build with no admin key is in the same category. Open source. Immutable. No admin key, no owner. Technically, this forecloses options. If I find a bug post-deployment, I can’t patch it. But it also means that nobody — including me — can rug the protocol, freeze funds for political reasons, or quietly extract value in ways users can’t see. Some protocols take this design deliberately: it makes the protocol maximally trustless and resistant to regulatory or governance interference.
Each of these choices looks like a line in a config file. Each one, once deployed, is permanent.
What “live” actually means
There’s a specific psychological shift that happens when you go from testnet to mainnet. On testnet, you’re running experiments. On mainnet, you’re running a live payment protocol that holds and routes real value, and the sentence “just roll it back” doesn’t apply.
Use of blockchain protocols involves significant risk, including but not limited to: smart contract bugs, network congestion, token price volatility, regulatory changes, and loss of private keys. I put that in the terms not as a legal hedge but because it’s true, and I want the people using Shaka to understand what they’re interacting with. The contract is honest about what it is. I try to be too.
“Live” also means that the testing I did before deployment is the only testing that counts. There’s no iteration on a live immutable contract. You get one shot at the initial state. Everything after that — the frontend, the domain resolution layer, the partner integrations, the documentation — can be updated and improved. The contracts cannot. So the pre-deployment period isn’t a sprint to launch. It’s the period when the product is actually being built, in the most consequential sense of the word. What ships is what persists.
That weight is real. It doesn’t go away. But it’s also clarifying. There’s no ambiguity about what matters.
The tradeoffs of building solo
Solo building has a particular shape. The advantages are real and I don’t want to be falsely modest about them: coherence, speed of decision-making, no coordination overhead, no design-by-committee. Every architectural choice reflects a single set of values and a single read of the tradeoff. The product is internally consistent in a way that’s hard to achieve with a team.
The liability is equally real: there’s no safety net. No one to catch what I’ve normalized past. No second engineer to say “wait, have we tested what happens if someone sends this with zero recipients?” That question might occur to me. It might not. Effective smart contract auditing requires a multi-tool approach, combining the strengths of different analysis techniques. Solo, the only way to approximate that multi-perspective rigor is to build process that forces you to confront your own blind spots — more test layers, more deliberate adversarial thinking, longer review periods than feel necessary.
The methodical, unglamorous work of that is “bad for timelines, good for the product.” That phrase has become something of a private organizing principle. Every time I spend an afternoon on a test that will never be visible to users — a test for a scenario that has a one-in-ten-thousand chance of occurring — I’m buying a small amount of the kind of confidence that a payment protocol actually needs to earn. That work doesn’t compound visibly. But it compounds.
Why I build in public
The short answer is: because the product itself demands transparency, and there’s no coherent way to build a trustless, immutable, open-source protocol while treating the build process as something to hide.
Kooky.shaka is live today, resolving to his wallet on every deal he creates. It is both the proof of concept and the namesake of the protocol it now powers. That’s not a marketing beat. It’s a statement about what I’m doing: I use what I build. I’m in the system. I eat the cooking. Building in public makes that visible, and being visible about the process is a form of accountability that feels appropriate when the thing you’re building routes money.
There’s also a simpler reason. The only way for someone evaluating Shaka to know that the testing discipline was real, that the architectural choices were deliberate, that the tradeoffs were understood rather than stumbled through — is to show the work. Not the metrics, not the launch announcements: the actual reasoning. The decisions. The ugly middle of it.
What it actually takes to ship a payment protocol solo isn’t dramatic. It’s a test suite running for the fourth time. It’s reading a function for an hour. It’s resisting the urge to ship something that passes tests but hasn’t been sat with long enough to reveal what it doesn’t test.
That’s the build. That’s what live means.