Protocol architect and engineering lead

Security practice

Most of the bugs I have found in production did not throw an error. They balanced. They reconciled. They were simply paying the wrong number to the wrong person, quietly, for weeks. That class of defect is why I think security is a design activity rather than a testing activity — you find these by reasoning about state transitions, not by waiting for something to go red.

What that looks like in practice

• Specifying a system's financial invariants explicitly — budget conservation, monotonic allocation, duplicate-free trees, encoding matched byte-for-byte against the on-chain verifier — and then enforcing them in tests and in scripts that run against production data as a deployment gate.
• Leading external audit engagements from the client side: scoping, responding to findings, deciding remediations, and arguing when I disagree.
• Running an internal review pass before anything reaches an external auditor.

Track record

• Sole counterpart to external auditors across four engagements at Hydrex. The decentralisation workstream I delivered came back with zero high-severity findings across fifteen contracts, and no failed remediations.
• Took Amana through external audit by Linum Labs as founder, having run static analysis in-house first.
• Took Crystl Finance's V3 vault contracts through a HashEx audit — both the preliminary and final reports are public.
• Completed a platform-wide threat model at Atem, covering databases, contracts, frontend, hosting, multisigs and custody, with a matching control table for prevention, monitoring and response.
• Competing in audit contests, with accepted findings on HackenProof.

I also build my own review tooling — a private toolkit covering EVM contracts, Solana programs and L1 protocol code.

How I work with AI

I use AI heavily and I am specific about how, because I got it wrong once in a way that taught me the actual lesson.

On one workstream I let the model build a contract family end to end. I designed the architecture and stayed too far from the implementation. The tests were written by the same model, in the same context, as the code they were meant to falsify — so a green suite carried no independent signal at all. It was self-confirmation dressed as verification. An external audit found what the tests could not.

Nothing was deployed and no user funds were ever exposed. But the failure was worth more than the workstream would have been, because the diagnosis generalises: the problem was never the tool, it was the verification model. The speed was real. The checking was circular.

What I rebuilt afterwards is a single idea applied consistently — introduce independent signal at every point where I was previously trusting my own first answer:

• Shorter iterations. Stay in the decisions rather than reviewing a finished artefact.
• Principles encoded into the tooling, not remembered. Standards live in the instruction files the model actually reads — priority ordering, minimal diffs, and a rule that a test which would pass against a no-op function is not a test.
• A reviewer in a different context. A separate agent reviews the work, deliberately outside the window in which it was written, told plainly that it did not write this code and should review what it permits rather than what the author intended. It reports and never edits.
• Review stages before the external auditor, so the auditor is not the first independent reader.
• My own audit tooling, built around adversarial refutation and proof-of-concept evidence rather than assertion.

I also proposed the weekly internal forum where my team now compares notes on what is working with these tools. Being asked to present my own method to peers is what forced me to articulate it properly — which is usually how it goes.

Architecture, correctness and security remain mine. The tooling is leverage, not delegation.

About

I came to software late and deliberately.

I read Philosophy and Pure Mathematics, then Electrical Engineering, at the University of Cape Town. I started out in corporate finance — leveraged finance at Citigroup in London, equity research at Sanford C. Bernstein before that — then came home and spent the next decade in leadership work: setting up and running a political party's leadership academy, then designing programmes for corporates, then heading a coaching practice. Along the way I started two businesses, one in solar installation and one in mindfulness training.

The through-line I had lost was the one I had been best at as a teenager: mathematics, systems, and code. In 2021 I went back to it properly, chose Solidity, and started building. A hackathon runner-up finish and a bounty submission turned into core-team roles at two protocols, and it has been full-time since.

What that background is actually worth. Two things, and I would rather be concrete about them than claim they make me special.

The finance is genuinely useful. Leveraged finance is structurally the same subject as DeFi lending — collateral, leverage, liquidation, credit risk — so I can hold a conversation about risk in financial terms and not only in protocol terms.

The coaching matters more than it sounds. A decade of developing leaders, four years of it heading a practice, means the parts of engineering leadership that most people improvise — giving hard feedback, handling conflict, working out what someone actually needs to grow — are trained rather than guessed. I still keep a small number of senior coaching clients.

Currently in Plettenberg Bay, South Africa, working remotely on UTC+2.

Outside work: my partner and our two daughters, then surfing, trail running and mountain biking, in roughly that order of priority.

Education

• BSc Electrical Engineering, University of Cape Town — Honours, Cum Laude; Dean's List 2001, 2002, 2003
• BA Philosophy and Mathematics, University of Cape Town
• Professional Coaching Certificate, UCT Graduate School of Business