Before I wrote a single line of DeFi code, I was sitting next to rocket engines.
My job was to make sense of what they were doing while they fired: pressure, temperature, thrust and mass flow, streaming in live and full of noise. Later, I qualified a satellite's oxidizer fuel to be commissioned to SpaceX. In a nutshell, I spent a month proving that a tank of highly concentrated hydrogen peroxide would not explode before launch.
Today, among other things, I build the controllers behind DAMM's leveraged looping strategies. I expected to learn a new field... but mostly, I recognised an old one.
A leveraged loop is a pressurised system: it holds more than it could on its own, it earns because of that, and it fails badly if nobody is watching it. So... wtf does rocket science have in common with looping, you may ask?
What a loop is
A loop deposits a yield-bearing asset as collateral, borrows against it, buys more of the same asset and deposits that too. Repeat a few times and you hold several times the asset for the same capital. The position earns the asset's yield on the whole stack and pays the borrow rate on everything it borrowed:
Here L is the leverage, y is the asset's yield and b is the borrow rate. While y is above b, leverage multiplies the spread. When b climbs above y, leverage multiplies the loss. Everything below is about living with that second case.
1. Both are slow pressure problems
In the lab. High-test peroxide is never perfectly still. It slowly decomposes into water and oxygen, and in a sealed tank the oxygen has nowhere to go, so the pressure creeps up. No single hour looks dangerous. The danger is what builds up over a month, which is why my SpaceX deliverable was a month-long storage test and not a snapshot.
In a loop. The same pattern applies. A borrow rate slightly above the yield for a day costs almost nothing. Let that gap persist for three weeks, amplify it with leverage, and it can quietly erase months of carry. Liquidation risk can build the same way: debt outpaces collateral until the safety margin disappears. For major ETH LSTs, our use of fundamental oracles limits the direct impact of temporary market depegs on collateral valuations, leaving interest rates as a central risk. The danger is often not one bad block, but a slow accumulation of pressure that nobody responds to in time.
2. Filter before you act
On the test stand. Sensor readings from a firing engine are messy. A chamber-pressure trace can jump because of combustion instability, electrical noise or a bad sample. The challenge is telling a real problem from a noisy reading. Rolling medians and frequency analysis over moving windows help make that distinction, so the control system responds to meaningful changes in the engine's behavior.
In a loop. Borrow rates are just as noisy. A large withdrawal pushes utilization up and the rate jumps. A few blocks later, fresh supply arrives and it falls back. Reacting to every jump would mean repeatedly unwinding and rebuilding the position, paying fees each time. So I treat borrow rates, utilization and yields like sensor channels: filter the readings first, then act when the signal warrants it.
3. The PID: from an oxidizer tank to a loop exit
In the lab. For the storage test, I held a tank of 99% hydrogen peroxide (high-test peroxide, a rocket oxidizer and a military-grade explosive) at exactly 25 °C for a full month. Then I measured how much it decomposed and how far the tank pressure rose. A PID temperature controller held the tank steady 24/7:
- P (proportional) corrects when the temperature deviates from the 25 °C target.
- I (integral) makes the correction harder as this error accumulates.
- D (derivative) reacts to how fast the temperature error is changing.
The results went to SpaceX as evidence that the satellite complied on the ground.
In a loop. The hard question in looping isn't when to enter. It's when to leave. Unwinding isn't free: you pay swap fees, slippage and gas. Exit on every blip and fees eat you. Wait too long and the bleed does. I answer it with another PID controller:
- P is how fast the position is bleeding right now.
- I is the total cost of staying in so far. This is the dominant term, and it works like the slow pressure rise in the tank.
- D is whether the bleed is speeding up or slowing down.
The controller exits when the projected cost of staying is higher than the cost of leaving.
The sweet spot of a PID: there's not much to train, good old classical control. The control law itself is the model. A machine-learning exit signal can overfit to last year's rate spikes, but a PID can't memorise anything, so it's very hard to fool yourself with it.
4. Redlines
On the test stand. Every engine test has redlines. If chamber pressures or temperatures go past a hard limit, the stand aborts on its own. There's no discussion and nobody gets to override it. Safety first, only then work out what happened afterwards.
In a loop. The PID handles the slow, financial question. Some conditions aren't financial questions at all. A loop has its own redlines: how close the position is to its liquidation threshold, whether the collateral is trading away from its fair value, whether the price feed the lending market relies on still makes sense, and whether there's enough liquidity to unwind at size. When one of those is crossed, the position shouldn't be weighing costs. It should be getting smaller. The slogan persists: safety first, analysis later.
5. Test like you fly
In aerospace, hardware climbs a ladder of tests before it's allowed anywhere near a launch:
- Cold-flow tests. Propellant runs through the plumbing with no ignition, to prove the valves, sensors and timing before anything burns.
- Hot-fire tests. The engine is lit on the stand, first for a few seconds, then for longer.
- Qualification tests. A test unit is pushed past anything it should ever see in flight (hotter, longer, harder) to prove there's margin.
- Acceptance tests. Every unit that will actually fly is tested at flight conditions, because a sister unit passing proves nothing about this one.
- Storage and compatibility tests. Like the peroxide test month: proving that propellants and materials behave over the time they'll really spend together.
The rule behind all of them is test like you fly: the real temperatures, the real duration and the real vibration. A test that only shows what you hoped to see doesn't count. Failure reviews are written up and read by the whole team, and a reversed conclusion is treated as the system working.
Our research follows the same rule:
- Walk-forward, out-of-sample testing. A controller is tuned on the past and scored only on data it has never seen. That's how a flight would test it.
- Perfect-foresight ceilings. Every exit rule is measured against the best exit timing that was possible in hindsight, the way an engine is measured against its ideal performance.
- Real costs in every backtest. Gas, slippage and our own market impact on the unwind are all charged.
- Margin, not fit. Like a qualification test, a controller has to hold up through periods rougher than the ones it was tuned on, not just score well on average.
- Published reversals. Our internal research log is full of entries where an exciting result was killed by a careful re-test, like a look-ahead leak or a bug in the accounting. We treat those as our most valuable findings. All of this happens in staging: nothing reaches production until it comes out clean on every metric.
Why I came to DeFi
Aerospace has some of the best control engineering in the world, and I loved the work. But I always wanted to get into finance somehow, and I wanted to build things with real impact, working with friends. In aerospace my contribution was marginal: one engineer among thousands, on programmes that take years, with maybe one engine test a week and one launch a year.
At DAMM the loop is much tighter. DeFi runs around the clock, every state variable is public, and feedback arrives in blocks. Borrow rates, utilization, collateral prices and liquidations are sensor channels anyone can read. For someone trained to filter, control and qualify physical systems, that's an unusually good test bench. The controller I write today runs on real capital, next to people I chose to work with, and whether it's right shows up in days, not years.
The engines changed, but the engineering is, somehow, analogous.
DAMM Capital builds institutional-grade onchain strategies. The controllers described here are simplified for illustration. Production parameters, signals and thresholds are proprietary.