My money, my bot — and then a vault

For years I'd been providing liquidity on SaucerSwap, putting my HBAR to work in the pools. But the same thing kept happening: the market would move, my position would drift out of range, and my liquidity would sit there doing nothing until I noticed and moved it by hand.

I went looking for something that would handle that for me — a trading bot, and a platform that was honest about what it was doing with my money. Something that would keep my liquidity working without me watching it every day. I couldn't find one I trusted.

So I started working out how to build it for myself: an automated strategy I could actually rely on, following one idea — move with the tide of the market instead of fighting it. Buy into strength, step back in weakness, hold through the middle.

I ran it on my own account, with my own money, for months. Long enough to see where it worked and where it didn't — and long enough that I trusted it before I ever thought about letting anyone else in.

I'm not a developer. I work in IT as a consultant and project manager, and this started as a hobby — something I built in my own time because I wanted it to exist. I worked out the strategy and the design myself, and I built it with the help of Claude, Anthropic's AI, which wrote the code alongside me.

As it grew, I stopped treating it like a hobby and started treating it like something that would have to earn other people's trust. That meant building it the careful way, and testing it far harder than I'd need to for just myself. I'm not a developer, which is exactly why I tested it harder than I would have for myself alone.

Because running a bot on my own money is one thing. Letting other people take part is another — unless I could do it without ever holding their funds. That's what I set out to build: a non-custodial vault, where the contract holds the position and you keep control. I can pause the bot. I can't touch your money or close the exit, because I never hold it.

And I wanted one fee, charged only when it's fair: 15% of the profit, measured in dollars above what you put in. No gain, no fee. No entry cost, no exit cost, no yearly cost, no lock-up. I didn't want to earn anything unless the people in the vault did.

Crypto projects get audited for a reason: an outside expert reads the code looking for the ways it can be made to do something it shouldn't. It's the closest thing the industry has to a seal of approval. And yet the history of the past ten years is full of projects that passed an audit and were drained anyway. An audit is a snapshot of one version, on one day, by one team. Attackers don't work that way.

So I didn't treat an audit as a finish line. I studied how the major audit firms actually work: what they look for, in what order, which classes of bugs they hunt first and which tools they run. Then I worked those audits out myself, step by step, and I wrote the contract with that checklist as the starting point rather than the final exam. Every function was written knowing which question an auditor would ask about it.

On top of that, I went through the vault hacks themselves: how real vaults on real chains were emptied, what the attacker did, which assumption broke. Each pattern became a question for my own contract, and later a test against it.

Here's where I think we are now, and where it's going. Automated AI agents are getting good at probing smart contracts for weaknesses, and that will only grow. I'm not hoping this vault stays unnoticed. I assume it will be attacked, by people and by agents, and I built it as if that's a matter of when.

What I can't tell you is that there's nothing left to find. I don't know what I don't know. There may be a weakness I haven't thought of, and if there is, someone will try it. So from here on I follow the crypto hacks every day, in my own news feed, and I check each new one against this vault. What I can tell you is this: I trust it enough to put my own money in, and that's the only reason I'm asking whether you want to.

The vault is an immutable contract: once I deployed it, I can't change the rules. No admin key, no back door. That means getting it right the first time is everything — so I took my time.

But it had to be more than right. It had to hold. I'm putting my own money in this, so I had my own reasons to get it right. And for anyone else who takes part, it has to be something they can rely on — not just today, but under pressure.

So I was deliberate. The contract went through six review layers: dependency scans, static analysis, a manual review I proved with mutation testing, two AI contract reviews, mathematical verification of several key properties, and a 48-hour live run. Along the way I found things I'd gotten wrong, and I fixed them before I froze the launch version.

Reviewing code isn't the same as attacking it, so I attacked it myself. With Claude, I built an attacker — an agent whose whole job was to come at the vault the way a real attacker would. I pointed it at the history of crypto itself: the hacks and exploit patterns from the past ten years, the ways real projects have actually been drained. If it had worked somewhere before, I wanted it tried against my vault.

It ran a structured series of 16 attacks against the vault — trying to drain it, re-enter it during payouts, manipulate the price it reads, force withdrawals it couldn't cover, abuse a stolen operator key, and break the emergency exit. Each one checked the vault's internal state before and after, and left a transaction on the chain that anyone can verify.

Thirteen held cleanly against the frozen contract. One more I had already proven on the previous version, on code that didn't change, so I didn't repeat it. The last two are known trade-offs I'd designed around, and I wrote them down honestly below. The vault held; no internal check ever broke.

Two things came out of my testing that I want to be upfront about. Neither lets anyone take another participant's principal; the first is bounded by the contract, the second is prevented by how I run it; both are flagged for the independent audit to confirm.

The first: a stolen operator key, during a sustained stablecoin de-peg, could cause limited harm. The strategy swaps between HBAR and USDC, and in that specific situation an attacker holding the operator's key could swap at a bad rate. I measured exactly how much, and I mitigate it three ways:

1. 1A daily cap, built into the contract. The bot can only swap a limited amount per day, so the damage can never exceed that cap — and nothing beyond the portion being rotated is ever at risk.
2. 2A de-peg halt in the bot. The bot checks whether a stablecoin has lost its peg, and stops swapping into it when it has — so the bad-rate swap doesn't happen in the first place.
3. 3The independent monitor. It watches around the clock and raises an alarm the moment something looks wrong, so I'd know immediately.

A brief price spike isn't enough to do anything; it would take a sustained de-peg, past all three of these, to cause even the limited, capped harm I measured.

The second: a new depositor into an emptied vault would inherit rewards that were still vesting from before. I handle this with an operational rule I follow — I never allow fresh deposits into a vault that's been emptied while rewards remain. The contract doesn't prevent this on its own, so my operations do.

I'm telling you this not because I have to, but because a vault that hides its limits isn't one I'd put my own money in — so I won't ask you to.

The whole design has one rule above the rest: I can't lock you in. If the bot goes silent for 48 hours, the emergency exit opens to everyone; after seven more days, anyone can wind the whole vault down — not just me. I tested exactly that, on-chain: a wallet that wasn't mine opened the wind-down, touched no one's share, took nothing extra, and everyone could claim their own portion.

Opening the exit gives the person who opens it no advantage. It just opens the door, fairly, for everyone. That's the property I care about most, and it's proven on-chain. So if I and the bot go offline for any reason — if I disappear, if the servers die, whatever it is — nobody is trapped. The exit is there, it works without me, and anyone can open it.

I keep investing in this, with my own money and my own time, and I keep building. Eb & Vloed is one strategy. I have eight other kinds of bots in the pipeline, each built on a different idea about how a market moves, and each one will go through the same road this vault did before anyone else gets near it.

None of them launches on a schedule. A bot launches when three things are true: the strategy shows an edge in the backtests, across whole cycles and not just the last good year; the code has been through the same review layers and the same attacks as this vault; and it has run on my own money long enough for me to trust it. If one of those never comes true, that bot never launches. I'd rather have one vault that holds than nine that might.

I built a non-custodial HBAR/USDC vault on Hedera. It started as a bot trading my own money; now others can join without handing me theirs. One fee — 15% of profit, no gain no fee. No entry, exit, or yearly cost. Immutable contract: no admin key. I can pause the bot, but I can't touch your funds or close the exit.

Before launch I put it through six review layers and attacked it myself — 16 structured attacks against the frozen code. 13 held cleanly; one I'd already proven on the previous version, on unchanged code; the last two are known trade-offs I documented honestly. I proved on-chain that anyone can open the emergency exit if the bot goes silent — and that whoever opens it gets no advantage.

It's live on testnet now — connect a wallet and try it. An independent audit comes before mainnet. The testnet vault is public on HashScan, so you can check every transaction it makes yourself, and every test result is listed with its transactions.