DEV Community: Ehsan Mahmoudi

A Small Fintech Challenge, and Why I Let Postgres Hold the Money

Ehsan Mahmoudi — Mon, 24 Aug 2026 08:43:29 +0000

📌 Originally published at e-mahmoudi.me

A Small Fintech Challenge, and Why I Let Postgres Hold the Money

I picked up a small backend challenge recently: build a marketplace where guilds buy and auction items using in-game gold. Listings, auctions, bids, a price oracle, automatic settlement. On the surface it's a CRUD app.

The full source is on GitHub: github.com/jeyem/dragon-market.

It isn't. The moment money moves and two people act at the same time, it becomes the only problem that matters:

A marketplace can lose a feature and survive. It cannot lose a coin and survive.

Two guilds bid on the same auction in the same millisecond. A buyer spends gold they already spent on something else a microsecond earlier. An auction settles twice because a retry fired. Every one of these is a money bug, and every one of them is a race.

The interesting part of the project wasn't the API. It was deciding who is responsible for correctness. I decided it shouldn't be my Go code. It should be Postgres.

The temptation, and why I skipped it

The instinct is to reach for application-level concurrency control: a mutex around the bid handler, an in-memory queue per auction, a distributed lock in Redis. It feels like control.

It's also a trap. App-level locks don't survive a second instance of your service. They don't survive a crash mid-operation. They don't roll back. And they sit outside the system that actually stores the truth, so they're always one deploy away from being bypassed.

Postgres already solves this, and it solves it with guarantees that have been hardened for decades. So the whole design became one sentence: every operation that touches money is a single database transaction, and the database serializes the parts that conflict.

Balances you can't corrupt because they don't exist

The first decision was to not store balances at all.

There's no balance column anywhere. A wallet is derived from an append-only ledger:

total     = sum(grant, credit) - sum(debit)
reserved  = sum(reserve)       - sum(release)
available = total - reserved

This sounds like a performance compromise. It's actually a correctness gift. A mutable balance column is the classic lost-update bug waiting to happen: read 100, read 100, both subtract 30, both write 70, and 30 gold just evaporated. You cannot have that bug against a number you never update. You only ever append a fact — "reserved 50 for this bid" — and the balance is whatever the facts add up to. Every coin is traceable to a row.

Letting the database serialize the race

The bids are where concurrency gets real. A new bid has to be at least 5% above the current highest, and the bidder has to actually have the funds. Both checks are meaningless if another bid lands between the read and the write.

So the transaction takes a row lock on the auction before it reads anything:

SELECT ... FROM auctions WHERE id = $1 FOR UPDATE;

FOR UPDATE makes Postgres serialize every bid on that one auction. The second bidder simply waits — inside the database, holding a real lock — until the first transaction commits or rolls back. By the time they read the highest bid, it's the truth, not a stale snapshot. The 5% rule and the funds check are evaluated against reality and can't be undercut by a concurrent writer.

The same pattern guards a buyer's wallet: lock the guild row, then check available funds and the daily spend cap. No two purchases can both believe the same gold is available.

This is a deliberate trade. Bids on a single auction now run one at a time, so a wildly hot auction is a throughput hotspot. I kept it anyway and wrote the trade-off down: it's per-row, so different auctions still run fully in parallel, and I'd take "slower but always correct" over "fast and occasionally wrong" with money every single time. Consistency first; throughput is an optimization you can do later with a clear conscience.

The bug the tests caught (and what it taught me)

I wrapped the database calls in a circuit breaker, and my first version counted business rejections — "bid too low", "insufficient funds" — as breaker failures. A burst of perfectly valid rejections tripped the breaker, and the next legitimate request got a 500.

The end-to-end tests caught it immediately: a buy that should have returned 200 came back 500. The fix was a one-line distinction — only real infrastructure faults (a failed begin or commit) trip the breaker; a rolled-back business rule counts as a success, because the system did exactly what it should. The transaction had already protected the data. The breaker just had the wrong opinion about what "failure" means.

The takeaway

The lesson I keep relearning: the database is not just where data rests, it's a correctness engine, and most of the time it's a better one than the code you'd write to replace it.

ACID transactions gave me atomicity for free — debit the buyer, credit the seller, transfer the item, all or nothing. Row-level locking gave me serialization exactly where conflicts happen and nowhere else. An append-only ledger made an entire category of bug structurally impossible.

I wrote less concurrency code, not more. The hard part — making races safe — I handed to the system designed for it. That's not laziness. On anything that touches money, it's the most senior decision in the whole project.

The code, the migrations, and the end-to-end tests are all here: github.com/jeyem/dragon-market.

Originally published at e-mahmoudi.me. I write about blockchain, backend, and software architecture — more at e-mahmoudi.me.

I Built a Liquidity Sniper Bot for BNB Chain, and It Proved a Losing Game

Ehsan Mahmoudi — Mon, 24 Aug 2026 08:43:27 +0000

📌 Originally published at e-mahmoudi.me

I Built a Liquidity Sniper Bot for BNB Chain, and It Proved a Losing Game

I built a crypto trading bot.

Not to get rich. I went in fairly sure that "easy money" bots are mostly a fantasy.

I built it to find out for myself, with code, with real money, with data instead of opinions.

And it gave me a clean answer.

The bot works flawlessly. The market is the problem.
The tokens that survive every defense you build are the ones engineered to survive every defense you build, and then trap you.

This is the story of that project: what it does, how I took it all the way to live trading, and the exact mechanism by which it lost. The engineering was the easy part. The honesty was the point.

The idea I started with (and why it was wrong)

My first instinct was the one almost everyone has: arbitrage.

A liquidity pool prices BNB against USDT by a simple formula. When the price drifts a little, buy low here, sell high there, pocket the difference. A fast bot should print money on those gaps, right?

It took very little reading to see why that is the hardest game in crypto, not the easiest:

Established pairs are efficiently priced. Any deviation is closed in the same block by professional MEV bots running on private mempools and co-located infrastructure. By the time a retail bot sees the gap in the public mempool, a second or two later, it is gone, and your transaction is visible to everyone, so you get front-run too.

Efficient markets have no retail edge. That edge was captured years ago by people with infrastructure and capital I can't match.

So I reasoned my way to the one corner that might still be inefficient:

Brand-new token launches have no price discovery yet. The gap between the launch price and where the market settles is the only mispricing a small bot could theoretically capture.

That is "sniping." And it led me straight into the most adversarial environment I have ever written software for.

What I built

I wrote it in Go, as a clean, staged pipeline. The shape matters, because each stage is a defense, and the story is really about defenses being defeated one by one.

WebSocket (PairCreated event)
   -> listener     receive raw logs
   -> pipeline     a funnel of gates, cheap to expensive:
        decode -> reserve -> token -> score -> lp/pre-arm -> honeypot -> output -> trade
   -> monitor      track each position, run the exit strategy, execute sells
   -> executor     sign and submit real swaps (live mode)
   -> store        SQLite record of every position and sell

A few pieces I am genuinely proud of as engineering:

A pure-Go honeypot simulator. Before buying, it runs a full buy-then-sell round trip against the real token using eth_simulateV1: one RPC call, state carried between calls, a fabricated wallet funded by overriding a storage slot. If the simulated sell reverts, it is a honeypot, and we never touch it. No deployed helper contract, no Solidity.
AMM-accurate paper trading. The sandbox prices fills along the real constant-product curve, so a rugged pool fills near zero. Paper P&L cannot hide a loss the way naive backtests do, which turned out to matter enormously.
A real on-chain executor. Encrypted keystore wallet (passphrase from the environment, never disk), a capital ledger that gates buys on balance plus a gas reserve, real V2 swaps that measure tokens received from the actual balanceOf delta, a deployer blocklist that learns from rugs, and restart-liquidation so a crash never strands a position.
Chain and DEX general. Router, wrapped-native, chain id, and fees all come from config. The same binary runs any Uniswap-V2-style DEX on any EVM chain.

It is a complete, working system. That is important, because it means when it lost, it was not losing because of a bug.

Then I did the thing most people don't: I went live

Paper trading looked great. In the sandbox, most tokens showed a profit.

I almost stopped there. I am glad I didn't, because the gap between paper and live is the first real lesson:

Paper exits are instant, free, and never fail. Live exits are a transaction that takes about three seconds to mine, into a market that is actively trying to trap you. Paper profitability does not transfer to live for this strategy.

So I funded a throwaway wallet with a few dollars, set the trade size tiny (about $0.60 a pop), flipped the safety switch off, and let it run for real.

Here is exactly what happened, defense by defense.

The field report

The bot, at each stage	What real money did	Verdict
Detection plus honeypot sim	12 of 12 losses, -83%. Every token went flat, then rugged in 10 to 18 seconds.	rugs dominate
plus LP lock/burn check	One whole night: 0 buys. 66 launches skipped for unlocked liquidity.	the safe ones are rare
plus recursive pre-arm	Finally fired buys, on confirmed-locked, sim-passing tokens.	the strategy functions
The result of those buys	4 tokens passed everything, the buys worked, prices even rose, then every sell reverted.	-100% each

Let me unpack the two findings that actually matter.

Finding 1: a rug is not a price crash

The first run was carnage. Twelve trades, twelve losses. I added an exit strategy with a stop-loss and a trailing stop, and it did not help at all. Why?

Because a rug pull is not a price movement. The deployer does not sell the token down; they call removeLiquidity and pull the entire pool in one transaction. The price ratio barely moves, so a stop-loss watching price never triggers. One block there is liquidity; the next block the pool is empty and your tokens are unsellable.

You cannot out-exit a rug. There is nothing to sell into. The only defense is to never enter, which means proving the liquidity is locked before you buy.

So I built that. The pair contract is the liquidity token; if enough of its supply sits in a burn address or a known locker, the deployer can't pull it. I made the check recursive: it polls for a window and buys the instant a token proves it is locked.

That stopped the rugs cold. An entire night with zero losses, because it correctly refused every ruggable launch.

It also revealed Finding 2.

Finding 2: the survivors are engineered to be traps

When the bot finally bought tokens that had locked their liquidity and passed the honeypot simulation, four of them did something I will never forget:

14:05  BUY VIT      (passed LP lock + honeypot sim, real buy succeeded)
14:08  VIT +16.7%   (it went UP, sellable a moment ago)
14:08  SELL reverts. retry. reverts. x5. unsellable. -100%.

Same for three others, all dressed as fake stablecoins (USDM, PUSD, USDTR) to look legitimate.

These are switchable honeypots, and they are beautiful, evil engineering:

The token is genuinely sellable at the instant the simulator checks it, so it passes. The bot buys. The deployer lets bots accumulate for a few minutes, then flips a switch (setMaxSell(0), a blacklist, a pause) and freezes every buyer.

A honeypot simulation is a point-in-time check. It cannot see a future state change. There is no pre-buy filter for "the deployer will disable sells three minutes from now," because that information does not exist when you have to decide.

The structural conclusion

After all of it, BSC launches sort into exactly three buckets:

Token type	My defense	Outcome
no liquidity lock	LP check	skipped
static honeypot	sell simulation	skipped
switchable honeypot	none possible	-100%

And here is the part that makes it unwinnable, not just hard:

The tokens that survive your funnel are precisely the ones built to survive your funnel. Every filter you add does not reduce your losses, it selects for a more sophisticated adversary. You are not fighting bad luck. You are fighting someone who adapts to your exact defenses and keeps the timing advantage.

Total cost of learning this, for real, on-chain, with data I can point to: about $10. The entire "buy my sniper bot" industry is built on never telling you this.

What I actually took away

The losses were tiny. The lessons were not.

On engineering. This is the kind of project I value most: the one where I did not already know the domain (MEV, AMM math, eth_simulateV1, honeypot mechanics) and had to decompose it fast enough to build something real. The bot is genuinely good: a clean staged pipeline, honest AMM-accurate accounting, a full live-execution engine, chain-agnostic by config. None of that was the hard part.

Engineering is rarely about already knowing the technology. It is about decomposing an unfamiliar, adversarial system fast enough to get a true answer out of it.

On markets. Both ends of what I tried are losing games for retail, for opposite reasons. Efficient markets (arbitrage) have no edge, taken by faster, richer players. Inefficient markets (new launches) have an edge that exists because the place is a minefield. The scams live exactly where the only opportunity is. There is no permissionless venue that is both active and clean. That is not a config you can find, it is the structure of the thing.

On honesty. I could have stopped at the green paper-trading numbers and written a very different, much more flattering post. The whole point was to not do that. I built an instrument precise enough to tell me the truth, and then I believed it.

A bot that loses $10 and hands you a correct, hard-won conclusion is worth more than one that shows you a fake profit chart and quietly drains your wallet.

I am calling this project finished. It did exactly what I built it to do: it answered the question honestly.

The code is a complete, working liquidity sniper. The result is a clear "no." Both of those are, to me, a success.

The full source is open (GPL-3.0): github.com/jeyem/lqsniper. Read the field report in the README, and please remember the disclaimer.

Originally published at e-mahmoudi.me. I write about blockchain, backend, and software architecture — more at e-mahmoudi.me.