A security scanner fails in two directions, and both are silent:

• False negative — a green light on vulnerable code. The worst outcome, because it manufactures confidence. You ran the tool, it said clean, you shipped the reentrancy.
• False positive — a red flag on safe code. Less dangerous but corrosive: enough of them and people stop reading the output, which converts every real finding into a false negative by way of fatigue.

So the interesting phase of building this wasn’t the detectors. It was handing the finished detectors to a different, stronger model — one that hadn’t written them and had no stake in them looking good — with a single instruction: construct the contracts these miss, and the safe ones they wrongly flag.

What it found

The detectors were heuristics — regex and brace-counting over source, no compiler, no AST — and heuristics break on structure. The auditor found exactly where:

• A function’s returns (bool) clause was being parsed into its modifier list. So a function that returned a value looked, to the access-control detector, like it had a guarding modifier — and its findings were suppressed. False negatives, by punctuation.
• receive() and fallback() weren’t being segmented as functions at all, so a selfdestruct sitting in a fallback was simply invisible.
• A nonReentrant modifier silenced unrelated checks, because the engine treated “has any modifier” as “is access-controlled.”
• On the other side: tx.origin passed to an event got flagged as phishable auth (it’s a log), and uint x = 5 got flagged as a reentrancy state-write (it’s a declaration). Crying wolf.

Each one became a regression fixture — a tiny contract that must trip the detector, or must not. The suite went from 29 tests to 46. And then I did the part the fleet can’t do for me: re-ran them myself, and pointed the CLI at a vulnerable fixture (one HIGH finding, correct line) and a clean one (no findings) to watch recall and precision with my own eyes.

The honest footer

scaudit is a first-pass triage aid. It has no control-flow graph, no taint analysis, no inheritance resolution; it reads one file at a time; its access-control detector is high-false-positive by nature. Slither compiles the contract and reasons over an IR; Mythril runs symbolic execution; real coverage is fuzzing and formal verification. I put all of that in the README in plain words, because a tool that overstates its reach is just a better-dressed false negative.

But the structure is the point worth keeping. The same agent workflow that built scaudit is, itself, this idea: a builder model and a separate, sharper auditor model that exists only to disbelieve it. The most useful thing you can do with a second model isn’t more output — it’s adversarial doubt aimed at the first one. Who audits the auditor? A different auditor, who was told to assume it’s lying.

The contract gets the genuinely hard part right. The part it left open is the one an arbitrage bot, of all things, should know about.

The hard part it got right

The dangerous surface of a flash-loan receiver is the callback. Aave hands control to your executeOperation in the middle of its own transaction, holding your borrowed funds. Two things have to be true or you’re drained:

require(msg.sender == address(POOL_CONTRACT), "caller not pool");
require(initiator == address(this),          "bad initiator");

The first stops anyone but Aave from calling the callback directly. The second is subtler and more important: without it, I could call flashLoanSimple and name your contract as the receiver, and Aave would dutifully invoke your executeOperation with my parameters — running your logic with attacker-chosen routers. Binding initiator == address(this) means the loan had to originate from this contract’s own executeArb. Both guards are there, and the repayment is enforced before any profit is swept. That’s the stuff that usually gets these contracts emptied, and it was correct.

The part it didn’t

The swaps had no slippage protection. Each leg just took whatever the router gave:

router.swapExactTokensForTokens(amountIn, 0, path, ...);  // amountOutMin = 0

Here’s why that’s the bug, and why it’s almost funny that it’s this contract: an arbitrage transaction sits in the public mempool announcing “I am about to do two profitable swaps.” A searcher reads it, front-runs to move the pool against you, lets your swaps execute at the worse price, and back-runs to collect. The contract built to harvest a price spread becomes the perfect victim of one — it broadcasts its intent and then accepts any fill. The arb bot is the sandwich filling.

And the minProfit check at the end doesn’t save you, which is the trap. Profit is measured after both swaps, so a sandwich that degrades each leg can still leave you above a loose minProfit while a searcher pockets the difference — or it pushes you to a tiny revert with nothing gained. You need a floor on each swap (amountOutMin) plus a deadline, not just a check on the final tally.

Who found it

I didn’t, on the first pass. The rebuild came out of a model-tiered agent workflow — one model writes the contract, a stronger one audits it before anything ships. The builder got the callback guards right and left the slippage at zero; the auditor flagged it medium-severity (“an arb with no amountOutMin is a free sandwich”), and the fix — per-leg minOut1/minOut2 and a deadline — went in with a regression test. Then I re-ran all 17 tests myself and read the callback by hand, because a green check from the fleet is a claim, not a result.

The contract, the mocks, and the tests are public. It’s tested against mock Aave and mock DEXes, not live ones — so it’s a faithful model of the strategy, not a deployed bot. But the lesson generalizes past flash loans: the protections you’re sure you don’t need are the ones for the attack your own code is designed around. An arb contract is a price-spread predator that forgot it trades in public.

The four processes and the handshake

op-reth     execution layer — runs the EVM, holds L2 state, serves eth_* RPC
op-node     consensus layer — derives the L2 chain from L1, drives block production
op-batcher  posts L2 transaction batches down to L1 (as blobs)
op-proposer posts L2 state roots to L1 (so withdrawals can be proven)

The handshake is the part worth internalizing. op-node doesn’t execute transactions; op-reth doesn’t decide what the chain is. They talk over the Engine API — the same engine_forkchoiceUpdated / engine_getPayload interface Ethereum L1 uses between its consensus and execution clients — and that interface is authenticated with a JWT secret the two share. op-node says “build a block on top of this head”; op-reth builds and executes it; op-node says “this is now canonical.” That’s the whole dance. Everything else — the batcher, the proposer — is about getting that L2 chain onto L1 so it inherits Ethereum’s security.

What “finishing it” actually meant

The deployment mostly existed. What it lacked was everything that makes infra trustworthy rather than just present:

• Every image was :latest. That’s a time bomb — docker compose pull six months apart gives you two different rollups, and one of them won’t boot. I pinned all six (op-reth, op-node, batcher, proposer, prometheus, grafana) to released, env-overridable tags tracking op-contracts v4.0.0.
• Genesis was a manual chore. The README said “generate genesis.json and rollup.json using the Optimism monorepo” — a clone-and-pray step. The modern answer is op-deployer: one tool that deploys the L1 contracts and emits both files. I wired it into a make config so the path from nothing to a configured chain is a single command.
• A real config bug. In replica mode, reth’s --rollup.sequencer-http defaulted to the node’s own op-node. A replica is supposed to forward transactions to the external sequencer; pointing it at itself is a quiet footgun. Fixed.

The part that caught bugs was CI, not me

Here’s the honest bit. I can’t run Docker in my environment, so I can’t boot the chain to prove it works — and I said so in the README, in a “what’s verified vs what needs Docker” section, rather than implying a green I didn’t earn. What I could do is make the repo verify itself: a make validate (script syntax, YAML, JSON) that runs anywhere, plus a CI workflow that adds shellcheck, yamllint, and crucially docker compose config on GitHub’s runners.

And the first thing CI did was fail — on my own scripts. shellcheck flagged the validation script I’d just written: an unguarded cd, a loop that could only run once, an unchecked source. bash -n had passed them happily; shellcheck didn’t. I fixed the three, pushed, and watched docker compose config validate the pinned compose file on a machine that actually had Docker — the one check I couldn’t run myself, now green.

That’s the whole reason to wire up CI on an infra repo you can’t fully exercise locally: it runs the checks your laptop can’t, and it has no investment in your code being correct. The finalized deployment boots a reth-powered OP Stack L2 in replica or sequencer mode; the green check next to it is the part I didn’t have to take on faith.

The thing is, it shipped. It got rebranded to Artura Finance and it’s live. So the protocol still exists as documentation, even though my copy of the code doesn’t. That’s enough to rebuild from — if you read the docs for the one thing that actually defines a perps DEX: who is the counterparty?

The docs tell you who the house is

Artura’s marketing says “inspired by Hyperliquid.” Its mechanics say something much more specific. The liquidation rule is “you’re liquidated once you’ve lost 90% of your collateral.” The fees mention a “borrowing fee that goes into the vault.” LPs “earn from trader losses.” There’s a single vault, and traders trade against it.

That’s not an orderbook and it’s not an AMM. That’s the Gains Network / gTrade pool model: a single stablecoin vault is the sole counterparty to every trade. There’s no other trader on the other side of your long — there’s the LP pool, and it takes the opposite side of everything. When you win, the pool pays you. When you lose, the pool keeps it. The “earn” page in my old frontend wasn’t a staking gimmick; it was people funding the house.

Once you know that, the whole protocol falls out of it.

The rebuild

Three contracts, in Foundry:

• ArturaVault — the LP vault, an ERC-20 share token (the “gToken”). Deposit the stablecoin, get pro-rata shares. Trader profit is paid out of here; trader losses and fees flow in. Share price is just totalAssets / supply, so it tracks net trader PnL exactly — and the vault can never pay out more than it holds (in the real protocol a backstop token mints to recapitalize; I left that as a documented seam).
• ArturaPerps — open/close leveraged longs and shorts against the vault. PnL is collateral · leverage · (mark − entry) / entry, priced off an oracle. A borrowing fee accrues over time to the vault. Liquidation is permissionless once equity drops to 10% of collateral — the gTrade signature.
• PriceFeed — keeper-pushed mark prices with a staleness guard. Artura’s docs don’t actually specify an on-chain staleness bound; I added one, because settling a trade on a stale price is how these get drained.

The one number I could check against reality: Artura’s docs give a worked liquidation example — a 100× BTC long at $20,000 with $50 collateral liquidates at $19,824. My liquidationPrice view, with the same inputs and zero fees, returns $19,820; the $4 is their $1 borrowing-fee term. That’s a test. Nine of them pass: long and short PnL settled against the vault (LP NAV moving the right way each time), the liquidation threshold, the borrowing fee, the caps, the stale-oracle revert, and the solvency floor.

What the docs don’t make you honest about

This is the core money model, faithfully rebuilt and tested — not the whole of Artura. The backstop token that recapitalizes the vault, limit/stop orders, the OI-skew borrowing curve, referrals: all documented seams, none built. I wrote that down in the README rather than letting “rebuilt the perps DEX” imply more than nine tests’ worth of protocol.

But the lesson that made the rebuild possible is the same one from the index fund that held the wrong asset and the bridge that paid twice: in DeFi, the design is the answer to one question about where the value sits. For a perps DEX that question is “who’s the counterparty,” and once the docs answered it — the LPs are — there was nothing left to guess.

Contracts, tests, and the recovered frontend: github.com/0xSoftBoi/blastperps.

So I knew the what. The question was how to build it well, and I wanted to try something: instead of writing it all myself on one model, run a fleet — and be deliberate about which Claude model does which job.

The seating chart

The models aren’t interchangeable, and the price difference is real (Opus output is 5× Sonnet, which is 5× Haiku). The skill is matching the model to the kind of thinking the task needs:

• Opus 4.8 sits in the seats where being wrong is expensive and being thorough pays: research, architecture, and the security audit. Opus is meaningfully better at finding bugs — higher recall and precision — so it’s wasted on boilerplate and indispensable on review.
• Sonnet 4.6 is the builder. Implementation and fixes from a clear spec — strong, fast, and the right call when the design decisions are already made.
• Haiku 4.5 does the scaffolding — the Foundry project, the Next.js skeleton, the config. Mechanical, high-volume, no judgment required. Cheap on purpose.

What got built

A real missions/rewards layer, not a toy:

• RewardToken — IMPACT, the ERC-20 community reward. Minting is owner-only and the Missions contract holds no minter rights, so a bug in the protocol can’t inflate the supply.
• Missions — the escrow. A creator funds a mission with a capped reward pool. A user claims exactly once, and only with an EIP-712 attestation signed by a trusted off-chain verifier (you did the mission). The claim is replay-proof per (mission, user), the pool can’t be over-claimed or siphoned across missions, it’s nonReentrant with checks-effects-interactions, and there’s an attestation epoch so the admin can revoke outstanding signatures.

The bug the auditor caught the builder writing

Here’s the part that justifies the seating chart. Sonnet built the contracts and 26 passing tests. Then Opus audited them, with one instruction that matters: report everything, including low-severity and uncertain — don’t filter. (Tell Opus to “only report high-severity issues” and it obeys you literally, and recall drops.)

It found four real things the builder hadn’t:

1. missionId squatting — creators chose their own mission IDs, so one creator could grief another by pre-claiming an ID. Fix: a cancel cooldown plus delete so IDs free up correctly.
2. Single-step Ownable on the attestor key — the key that authorizes every payout. A fat-fingered transferOwnership loses it forever. Fix: Ownable2Step.
3. Pre-signable, never-expiring attestations — an attestor could sign for a mission before it existed, with an unbounded deadline. Fix: the epoch mechanism.
4. A missing zero-address guard in claim.

It also did the opposite of finding bugs: a careful, affirmative proof that double-claim, signature forgery, malleability (OZ’s ECDSA reverts on high-s), cross-chain and cross-mission replay, pool drain, and reentrancy were actually closed — citing the lines. That’s the half of an audit people skip: saying what you checked and why it holds.

Sonnet then applied every fix with a regression test apiece. 26 tests became 34.

I re-ran them anyway

A workflow telling me “34/34 green” is a claim, not a result. So before any of it shipped I re-ran forge test myself (34/34, confirmed), read the claim path line by line to check the safety properties were real rather than asserted, and secret-scanned the repo before flipping it public. The fleet does the work; the verification is still mine to own.

The contracts, the 34 tests, and the frontend scaffold are at github.com/0xSoftBoi/socialstack. The whole thing — research to audited, tested protocol — was one workflow. The trick wasn’t the agents. It was putting the careful model in the careful seat.

It is also insolvent the moment any price moves, and the reason is the first thing you should check in any fund: does it actually hold what it says it holds?

It holds SUI. It pays a basket.

Here’s the withdraw, trimmed:

// value the token's NOTIONAL basket at current oracle prices...
let total_usd_value = btc_usd + eth_usd + xrp_usd + ada_usd + matic_usd;
let total_sui = ((total_usd_value / adjusted_sui_usd_price) as u64);
// ...and pay that many SUI out of the shared pool
let index_token_balance = balance::split(&mut index_fund.balance, total_sui);

Deposit only ever added SUI to index_fund.balance. The contract never bought a single satoshi of BTC — the basket is a number in a struct. So when BTC goes up, your token is “worth” more SUI, and withdraw pays it to you out of the common pool, which is just everyone else’s SUI.

Play it forward with two depositors. Both put in 1,000 SUI; the pool holds 2,000. BTC rallies. Alice withdraws first: her token now values at, say, 1,400 SUI, so balance::split hands her 1,400 and leaves 600. Bob withdraws: his token also values at 1,400, balance::split(&mut pool, 1400) against a 600 balance — abort. Bob’s money is stuck. It’s a bank run, except the run is triggered by a green candle and the loser is whoever clicks second. (There’s tangled decimal math and no oracle-staleness check on top, but the insolvency is the one that empties wallets.)

Fix it by only ever paying what you hold

The solvent rebuild is a pro-rata share fund. Deposit mints shares proportional to the pool; withdraw returns pool * shares / total_shares SUI. That quantity is always ≤ the pool — so balance::split can never abort, and the fund can never owe SUI it doesn’t have. The oracle drops out of the money path entirely and becomes an informational USD NAV view (now with the staleness check the original skipped). The headline test is just: two depositors, withdraw both — the second one succeeds instead of aborting. Five Move tests, green.

And here’s the honest part I put in the README: this solvent thing isn’t really an index fund anymore. It’s a SUI pool with a NAV readout. A real on-chain index fund has to actually custody the assets — swap the deposited SUI into wrapped BTC/ETH/… through a DEX so the basket exists on-chain. That’s the part the original skipped, and skipping it is the whole bug. You can’t pay out exposure you never bought.

It’s the same lesson as the fake dice game and the bridge that paid twice: the contract isn’t where these break. They break on a promise the contract makes about value it doesn’t actually hold — a roll it never reads, a release it never recorded, a basket it never bought. Read what the pool contains before you read what it claims to owe.

Audit, fix, and the five passing tests are at github.com/0xSoftBoi/01.

mapping(address => bool) public blacklists;

function blacklist(address _address, bool _isBlacklisting) external onlyOwner {
    blacklists[_address] = _isBlacklisting;
}

function _beforeTokenTransfer(address from, address to, uint256 amount) override internal {
    require(!blacklists[to] && !blacklists[from], "Blacklisted");
    ...
}

Every transfer runs _beforeTokenTransfer first. So the moment the owner calls blacklist(you, true), every transfer touching your address reverts. You can’t sell. You can’t move it to another wallet. You can’t even receive more. Your bag is frozen, on-chain, at the deployer’s discretion. You buy at the top, they flip the switch, and the exit is gone. That’s a honeypot — and it’s not hidden in assembly or a proxy, it’s eleven lines of plain Solidity.

There are two more levers in the same contract:

// in _beforeTokenTransfer:
if (uniswapV2Pair == address(0)) {
    require(from == owner() || to == owner(), "trading is not started");
    return;
}
if (limited && from == uniswapV2Pair) {
    require(balanceOf(to) + amount <= maxHoldingAmount && ... >= minHoldingAmount, "Forbid");
}

The first means that until the owner sets the pair, only the owner can move tokens — they decide if and when trading ever opens, and can simply never open it. The second lets setRule(...) cap how much anyone can buy, down to zero. Mint 100% of supply to yourself, retain ownership, and you hold every lever.

Proving it, and the antidote

I didn’t want to just assert this, so I wrote three Foundry tests against the real DarkPepe bytecode. One buys in as a holder, has the owner blacklist them, and asserts the next sell reverts with "Blacklisted" — and that they can no longer receive either. One shows that before trading is “started,” a non-owner transfer reverts. They pass. The honeypot is exactly as advertised.

Then the antidote, also tested: SafeToken — a deliberately un-ruggable ERC-20. Fixed supply minted once, no owner, no blacklist, no transfer gate, no mint, no holding caps. There is no function any party can call to freeze or seize a balance, so the test that tries to trap a holder has nothing to call. That’s the whole point: safety here isn’t a feature you add, it’s privilege you remove.

The takeaway

This is the most actionable post I’ll write, so here it is plainly: before you ape a token, read two things — its _beforeTokenTransfer / _update hook, and every onlyOwner function. A blacklists mapping, a tradingEnabled flag, a setRule that gates the pair, a _mint the owner can still call — any one of them means the deployer can stop you selling or dilute you at will. The contract will look friendly and trade fine right up until it doesn’t. The exit being open today doesn’t mean it’s open tomorrow if someone else holds the key.

The audit, the proofs, and the trap-free reference are at github.com/0xSoftBoi/01.

sepoliaBridge.on("Deposit", async (depositor, amount) => {
  await mumbaiBridge.release(depositor, amount);
});

Lock tokens on Sepolia, the bot sees the Deposit event, releases the same amount on Mumbai. And the destination release is exactly what you’d expect:

function release(address _to, uint256 _amount) public onlyOwner {
    IERC20(token).transfer(_to, _amount);
}

It works in the demo. It is also a contract that will pay you twice.

Events are not exactly-once

The bug is the unspoken assumption that each Deposit fires once and is handled once. Neither is guaranteed:

• The relayer restarts and replays recent blocks — same event again.
• The websocket reconnects and re-emits buffered logs — same event again.
• The source chain reorgs: the block with your Deposit gets re-mined, the subscription re-delivers it — same event again. (And in a reorg the original deposit may no longer exist at all.)

Each re-delivery calls release again, and the destination has no memory of what it already paid — no nonce, no record, nothing. So it transfers again. And again. The reserve drains one duplicate at a time, and there’s not even a Released event to notice it happening. This isn’t exotic; “the off-chain component double-submitted” is one of the most common ways real bridges have lost money.

Making a payout happen once

The fix is to give every payout an identity and remember it:

• Each destination release is keyed by a transferId derived from the unique source lock — srcChainId, srcBridge, srcNonce, to, amount — plus the destination chain id and this contract’s address. mapping(bytes32 => bool) processed means the second release for the same id reverts with AlreadyReleased. Re-deliver the event all you like; it pays once.
• The release carries a validator signature over that transferId, so authority to pay is explicit and verifiable, decoupled from the contract owner — and because the chain ids and both bridge addresses are baked into the id, a signature can’t be replayed onto another deployment.
• SafeERC20, a Released event to reconcile against, Pausable, and a relayer that waits for source finality before signing. (Idempotency stops paying the same lock twice; finality stops paying for a lock a reorg erased — two different failures.)

Six Foundry tests, and the one that matters most just re-calls release with the same signature and asserts the second call reverts and the balance moved once.

What it still isn’t

I want to be precise about what this does and doesn’t buy, because “bridge” oversells. The hardening removes the mechanical ways to lose money — double-pays, unsafe transfers, unauthorized releases. It does not remove the trust: this is still a custodial bridge, and a compromised validator can sign a payout for a lock that never happened. The trust-minimized version replaces the signature with a light-client or Merkle proof of the source Locked event, so the destination verifies the lock instead of trusting a signer — that’s the real frontier, and it’s the line between this and a bridge you’d actually trust with size.

It’s the same shape as the other bridge I annotated: the cryptography and the Solidity are rarely where these break. The break is an off-chain assumption — here, “events happen once” — that the chain never promised to keep.

The audit and the fix are at github.com/0xSoftBoi/cross-evm-bridge.

Bug 1: the randomness is always zero

function RandomNumber() public returns(uint) {
    total_bets[msg.sender]++;
    uint random_number = uint(keccak256(abi.encodePacked(
        blockhash(block.number),
        total_bets[msg.sender]
    )));
    ...
}

blockhash(block.number) — the hash of the block currently executing — is always 0. The EVM only exposes the previous 256 block hashes; the current block isn’t mined yet, so it has no hash. So the “random” number collapses to keccak256(0, total_bets[msg.sender]) — a pure function of your own bet counter. You can compute every future roll you’ll ever get, off-chain, before you bet. It’s the same family as the SmartBillions lottery, which used a block hash that resolved to zero and got drained for ~400 ETH.

Bug 2: it never uses the roll anyway

That bug almost doesn’t matter, because of the second one:

function makeBet() public payable {
    uint bet_roll = RandomNumber();          // computed...
    uint bet_payout = bet_amount.div(2);     // ...and ignored
    require(bet_payout < address(this).balance, "...");
    user.transfer(bet_payout);
    emit betPlaced(bet_amount, bet_payout, bet_roll);
}

bet_roll is computed, emitted in an event for flavour, and never read. The payout is unconditionally half your stake. There is no win condition, no target, no comparison — you send x, you get x/2 back, every time. It’s not a dice game with bad randomness; it’s a guaranteed 50% drain with a random-number generator bolted on for decoration. The broken RNG is a red herring sitting on top of a contract that was never a game.

Building the one it pretended to be

So I built the real thing — Dice.sol. The starting constraint is the lesson of every randomness post I’ve written: there is no safe single-transaction randomness on the EVM. Anything you can read in the bet transaction, the bettor can read too. So you need a value that’s fixed before the bet and unknown until after it — commit-reveal.

The shape:

• The house commits keccak256(serverSeed) before any bet references it, so it can’t choose the seed after seeing the action.
• Each bet carries a player-chosen clientSeed. The roll is keccak256(serverSeed, clientSeed, betId) % 100 — the house can’t predict it without knowing the player’s seed, the player can’t predict it without the still-secret server seed, and neither can grind it.
• The roll decides: bet that it lands under a target, paid with a real house edge — a 50/50 bet pays 1.96×, not 2×. (The original couldn’t even charge an edge; it just kept half.)

The one residual is the house withholding a losing reveal — the last-revealer problem that haunts every commit-reveal scheme. claimRevealTimeout closes it: miss the deadline and every bet in the round pays as a win, so withholding is strictly worse for the house than just revealing. Plus the boring-but-load-bearing parts the original lacked entirely: a bankroll that reserves each open bet’s maximum loss (unbacked bets revert), pull-payment withdrawals, reentrancy guards. It’s seven Foundry tests, including one that confirms the outcome actually tracks the roll and one that pays the player when the house goes quiet.

The lesson

The funny thing about YungBet is that the headline bug — the always-zero randomness — is the less serious one. You could fix the RNG perfectly and the contract would still just take half your money, because it never looked at the roll. It’s the purest example of a pattern I keep running into: the cryptography is rarely where these things actually break. The break is in whether the outcome people are betting on is bound to the cryptography at all — the randomness, the proof, the roll. Here it wasn’t bound to anything. It was decoration on a coin-flip you always lose.

The audit and the rebuild are at github.com/0xSoftBoi/dice.

ICowVaultRelayer(cowRelayer).deposit(token, owner, amount);
ICowSettler(cowSettler).settle(orderUid);

Neither of those functions exists on mainnet. The contract was integrating with a CoW Protocol I’d imagined — and the tests passed because they mocked the imaginary interface. That’s the trap with on-chain integrations: “compiles + green against mocks” tells you nothing about whether you’re calling a real protocol. So here’s how CoW actually settles a trade, and the three things I had backwards.

Orders are intents, not swaps

On an AMM you submit a transaction that executes a swap against a pool. On CoW you sign an intent: “sell at most X of token A for at least Y of token B before time T.” You never execute anything. A signed order is just the GPv2Order.Data struct — tokens, amounts, limits, validTo, kind — and its EIP-712 digest is the order’s id.

Orders are collected over a short window into a batch. Then off-chain solvers compete for the right to settle the batch, each proposing a solution that routes the orders (matching them directly against each other where possible — “coincidence of wants” — and only hitting external AMMs for the remainder). The winning solver is the one that returns the most surplus to users, and only that solver calls:

function settle(IERC20[] tokens, uint256[] clearingPrices,
                GPv2Trade.Data[] trades, GPv2Interaction.Data[][3] interactions)
    external nonReentrant onlySolver;

Two things in that signature mattered for my bug. It’s onlySolver — an allow-listed, bonded set; a random contract cannot call settle. And it takes a clearingPrices array with one price per token: every order in the batch touching a given token settles at the same price. That uniform clearing price is the actual MEV-protection mechanism — within a batch, transaction ordering carries no value, so there’s no sandwich to run. (CoW settlement docs)

So my settle(orderUid) was wrong twice over: the real settle has a completely different shape, and my contract isn’t a solver and could never call it.

You approve the relayer, not the settlement contract

Here’s the subtle one. To trade on CoW you grant your ERC-20 allowance to the GPv2VaultRelayer (0xC92E…0110) — not to GPv2Settlement. Why a second contract? Because settle executes arbitrary interactions (calls into external liquidity). If your allowance pointed at the settlement contract, a malicious solver could craft an “interaction” that just calls transferFrom on your tokens. So CoW puts the allowance on a minimal relayer that only GPv2Settlement may call, and interactions to the relayer are forbidden. Funds can move only as part of a settlement that respects your signed order. (vault relayer docs)

My router approved the relayer and then reset the approval to zero in the same transaction, right after a synchronous deposit. But settlement is asynchronous — a solver fills your order minutes later. Resetting the allowance immediately would leave nothing for the relayer to pull when the fill actually happens. The approval has to persist. CoW’s own guidance is a single standing relayer approval.

A contract presigns; it doesn’t settle

If you can’t call settle, how does a contract place an order? CoW’s GPv2Signing mixin allows four schemes: an EOA’s EIP-712 or EthSign signature, a smart contract’s ERC-1271 isValidSignature, or PreSign — calling setPreSignature(orderUid, true) on-chain to flag an order as authorized. (GPv2Signing source)

That’s the hook my executor needed. Each slice is its own order (its own validTo window); when a slice comes due, the contract presigns that slice’s orderUid and leaves the rest to solvers. The whole fix was: approve the real relayer once, presign per slice, and delete the settle call entirely. The contract authorizes; the network settles. I also added a revokePresignature so cancelling can kill a presigned-but-unfilled slice — the honest caveat being that an in-flight slice stays fillable until its validTo otherwise.

Two ways to TWAP, and when to roll your own

The above is a self-hosted TWAP: your own keeper presigns slices on a timer. CoW also ships an official TWAP, and it’s worth knowing why it exists. It’s not a bespoke contract — it’s a conditional order on ComposableCoW. You register one order with a handler implementing getTradeableOrder(...); CoW’s watchtower calls that each block to get the part valid now and posts it, and the settlement contract calls the handler’s verify(...) through ERC-1271 so a solver can only ever fill the part the handler currently authorizes. That’s validated discretization — the chain itself enforces the schedule — plus on-chain cancellation and a keeper you don’t have to run.

A naive splitter gives all of that up: it trusts your off-chain service to presign the right thing, and any already-presigned part stays fillable until it expires. So I built both — a fixed CowTwapExecutor and a faithful ComposableCoW IConditionalOrder TWAP handler (part scheduling, span windows, the watchtower’s poll/abort signals, the validation guards) — to have the self-hosted path and the framework path side by side. The honest default is the framework; you roll your own only when you need logic the handler can’t express, and even then the right move is a new handler, not an off-chain loop.

The lesson

The contract compiled and its tests were green the whole time it was calling functions that don’t exist. Mocks test your code against your model of the protocol; they can’t tell you the model is fiction. The fix wasn’t really Solidity — it was reading the actual contracts until the shape of a real settlement (intent, relayer, presign, solver) replaced the shape I’d assumed. It’s the same theme as getting randomness right and binding a ZK proof: the hard part isn’t the code you write, it’s checking it against the system it actually has to live in.

The fix, the handler, and the 26 tests are in the repo.