Smart contracts and financial applications on Ethereum and the EVM, built so a mistake has a limit

A contract with one way out let attackers watch their own transactions fail

On a wallet-protection product I helped build for EVM wallets, each user's assets sat behind a minimal, audited Solidity contract that could do one thing: move the funds to a cold wallet the user owned. A service watched the mempool, decoded each pending transaction and checked its intent against limits the user had set. When one broke a limit, the service sent a counter-transaction with a slightly higher priority fee, so it executed first. The attacker saw a failed transaction, and the funds were already out of reach.

Because the contract did so little, the speed had to live in the service. I reworked its execution path, networking and decoding from about 1 second end to end to about 60 ms, about 3 ms of it processing, which greatly widened its coverage when an attack arrived late in a block. The same design later had to work with MPC and multisig wallets.

Creators deployed their own mint contracts, and the platform never held their keys

I built the Solidity contracts behind a platform that let artists and creators who do not code deploy their own EVM mint contracts, with whitelists, airdrops and pre-sales, and keep custody of them. The platform also handled their payments end to end.

Non-custodial design removes a whole category of risk, because there is no key of yours to steal, and it costs a more careful user experience. Where your application does hold keys, the design has to say where they live, who can use them, and what happens when one is lost or exposed.

What I would tell your team before it writes a contract

I have also shipped cross-chain EVM contracts and bridges for a proof-of-work chain I founded, a project that passed third-party security audits. Across all of it, the advice is the same.

Decide first what the contract must never do, and make that its whole job. Anything that has to be fast, or may need changing, belongs off-chain.

Say which side is authoritative at each step where your services and the chain can disagree. A transaction your service sent is not yet a state: record what you signed before you broadcast it, rebroadcast the same signed transaction after a timeout rather than signing a second, and never count an approval as the trade or payment it was meant to allow.

Test every retry and fallback against the guarantee the user agreed to, such as a minimum output, and not only against whether it succeeded. Before anything is sent, simulate the whole approve-and-execute sequence on pinned chain state, and check the balance the wallet actually received rather than the estimate.

One engagement covers the contract and everything around it

The first step is a workflow review: I look at how your team ships, what my software factory can take on, and any security issues I find along the way. You leave with a plan either way.

From there the factory does the volume, I review what it produces, and you approve what your process asks you to approve, with no constant meetings.

If you have a contract heading for deployment, start with a workflow review before it ships.