DEV Community: Carlos | Zealynx

Your agent's payment approval can pass at any price

Carlos | Zealynx — Thu, 05 Nov 2026 14:16:47 +0000

On Saturday morning I was reading a draft standard for human approvals in MCP, the Human Gateway SEP from the HATP project. The idea is a good one. Before an agent runs a tool that matters, the right person signs off, and the tool server can check that signature offline without trusting the agent or the client.

The approval is a signature over a digest of the action: the server, the tool and the arguments. The example in the spec is a charge_card call, and it works because the amount and the payee are arguments. Bob approved this payment, to this payee, for this amount.

Then I tried it with a paid tool. In x402 over MCP the price isn't an argument. The agent calls the tool, the server answers with an error result carrying its terms (amount in atomic units, token contract, network, payTo), and the agent calls again with the same arguments plus a signed payment in params._meta["x402/payment"]. The digest is the same for both calls. So the approval passes at any price and any payee, and the person approving never sees either.

I opened an issue on 31 October and the maintainer shipped a fix in release 0.1.4 three days later. The same gap is easy to have anywhere a human approval sits in front of an agent payment, so this is what I'd compare in yours.

Last week I wrote about where agent payment designs trust the wrong thing and put up a full checklist. This one is only about the approval step.

The key signs more than the person approves

On EVM chains the x402 exact scheme pays with an EIP-3009 transferWithAuthorization. The agent signs typed data with from, to, value, validAfter, validBefore and a nonce, and the EIP-712 domain carries the chain ID and the token contract. So the payment signature is bound to the payee, the amount, the token, the chain and a time window.

The approval in front of it usually covers less, and it's the only part a person looks at. So put the two next to each other, field by field. Anything the key signs that the approval doesn't cover is something the server or the agent gets to pick.

Amount and payee have to be in what gets approved

The fix adds an optional payment member to the approved action:

"payment": {
  "network": "eip155:8453",
  "asset": "eip155:8453/erc20:0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
  "maxAmount": "2500000",
  "payTo": "0x9a3f…"
}

It's inside the digest and it's shown in the ask, so the person sees 2.50 USDC on Base to that address instead of "premium_report, ticker ACME".

I'd copy two details from it. The amount is in atomic units of a named asset. A { "value": 2.5, "currency": "USD" } field can't tell USDC on Base from a token with the same symbol on another chain, and a CAIP-19 asset ID can. And it's a maximum, not an exact price, so "up to $5" is the same check with a bigger number.

The payee can't be the one checking

In the first version the gated server verified the approval. That makes sense when the agent and the client are the parties being supervised. For a paid tool, though, the server is also the payee, and a check that only the payee runs doesn't protect the payer.

So in 0.1.4 the payer's client or wallet compares the server's terms with the approved payment before it signs: same network, same asset, same payTo, and an amount no higher than maxAmount. If anything differs, it doesn't sign and asks for a new approval with the new terms. The server still checks too, but that catches honest mismatches, not a server that wants more.

The server side has its mirror image. An x402 server should check the payment against its own price list, not against the copy of the terms the client sends back in accepted. The stock x402 server compares the two. A hand-rolled one that forwards the client's accepted to the facilitator lets the client set its own price, and the facilitator will happily confirm it.

The window is the field I rarely see on an approval screen

The x402 client doesn't choose how long its payment signature stays valid. The stock clients set validBefore to now plus the maxTimeoutSeconds from the server's terms (I checked the TypeScript, Python and Go clients in the x402 repo). A server that asks for 604800 gets a signature it can settle for a week.

The approval has its own expiry, HATP's is expiresAt, but that's when the approval stops being accepted. It says nothing about how long the payment it led to can be settled. The amount doesn't change, but the server can hold the signed payment and settle it days after the person who approved it changed their mind.

HATP's payment member doesn't carry a window yet, so this is the one field from the signature the approval still doesn't cover. A maximum window, checked next to maxAmount before signing, would close it.

A limit per payment isn't a limit in total

Standing approvals ("let the agent pay for this tool this week") are what people ask for next, and a per-payment cap doesn't bound them. 2.50 USDC a call is 250 USDC after a hundred calls, and an agent in a retry loop can make a hundred calls in a minute.

The approval needs a running total, kept where the payments are signed. The SEP now says that for standing approvals, and I'd ask the same of any wallet guard: does it count, or does it only look at one payment at a time?

The fee is part of the price

This one isn't x402. Earlier this week I looked at an ERC-4337 smart account where the owner sets per-call caps and a budget, and an agent holds a session key. The caps covered the calls the key could make. But the session key also signs the gas fields of the user operation (maxFeePerGas, maxPriorityFeePerGas, preVerificationGas), and the fee goes to whoever bundles it. Someone holding a leaked key can bundle one allowed operation themselves at an absurd gas price and take most of the account's ETH as the fee, inside every cap.

A cap on the gas fields in validation closes it.

Approve once, pay once

x402 turns a paid call into two tools/call requests with the same arguments. HATP approvals carry a single-use nonce, and the first version didn't say when the server records it. If it records it on the first call, the one it answers with its price, the paid retry comes back as a replay and gets refused. That's not a hole, but it's the kind of bug that gets a check switched off in a hurry. The fix says a nonce is consumed only when the tool actually runs.

The opposite mistake is worse: a nonce that's never consumed lets one approval pay for many calls. Test both. The retry goes through once, and a third call with the same approval doesn't.

Field by field

What the key signs	What the approval should cover	Checked where
`to`	`payTo`	payer's client or wallet
`value`	`maxAmount` in atomic units, plus a running total for standing approvals	payer's client or wallet
token contract (EIP-712 domain)	CAIP-19 asset	payer's client or wallet
chain ID (EIP-712 domain)	CAIP-2 network	payer's client or wallet
`validBefore`	a maximum window	payer's client (not in HATP yet)
gas fields (ERC-4337)	a gas cap	the account's validation

The quickest test I know for your own setup: approve a call, then have your test server raise its price on the retry. If the payment still gets signed, the approval doesn't cover the price.

I first wrote a short version of this on X.

I wrote this with help from AI for drafting and editing. The opinions and the review experience are mine.

Still building? The design questions worth settling before anyone scopes an audit

Carlos | Zealynx — Tue, 03 Nov 2026 14:22:01 +0000

A lot of teams write to an auditor while the code still changes every few days. The honest answer then is that nobody can give you a real scope yet. An audit reviews one commit, inside a scope, for a fixed number of days, and none of those three are stable while you're still building.

But that doesn't mean there's nothing to do until the freeze. Many of the serious findings in an audit aren't typos in the code. They're decisions: an admin key that can do more than anyone intended, a pause that also blocks withdrawals, an external call whose return value nobody thought about. Those get decided early, often in a few minutes, and by the time an auditor reads the code they're already in the storage layout and the tests.

This month I answered a few builders on public forums who were asking exactly these questions before shipping. Three of the threads show it well.

A chain deciding who it trusts, before there's a token

On the Polkadot forum, the builder of MADAR Network asked how to keep "one person, one vote" on their Polkadot SDK chain without collecting IDs. A 2-of-3 committee approves operators and runtime upgrades, and they were weighing a bond per operator.

Another forum member pointed out it's a Sybil and proof-of-personhood problem. I added that a bond can be slashed for equivocation, since double voting is provable onchain, but an operator who just stops voting has signed nothing you can slash. The unbonding delay also has to be longer than the window to report equivocation. And two of the three committee keys could admit their own operators and push an upgrade, so separate keys plus a delay on upgrades closes most of it.

Their answer: they're still on public testnet with no token, so this goes into the design before mainnet instead of being added later.

A private payments vault that changed its redeem function

On the Celo forum, a solo developer started building Envelope in public: tokens locked in a vault, a transferable NFT as the claim ticket, and a zero-knowledge redeem with a nullifier.

I asked who is really allowed to redeem, because a design that needs both the NFT and a secret lets the two drift apart once the NFT is sold, and whether the recipient and the relayer fee were bound into the proof, so nobody can copy a valid proof from the mempool. A wallet team asked what happens when a user loses the note data.

The planned contract changed. Redeem will burn the NFT in the same transaction as the proof, a holder's signature will let a relayer submit it so a fresh address needs no gas, and losing the note means losing the funds, so the app has to say that up front. Each of those touches a function signature or a storage layout. Cheap in month one of a four-month build.

An approval flow that couldn't say who approved

On the LangChain forum, a developer building an approval flow on LangGraph noticed that the record shows someone resumed the paused graph, not who.

Besides the identity part, I pointed at a second gap: the paused step runs again from the top on resume, so if the state changes in between, what executes can differ from what the approver saw. Put a hash of the proposed action in the pause and refuse to execute on a mismatch.

For any agent that can spend or call tools, "who approved what" is a design decision. It's much easier to make before the flow has users.

What to write down once the design settles

Item	What it contains
System overview	One page: what it does, main flows, contracts or components
Assets and trust boundaries	What holds value, and every place your code trusts something it doesn't control
Privileged actions	Every role, what it can do, what it can't, who holds it, which delays apply
Assumptions and dependencies	External contracts with addresses and versions, compiler and library versions, evidence for each assumption
Test history	What's covered, which invariants are checked, what's known to be untested
Open questions	The ones you know are still open
Launch window	When, and what's fixed about that date
Frozen commit	Last, when the code stops moving

Feedback is not an audit

A forum thread or a review call can change a design, and that's worth a lot. It doesn't read the code you deploy and it certifies nothing. Your tests prove what they test. Audit readiness means a reviewer can start on a fixed commit. An independent audit tells you what qualified people found in that commit, within that scope and time, and nothing about later commits.

One thing to do today

Pick the one assumption your protocol depends on most that no test checks today. "The committee will never collude." "The lending market never pauses withdrawals." "The agent can't sign above the cap." Write it down, and next to it write what evidence would show it holds.

If you can't think of the evidence, that's the design question to settle while you're still building.

Adapted from a piece our team published on zealynx.io, which also has three hypothetical worked examples (a vault, an external integration and an agent that spends) and the forum links.

I wrote this with help from AI for drafting and editing. The opinions and the review experience are mine.

An agent payment security checklist, from the payout address to the signer

Carlos | Zealynx — Sat, 31 Oct 2026 07:30:23 +0000

Yesterday I wrote up five AI agent payment designs I'd looked at in October: an x402 facilitator, a swap API for agents, an x402 test suite, a wallet guard and a banking agent. The payments worked in all five. The gap was always in something the payment path accepted without checking.

The day before that post went out, Binance lost about $2.5 billion from one hot wallet in under four minutes, through an EIP-7702 delegation signed by that wallet's own key.

So this is the full list I'd go through now before an agent is allowed to move money. Some of it repeats that post, most of it is new.

What happened to Binance 14

At 20:20:59 UTC an attacker sent one transaction carrying 50 EIP-7702 authorizations. Each was signed by the wallet Etherscan labels "Binance 14", each for a different consecutive nonce, all pointing the wallet at a sweeper contract. Ethereum used the one matching the wallet's next nonce. At 20:24 the first sweep took about 167,464 ETH and roughly 1.6 billion USDT. The wallet stayed delegated until 00:10, and deposits Binance kept routing into it were swept again at 21:04 and 21:44 (CoinDesk).

Binance says it found no evidence that private keys leaked. How the attacker got the 50 signatures was still under investigation when I checked on 31 October. That part shows up in checks 10, 11, 14 and 15.

1. Where the money goes (4 checks)

The strongest control sets the payout first. In the x402 facilitator, a merchant had to sign to change where their vault pays, but the operator deployed the vault and its first payout came from a dashboard setting. A leaked operator key could create vaults that pay someone else before any merchant signs. If the payout is written once at creation, a fix in the factory only covers new contracts, so go back through the old ones too.
Every contract address is pinned per chain in your config. The swap API added recipient and minimum-output checks, but took the bridge's deposit contract address from the same bridge API it was checking. A compromised API could list its own contract and every check would still pass. Alert when the API and your config disagree.
Calldata gets decoded before anyone signs it. If the agent signs calldata an API returned, that API is part of the agent's wallet. Check the target is on an allowlist, the recipient is the user and the minimum output matches the quote.
A smart wallet address means nothing on another chain. In 2022, 20 million OP sent to Wintermute's address on Optimism went to someone else, because their Safe existed on mainnet but not yet on Optimism and an attacker deployed one there first. Verify ERC-1271 signatures and smart wallet payouts on the chain where the money lands.

2. What a payment is bound to (4 checks)

Each payment is bound to amount, recipient, resource, token contract and network. A server that only checks that a settled payment exists serves whatever route the proof is presented to.
Substitution tests run in CI. A valid payment for a cheaper route, to another recipient, in another token or on a testnet has to fail against your most expensive mainnet route. The x402 test suite added all of these as checks.
One payment buys one response. Mark it as used atomically before the response goes out, or the same signed payment sent 20 times at once buys 20 responses.
Client spend limits pin the token and the network, not only the number. In x402 the 402 response tells the client which token contract and network to pay on, so an endpoint can keep the number the same and change the token.

3. What the agent's key can sign (4 checks)

You have a list of every signature the key can produce. Transactions, EIP-712 typed data, Permit and Permit2, plain messages and EIP-7702 authorizations. The wallet guard held unlimited approvals and Permits by default and still approved a type 4 transaction that delegated the whole account. Its author fixed it within three hours.
Keys that should never delegate refuse the authorization payload. An authorization is a signature over keccak256(0x05 || rlp([chain_id, address, nonce])), with no recipient and no amount in it, and chain_id 0 makes it valid everywhere. A hot wallet has no reason to sign one. A rule that only blocks type 4 transactions sent from your hot wallet wouldn't have fired at Binance, because the attacker sent the transaction and only the signatures came from Binance 14's key.
The signer decodes what it signs. An MPC policy engine or HSM that signs whatever 32-byte hash it's handed can't apply any policy. Have it build the hash itself from the decoded request.
The guard is the only way to the key. A client-side guard only sees what goes through the client it wraps. If the agent or another service can reach the raw key, the guard never sees the signature.

4. Watching the account (3 checks)

The wallet reads its own code before each send. A delegated account's eth_getCode returns 0xef0100 followed by the delegate's address. Stop if it points somewhere you don't expect. The wallet guard shipped this two days after I suggested it, with a list of expected delegates so teams that delegate on purpose don't have to turn it off.
Funds stop flowing into a wallet whose code changed. Whatever watches your hot wallets' balances can call eth_getCode every block too. It wouldn't have stopped Binance 14's first sweep, but it could have stopped deposits going in before 21:04 and 21:44.
The revoke is ready, and so is the nonce math. An authorization to address(0) clears a delegation. But authorizations signed for later nonces stay valid until the account's nonce passes them, and the Binance 14 transaction carried 50 of them. After a revoke, push the nonce past the highest one an attacker could hold, and if the signer itself is compromised, move the funds and retire the key.

5. What the model and the human see (2 checks)

The model writes no free text that leaves your system. Transfer notes, memos, email bodies, metadata. The banking agent kept the payee and amount out of the model's hands, but the model still wrote the transfer note, which lands with someone outside the bank. Let the customer fill it on the confirm screen.
The human approves what gets signed, rendered by code. Token contract, network, amount, recipient and expiry, built from the payload, not the agent's summary, on a screen outside the chat.

6. Operators, tools and logs (3 checks)

Operator keys that can set payouts are treated as treasury keys. Separate, monitored, rotated, and every payout they set raises an alert.
Read-only is enforced by the database role. dbhub's read-only mode (GHSA-mwwr-p57h-56pf) never reached the connection, so a SELECT calling a function with side effects could still write. And a read tool next to a tool that sends anything out can still leak what it reads.
Every payment decision is logged with its inputs. Which requirements, which quote, which upstream answer, which approval, which signature.

Before you ship

Draw the path from the agent's decision to the money landing, and mark every value that comes from outside your code.
Run the substitution tests from check 6 against your real routes on a testnet.
Send your signer one EIP-7702 authorization request and see whether it signs.
Write down who can revoke a delegation, rotate a key and stop routing funds, and how long each takes.

Adapted from a checklist our team published on zealynx.io.

I wrote this with help from AI for drafting and editing. The opinions and the review experience are mine.

One EIP-7702 signature hands over a whole wallet. What to check if you build on it

Carlos | Zealynx — Fri, 30 Oct 2026 14:14:05 +0000

This week I was reading an open-source guard for agent wallets. It checked unlimited approvals, Permit signatures and long expiries, the usual suspects. It had no idea EIP-7702 authorizations existed. The author fixed it within a few hours, but it stuck with me, because that signature is the most powerful one an Ethereum key can produce now, and some tooling still treats it as an edge case.

Since Pectra went live on mainnet on May 7, 2025, any EOA can point its address at a contract with one signature. After that, every call to the address runs that contract's code with the EOA's balance and storage. The wallet keeps its address and its key, and it also becomes a smart account.

That's a great feature. It also moved the wallet attack surface overnight. Here's what I'd check if you write a delegate contract, a wallet, or a protocol that takes calls from EOAs.

How the delegation works

EIP-7702 adds transaction type 0x04. It carries an authorization_list, and each entry is a tuple:

[chain_id, address, nonce, y_parity, r, s]

The signature covers keccak256(0x05 || rlp([chain_id, address, nonce])). Whoever signed it is the account being delegated. That signer doesn't have to be the one sending the transaction, which is what makes sponsored transactions possible. It's also what lets a drainer submit an authorization a user signed on a phishing site five minutes ago.

Once a tuple is processed, the account's code becomes 23 bytes:

0xef0100 || address

That's the delegation designator. Calls to the account (and a transaction sent to it) load the code at address and run it in the account's context. Code-reading opcodes don't follow the pointer: EXTCODESIZE returns 23 and you read the designator itself, which is how you tell a delegated account apart.

The delegation stays until the owner signs a new one. Delegating to address(0) clears the code and the account is a plain EOA again.

The signature is the deployment

With a normal smart account you deploy a contract and then use it. Here the signature is the whole deployment. The tuple has a chain id, a target and a nonce. No scope, no expiry, no value cap. Whoever signs it hands their address to whatever code lives at address.

It went the way you'd expect. In May 2025 Scam Sniffer flagged a user who lost about $146,000 to malicious 7702 batch transactions tied to Inferno Drainer: the account got delegated and the tokens moved out in one go. On August 24, 2025, a similar batch took $1.54 million in wstETH, cbBTC and NFTs from a single victim.

There's a second pattern that often gets mixed with this one. A month after Pectra, Wintermute found that over 97% of all 7702 delegations on mainnet pointed to copies of the same sweeper contract. Those were accounts whose keys had already leaked. 7702 didn't steal the keys, it just made sweeping every incoming deposit cheaper than running a frontrunning bot. Different problem, same signature.

If you build a wallet, the authorization deserves its own signing screen, with the target contract named in plain words. It's a bigger grant than any approval.

The delegate contract is the wallet's whole security

Even when a user delegates on purpose to the contract they meant to, that contract is now the only thing standing between the account and anyone who calls it. The simplest failure is a function with no access control:

contract VulnerableDelegate {
    function execute(address to, uint256 value, bytes calldata data) external payable {
        (bool ok, ) = to.call{value: value}(data);
        require(ok);
    }
}

Anyone who knows a delegated address can call execute and send its funds anywhere. The user authorized the contract, not each call, so every call has to be authenticated inside it.

The spec's "Secure delegation" section spells out what the account's signature over a call has to cover, and it's a good review checklist:

A nonce, or the same signature replays.
value, or a sponsor can change how much ETH goes out.
gas, or a sponsor can starve the call so it fails.
target and calldata, or a sponsor can route the call anywhere.

Then there's initialization. A delegation runs no constructor and no initcode, so delegates use an initialize function, the same as proxies. If the delegation and the initialize call land in separate transactions, someone can call initialize first with their own owner. Batch them in the same transaction, or make initialize check a signature from the account's own key.

And storage. The delegation can be swapped, the account's storage can't. If the user moves from a delegate that keeps a bool in slot 0 to one that keeps a uint256 there, the new one starts with garbage. Use ERC-7201 namespaced storage and assume you won't be the last delegate this account ever has. It's the same discipline as upgradeable proxies.

chain_id = 0

An authorization with chain_id = 0 is valid on every EVM chain. The spec allows it on purpose, so a wallet can ask for one signature that delegates to the same contract address everywhere.

The catch is that the user signs once and the attacker gets to choose where it lands. The nonce in the tuple has to match the account's nonce on that chain, so it doesn't apply everywhere at once. But it stays valid on any chain where the nonce matches, today or whenever the account's nonce gets there. One phished signature is a takeover waiting on every chain the user touches, as long as the same contract address holds attacker code there.

My view: wallets should refuse to sign chain_id = 0 by default, and delegates shouldn't ask for it unless their code really behaves the same on every chain they might be deployed to.

If your contract takes calls from EOAs

This is the part that affects people who never touch a delegate.

require(msg.sender == tx.origin) used to mean "this is the top frame of the transaction". The spec says plainly that 7702 breaks that. A delegated account can be tx.origin and still run arbitrary code, so if you used the check as a reentrancy guard or an anti-bot gate, it no longer holds for those users. Use a real reentrancy lock (ReentrancyGuard or a transient-storage mutex) for the first, and accept that the second is gone.

The code.length checks flip the other way. A delegated account has 23 bytes of code, so anything that treats code.length > 0 as "this is a contract" now sees your user as a contract. Two places I'd look:

ETH pushed to users. A plain call{value: x} to a delegated account runs its delegate's receive or fallback. That can revert, burn gas or re-enter. If a loop pays a list of users, one delegated user can now break the loop.
safeTransferFrom and _safeMint. OpenZeppelin's ERC-721 calls onERC721Received whenever the recipient has code. If the user's delegate doesn't implement it, minting to that user reverts. Delegate authors should implement the token receiver hooks, and protocols should know some users will fail here.

If you really need to know whether a caller is delegated, check the designator:

function isDelegated(address account) internal view returns (bool) {
    bytes memory code = account.code;
    return code.length == 23
        && code[0] == bytes1(0xef)
        && code[1] == bytes1(0x01)
        && code[2] == bytes1(0x00);
}

Since London no contract can be deployed with code starting with 0xef (EIP-3541), so the prefix is unambiguous.

Sponsors and paymasters

7702 was designed to work with ERC-4337, so a delegated EOA can be the sender of a UserOperation and validation runs its delegate's code. If you run a paymaster that sponsors "accounts using our wallet", remember the user can swap the delegate with one signature at any time. Checking the implementation once at onboarding isn't enough. Read the account's code (0xef0100 plus the delegate address) when you sponsor, and only pay for delegates you know.

The same goes for any guard that signs on a user's behalf. A delegated account's code tells you its current delegate. If it points somewhere you don't expect, stop.

The short version

Writing a delegate

Is every call authenticated, with the signature covering nonce, value, gas, target and calldata?
Is initialize batched with the delegation or signed by the account's key?
Is storage namespaced (ERC-7201)?
Do you implement the token receiver hooks?

Building a wallet

Does the 7702 authorization get its own screen, with the target named?
Do you refuse chain_id = 0 by default?

Writing a protocol

Anything relying on tx.origin == msg.sender?
Anything that treats code.length > 0 as "contract", including ETH pushes and safe transfers to users?

If you've shipped a delegate already, I'm curious what you did about initialization: batched with the delegation, or a signature check?

Adapted from a piece our team published on zealynx.io.

I wrote this with help from AI for drafting and editing. The opinions and the audit experience are mine.

AI agent payments usually get the flow right and the trust wrong

Carlos | Zealynx — Fri, 30 Oct 2026 07:52:52 +0000

Over the last two weeks I kept running into AI agent payment projects: a pay-per-call facilitator, a swap API built for agents, a test suite for x402 payments, a guard that sits between an agent and its wallet, and a banking agent.

The payments worked in all five. The gap was somewhere else, in something the payment path trusted without checking, and it was never the model.

Every team took the feedback well and most shipped a fix within days, so this isn't about anyone being careless. It's a blind spot that's easy to have when the model gets all the attention.

Who decides where the money goes

An x402 facilitator live on mainnet gives each merchant their own vault contract, which pulls the payment and splits it in one transaction, the net to the merchant and the fee to the protocol.

To change where a vault pays, the merchant has to sign. That's the strong control. But the operator deploys the vault, and the first payout address comes from what was saved in the dashboard. The docs call that setting a preference, not an authority. You only see that it decides the first payments in the vault code, not in the docs.

So the weaker path picks where the money goes, and the merchant's signature only matters after that. If the operator key leaks, every merchant who hasn't been paid yet can get a vault that pays someone else.

The dev agreed and is fixing it so operator-created vaults always pay the merchant. If you ever fix something like this, remember the payout is written once, when the vault is created. A fix in the factory only covers new vaults. The existing ones keep whatever they were given, so you go through the creation events and ask those merchants to confirm.

If the address comes from the API, it's not a check

Then there was a free swap API and MCP server for agents. It asks several aggregators and bridges for quotes, ranks the routes and returns calldata, and the agent signs whatever comes back.

That makes the upstream APIs part of the agent's wallet. If one of them is compromised, it can hand back calldata that sends the swap to someone else, and every agent using the API signs it.

I suggested decoding the calldata on the server first: the router is on an allowlist, the recipient is the user, and the minimum output matches the quote. They shipped it within a day.

Then they hit the harder case, a bridge where the recipient is bound off chain. Their fix was good: fetch the order, recompute its id, check the recipient and the minimum amount, and require the deposit to go to the bridge's deposit contract. But the deposit contract address came from the same bridge API at runtime. A compromised API could list its own contract, and every order check would still pass, because the funds never reach the real one.

Pin addresses like that per chain in your config, and alert when the API disagrees.

"A payment exists" is not "this payment paid for this"

This one is an open-source CI suite that injects faults into x402 settlement on Solana, so a server can test how it handles bad payments. The author asked which checks were missing.

I'd start with a valid payment made for a cheaper route, or to a different recipient, replayed against a pricier route. A server that only checks that a settled payment exists will serve it.

They took it as tests for amount, recipient and resource substitution. Then I asked about the same amount paid in a different token, or on devnet, replayed against a mainnet route. Checks that only compare amount and recipient let that through. They shipped both as new checks in their next release.

The same thing comes up on the client side. In x402 the 402 response tells the agent which token contract and which network to pay on. So a spend limit that pins the recipient but not the asset and the network can be walked around by an endpoint that keeps the number the same and changes the token. And when a human approves a payment, they should see the exact requirements that get signed, not the agent's summary of them.

The signature your guard doesn't know about

An open-source guard for agent wallets holds unlimited approvals, Permit signatures and long expiries by default, which are the ones that usually bite.

The one missing was EIP-7702. An authorization is a signature over a chain id, an address and a nonce. It isn't typed data and it isn't a normal transaction, but it delegates the whole account to a contract, which is worse than any unlimited approval. And a chain id of 0 makes it valid on every chain.

The guard approved a type 4 transaction even when its authorization list delegated the account, and the framework plugin didn't look at the authorization list at all. The author fixed both and published within three hours.

He was also honest about the limit: the guard only sees what goes through the wrapped client. If the agent can reach the raw key, nothing on the client side sees the authorization. One thing a guard can still do on its own is read its account's code before each send. A delegated account returns 0xef0100 followed by the delegate's address. If that points somewhere you don't expect, stop signing.

The text the model still writes

The banking agent was already well built. The customer types the payee and the amount, and the confirm screen sits outside the chat, so the model can't misdescribe the transfer.

But the transfer note is still written by the model, and it leaves the bank and lands with someone outside. A model that read a malicious message can put the customer's balance or another account number in the note of a small transfer. It's the same problem as email tools where the recipient is pinned but the model writes the body.

The simplest fix I can think of is a note field on the confirm screen that the customer fills in. Then the model never writes it.

What I check now

These are the questions I ask about an agent payment design now:

Who can set where the money goes, and in what order? If a weaker control decides first and the strong one only applies later, the weak one is the real control.
Where does every address come from? If it comes from the same API you're checking, it's not a check. Pin it.
What is the payment bound to? Amount, recipient, resource, token and network. Not just "a settled payment exists".
Which signatures can the agent's key produce? Transactions, typed data, permits and EIP-7702 authorizations. A guard that only knows some of them isn't a guard for the others.
What free text does the model still write that reaches someone outside? Notes, memos, email bodies, metadata. That's a way to send data out.

None of the fixes needed a smarter model.

If you're building agent payments, I'm curious which address in your flow still comes from an API you don't control.

I first wrote a short version of this on X.

I wrote this with help from AI for drafting and editing. The opinions and the review experience are mine.

Six ways ERC-4337 smart accounts fail in audits

Carlos | Zealynx — Tue, 27 Oct 2026 14:11:34 +0000

A normal Ethereum wallet has one rule: whoever holds the key controls the account. Blunt, but predictable.

ERC-4337 swaps that rule for a function you write, validateUserOp. Whatever logic sits in there is now the account's whole security. The EntryPoint will call it, the bundler will forward whatever passes it, and if it's wrong, nothing downstream saves you. Something that used to be protected by cryptography is now protected by code, and code has bugs.

So when I review a smart account, that's where I start. Trail of Bits published their own list of six common mistakes in 4337 accounts in March, after auditing dozens of them, and a lot of it matches what we run into. These are the six I'd check first, with what they look like in code.

1. The signature doesn't cover the whole UserOperation

The classic one: a team ports an EOA-style signature check into validateUserOp and only signs part of the operation.

// Vulnerable: the signature only covers callData
function validateUserOp(
    UserOperation calldata userOp,
    bytes32 userOpHash,
    uint256 missingAccountFunds
) external returns (uint256 validationData) {
    bytes32 hash = keccak256(abi.encode(userOp.callData));
    address recovered = ECDSA.recover(hash, userOp.signature);
    if (recovered != owner) return SIG_VALIDATION_FAILED;
    return 0;
}

The EntryPoint checks and increments the nonce in the UserOperation, but this signature doesn't cover the nonce. So anyone who sees a valid operation can resubmit the same signature with the next nonce and run the same call again, on the same chain. The gas fields aren't covered either, so they can also set the gas price as high as they like and the account pays it from its deposit. And if the account sits at the same address on another chain (common with CREATE2), the operation works there too.

The fix is to verify the signature against userOpHash, which the EntryPoint already gives you. It covers every field of the operation except the signature, plus the EntryPoint address and the chain id.

Same idea for isValidSignature (ERC-1271): if two accounts share an owner key, a signature made for one can pass on the other unless the hash includes the account address and the chain.

2. A paymaster that pays for anything

Paymasters pay gas for other people. That sentence alone should start a threat-modeling session.

The common failure is a paymaster that decides to sponsor in validatePaymasterUserOp based only on who the sender is. "Is this user on our allowlist?" Yes, so it pays, whatever the callData does and however much gas it asks for. An allowlisted user (or anyone who controls an allowlisted account) can then burn through the paymaster's deposit in the EntryPoint.

What I'd check:

Does validation look at the target, the function selector and the gas limits, not just the sender?
If you charge the user in postOp (an ERC-20 paymaster pulling tokens, for example), what happens when postOp fails? The user can make it fail, for example by revoking the token allowance inside the same operation. The execution reverts, and the paymaster has still paid the gas (since EntryPoint v0.7 there's no second postOp call to clean up). Getting paid shouldn't depend only on postOp succeeding.
What does it cost an attacker to drain the deposit? If the answer is "less than the deposit", you need more limits.

3. The packed return value

validateUserOp doesn't return a simple true or false. It returns a uint256 with three things packed in it:

The low 20 bytes: 0 means the signature is valid, 1 means it failed, and anything else is read as the address of an aggregator.
The next 6 bytes: validUntil, a timestamp, where 0 means it never expires.
The next 6 bytes: validAfter.

The mistakes I see around this:

Reverting on a wrong signature. The spec says to return 1 (SIG_VALIDATION_FAILED) on a signature mismatch and revert only on other errors. Reverting breaks gas estimation for your users.
Packing by hand and swapping validUntil and validAfter. The window you meant to allow is not the window the EntryPoint enforces.
Forgetting that validUntil = 0 means forever. A session key whose expiry never got set is a key that never expires.

Use the _packValidationData helper from the reference implementation, and write a test that runs your return values through the real EntryPoint, not a mock.

4. Modules anyone can install

More and more accounts use modules (validation modules, execution modules, fallback handlers, ERC-7579 style). Composable, yes, but the account becomes only as safe as the weakest module installed on it.

The specific failure: module installation without access control.

// Vulnerable: no access control on module installation
function installModule(address module, bytes calldata initData) external {
    IModule(module).onInstall(initData);
    _modules[module] = true;
}

If anyone can call that, an attacker installs a validation module that says yes to every signature, and the account is theirs. Installing a module should go through the same validation as any other privileged action, and every module you allow deserves the same review as your own validateUserOp.

5. Validation that reads storage it shouldn't

Bundlers simulate your validation before including an operation, and they enforce rules (now in ERC-7562) on what validation can touch. Roughly: the account's own storage, and slots in other contracts that are tied to the account's address, like a token balance keyed by the account. The rules exist so an operation can't pass simulation and then fail on chain because someone changed shared state in between.

Read a shared price oracle or a third-party registry during validation and compliant bundlers will drop your operations. The annoying part is that it all passes locally, and teams find out in production when operations quietly never land. Run your operations through a real bundler on testnet before mainnet, and call eth_estimateUserOperationGas against it during testing.

6. Social recovery that can be griefed

Social recovery is one of the best things about smart accounts, and one of the most often broken. Usually it's not theft, it's a way to lock the owner out.

The pattern: any single guardian can start a recovery, the threshold is needed to finish it, and starting a new one resets the timer. A single bad guardian can keep restarting the clock and block a real recovery forever, for the price of gas.

What I'd check: can one guardian restart or block the process on their own? Is there a delay on ownership changes, so the real owner has time to cancel? What happens if a recovery starts while another one is still open?

What the bundler and EntryPoint don't do for you

A misconception I hear a lot: "the bundler and the EntryPoint are a security layer". They're not. They enforce the 4337 protocol rules, not your business logic. An operation that passes your validateUserOp will be executed even if it drains the account, installs a malicious module or hands ownership to someone else. Protocol conformance is their job. The rest is yours.

The agent problem

More and more AI agents use a 4337 account as their wallet: the agent builds UserOperations, the account validates and executes them. That changes the threat model. If the agent can be prompt-injected, the attacker doesn't need the key. They only need to change what the agent wants to do, and the agent will sign it correctly.

So "the signature is valid, so the action is authorized" stops being true. For agent-controlled accounts, the limits have to live in the account: spending caps per period, allowed targets and functions, rate limits, in validateUserOp or in a dedicated module. Not in the agent's system prompt. I think a lot of review time in the next year goes exactly here.

A short checklist

Validation

Is the signature checked against userOpHash, and nothing narrower?
Do you return 1 on a bad signature instead of reverting?
Are validUntil and validAfter packed with the helper and tested against the real EntryPoint?
Does validation read only storage the bundler rules allow?

Paymaster

Is sponsorship tied to targets, selectors and gas limits, not just the sender?
Does the paymaster still come out fine if postOp fails?

Modules

Does installing a module need the owner's authorization?
Can a module override core validation?

Recovery

Can one guardian grief the process?
Is there a delay on ownership changes that the owner can use to cancel?

If you've built on 4337 or ERC-7579 modules, which part was hardest to get right for you? I'm curious whether it's the paymaster or the validation rules that bite people most.

Adapted from a piece I wrote on zealynx.io.

I wrote this with help from AI for drafting and editing. The opinions and the audit experience are mine.

Three things that break when your vault takes cross-chain deposits

Carlos | Zealynx — Fri, 23 Oct 2026 13:12:20 +0000

If your ERC-4626 vault is about to accept deposits from other chains, this one is for you.

On October 8, Chainlink launched CCIP Vault Adapters. A standard ERC-4626 vault on one chain can now accept deposits from more than 80 others, while the accounting, governance and risk parameters stay on its home chain. Aave, Lombard, Veda and Venus are among the first users.

Four days earlier, S&P Global Ratings launched a Vault Risk Assessment. It scores a lending vault on six factors, and two of them are about code: protocol risk, and vault security and governance. "A strong score in one factor does not offset a material weakness in another," one of S&P's analysts told Cointelegraph.

And the money is there. Deposits in DeFi lending vaults passed $10 billion, up from about $4 billion at the start of 2025, according to the Financial Times, as reported by CoinDesk.

My read

A vault is becoming something an outside party scores, and part of that score is your code. I think that's a good thing. A depositor reading a risk score asks better questions than a depositor reading an APY.

One-click deposits are good for users too. But they move the hardest question in cross-chain finance out of the user's wallet and into your vault: did the full amount actually arrive? Before, the user bridged, waited, and deposited whatever landed. Now your contract mints shares for a deposit that started on another chain. Chainlink is clear about where its part ends. Its own disclaimer says it "does not deploy, control or operate any vault or vault adapter." The transport is theirs. The accounting is yours.

What breaks when a vault goes cross-chain

My team reviewed this kind of system in September. Yieldcoin v2 is a five-chain stablecoin vault built on Chainlink CCIP and CRE: a parent vault keeps the books, and child vaults on other chains put the money to work in Aave and Compound. It built its own CCIP flows before the new adapters existed, so none of this is about Chainlink's product. These are the three findings I'd check in any cross-chain vault:

A successful send is not a delivery. CCIP token pools can charge a transfer fee. The code minted shares from the amount sent and treated a successful ccipSend as proof that the full value arrived. With a fee on, the destination received less, every call still succeeded, and the shares were backed by less than the books said. Nothing reverted, so nothing alerted. The fix: reconcile shares to the amount that actually arrived.
A signed command has to name its receiver. The signatures covered the report, but not which contract received it. A valid withdrawal meant for one child vault could be replayed through another. That was the Critical. The fix: sign the target chain and the router too.
A retry only helps if the failure can change. Netting could shrink a deposit to one base unit of USDC. Aave v4 rounds that to zero shares and rejects it. The vault stored it for a retry, and the retry could never work, so later epochs and rebalancing stayed blocked. The fix: preview the conversion first, and keep amounts that can't be deposited tracked instead of retried.

The adapters do come with failed-message handling, designed to give stuck funds a path back to the owner. Asynchronous vaults and cooldowns are next on Chainlink's list, and that's where these state machines get really hard. If you're heading there, ERC-7540 (the request-and-claim pattern for async vaults) is the standard to read first.

If you're opening your vault to other chains in the next three months

Three things I'd have done before the first cross-chain deposit:

Test with the fee switched on. Run your deposit flow on a fork against a token pool that charges a fee, and assert that shares match what arrived, not what was sent.
Write down every failure and its exit. For each revert you catch, ask: can waiting fix this? If not, does it abort, reconcile or reroute? A stored retry for a condition that never clears is a frozen vault with extra steps.
Get the single-chain basics right first. The first-depositor inflation attack is still the first thing I'd check in any ERC-4626 vault. Virtual shares or dead shares at deploy, and an invariant that a deposit above zero never mints zero shares.

S&P hasn't scored a single vault yet. The first assessments come "in future announcements." When they do, protocol risk and vault security sit on the list next to curator and credit risk, and a strong score on one doesn't cover a weak one on another.

If you're building one of these, I'm curious: how are you testing the cross-chain leg today, forks, mocks, or testnet?

Sources: Chainlink CCIP Vault Adapters, S&P Global Ratings press release, Cointelegraph, CoinDesk.

Originally published in my newsletter, DeFi Protocol by code.

I wrote this with help from AI for drafting and editing. The opinions and the audit experience are mine.

An MCP security checklist for developers wiring agents to real tools

Carlos | Zealynx — Thu, 22 Oct 2026 13:12:40 +0000

Connecting an agent to a tool through MCP takes about ten minutes. You add a server to a config file, restart, and now the model can read files, run git, query a database or send email.

What you also did in those ten minutes is give a process that takes instructions from text it reads the same permissions as you. Every file the agent opens, every web page, every tool result is input that can steer it. And the MCP server on the other side usually runs with your user, your keys and your network.

Most of the MCP problems I've looked at are not exotic. They're the old bugs (path traversal, shell injection, hardcoded keys) in a place where the input now comes from a model that can be talked into anything. Plus a few new ones that only exist because of how agents read tool output.

So this is the list I'd go through before letting an agent use an MCP server on anything real.

The numbers, briefly

These are from public research in 2025, so treat them as a snapshot, not a census:

82% of MCP servers studied use file operations prone to path traversal (Endor Labs).
53% rely on static, long-lived credentials like hardcoded API keys (Astrix Security, 5,200+ servers analyzed).
43% of servers tested had command injection (Equixly).

And the incidents that show the pattern:

Tool poisoning, April 2025. Invariant Labs showed a malicious MCP server, sitting next to a trusted WhatsApp server in the same agent, quietly exfiltrating chat history through instructions hidden in its tool description.
MCP Inspector RCE, June 2025. CVE-2025-49596, CVSS 9.4. Unauthenticated code execution on developer machines through Anthropic's official debugging tool.
mcp-remote, July 2025. CVE-2025-6514, CVSS 9.6. A malicious authorization_endpoint during the OAuth flow turned into OS command execution.
Postmark MCP, September 2025. A trojanized package on npm BCC'd every outgoing email to the attacker.

None of these needed a clever model attack. They needed one trust assumption nobody wrote down.

1. The server itself (4 checks)

These are the ones that end in code execution or file access on your machine.

Path traversal. Every path argument is resolved and checked against the allowed root, after following symlinks. ../ is the obvious case, an absolute path or a symlink inside the allowed folder are the ones that slip through.
Command injection. No shell strings built from tool arguments. Pass arguments as an array, and watch for arguments that start with -, because git log --grep="$input" stops being safe the moment the input becomes a flag.
Execute primitives in "safe" tools. Git is the classic one. If the agent can write .git/config or pass -c options, it can register a hook, an alias or a filter that runs on the next commit or checkout. A reader pointed out on one of my earlier posts that git worktrees share hooks and config with the main repo, so a separate worktree doesn't help here either.
Write boundaries. Writes are limited to the folders the task needs. Config files (.git/hooks, .husky, package.json scripts, CI files, editor settings) are persistence, so treat writes there as executions.

2. Tool poisoning and injection (4 checks)

The part that ordinary input validation doesn't catch.

Injected instructions in tool output. A git log, a README, an issue comment or a web page can contain "ignore previous instructions". Assume it will. The defense is not a better prompt, it's that the agent can't do much damage when it follows one.
Hidden content. Invisible Unicode, HTML comments and text the user never sees but the model does. Strip or flag it before it reaches the context.
Exfiltration through normal-looking actions. A poisoned agent doesn't need a "send secrets" tool. A URL with a query string, an image link in markdown, a commit message, a search query. Check which of your tools can carry data out.
Tool descriptions are input too. A server can put instructions in its own tool descriptions, or name a tool so it shadows one from a trusted server. Read the descriptions of every server you add, and re-read them when the package updates.

3. Credentials and access (3 checks)

No hardcoded credentials. Use proper OAuth or short-lived tokens where the API supports it.
Scoped keys. A key per server, with the smallest scope that works, rotated. Not your personal admin token in an env var that every server and every subprocess can read.
Least privilege for the process. Don't run servers as root. Ideally not even as your main user: a container or a separate user with access only to what the task needs.

4. Several servers in one agent (3 checks)

Combinations are the attack surface. A browser server plus a git server means web content can steer git operations. Filesystem plus network means read plus send. Look at what each pair can do together, not each one alone.
Shared context. All servers write into the same model context, so one bad server can influence how the agent uses all the others.
Write down the combinations. A short table of which servers are connected where, and what each combination could do if one of them went bad.

5. Supply chain (3 checks)

Pin versions and verify what you install. An MCP server is a dependency with your permissions.
Watch for typosquats and impersonation. The Postmark case was a package that looked like the real thing.
Prefer a short list of servers you've reviewed over whatever a search turns up, and review updates like you'd review a PR.

6. Prompt and context (3 checks)

Context pollution. Large or adversarial tool output can push your instructions out of the window or bury them.
Keep instructions and data apart. Mark tool output as data in the way you build the context, and don't let it land in the system prompt.
Size limits on what a tool can return.

7. Network and monitoring (4 checks)

SSRF. Any tool that fetches a URL can be pointed at 169.254.169.254, localhost admin panels or your internal network. Block private ranges by default.
Webhooks and callbacks are authenticated and can't be pointed anywhere by the model.
Rate and spend limits that live outside the agent, so a loop or a poisoned plan can't run up a bill.
Logs with arguments. Which tool was called, with what, by which agent session. When something goes wrong, "the agent did something" is not a useful incident report.

Before you ship it

Go through the OWASP Top 10 for Agentic Applications once with your setup in mind.
If the agent uses more than one server, review them together.
Test prompt injection against your actual model and tools, not a generic demo. Put an instruction in a file the agent will read and see what it does.
Decide what you'll do when a server or a key is compromised: how you revoke it, and how you find out what it touched.

The short version

If I could only pick three: no shell strings built from model input, no long-lived broad keys in the server's environment, and treat every tool result as something an attacker wrote. Most of the incidents above fail at least one of those.

What does your MCP setup look like? I'm curious how many people run servers in a container versus straight on their laptop.

Adapted from a guide our team published on zealynx.io.

I wrote this with help from AI for drafting and editing. The opinions and the audit experience are mine.

Can't afford an audit yet? What I'd do instead

Carlos | Zealynx — Tue, 20 Oct 2026 13:07:11 +0000

A serious smart contract audit costs somewhere between $15k and $100k+, depending on scope and complexity. For a team before its first raise, that can be more than a month of runway. So a lot of founders look at the quote, close the tab and ship anyway.

I run a small audit firm, so weigh my bias. But "audit or nothing" is the wrong way to frame it. The useful question is: what is the most risk I can remove per dollar, at the stage I'm actually at?

Here's how I'd answer it.

The options, side by side

Option	Rough cost	What it covers	What it misses
Ship unaudited	$0 today	Nothing	Everything
Static analysis (Slither, Aderyn)	$0	Known bug patterns	Your logic
AI-assisted review	$0 to $200 a month	Broad pattern coverage	Accountability, economic logic
Public audit contest	$20k+ prize pool	Many eyes, variable depth	Early teams' budgets
Bug bounty	Pay per finding	Bugs found after deploy	Everything before deploy
Time-boxed senior review	A few hundred to a few thousand dollars	Your highest-risk contracts	Full coverage
Full audit	$15k to $100k+	Full scope, re-checks	Nothing in scope, if done well

What each one is actually good for

Shipping unaudited is fine on testnet with no user funds and no token. The trap isn't getting hacked on day one. It's that value arrives slowly, and by the time the protocol is worth attacking, the team is used to shipping without review.

Static analysis should run in your CI no matter what. It catches the embarrassing bugs: reentrancy shapes, unchecked calls, common access control mistakes. It does not catch the expensive ones. No analyzer knows your withdrawal formula rounds the wrong way or that liquidations break when the oracle goes stale.

AI review finds real bugs now. I build AI auditing tooling myself, so I've seen both sides: without a human who audits for a living checking the output, it gives you false confidence in both directions. It flags things that aren't exploitable and stays quiet on economic logic it doesn't understand. A strong complement, a weak replacement.

Audit contests can go deep, but competitive prize pools start around $20k and quality depends on how attractive your pool is to good researchers that week. They suit funded teams near mainnet with code stable enough to freeze.

Bug bounties aren't a review at all. They're an incentive for after you deploy, so the bug gets found once user funds are already behind it. Run one alongside everything else once you're live, never instead of reviewing before launch.

A time-boxed senior review is the category built for exactly this gap: a senior auditor spends one to three days on the contracts where the money moves. It's not line by line over everything, and it's not an audit. Anyone who sells you a two-day review as "audited" is setting your users up.

What I'd pick at each stage

Testnet, nothing at risk: static analysis in CI plus AI review. Spend $0.
Real users or funds arriving, budget under about $5k: a time-boxed senior review of the contracts that hold the money, plus the free tools. This is the most risk removed per dollar you can get.
Funded and heading to serious TVL: a full audit, maybe preceded by a contest.
Live at any stage: add a bug bounty on top.

Three questions before you pay anyone

Whatever you choose, ask these first:

Who exactly reads the code, and what's their track record?
What do I get in writing?
What am I allowed to claim publicly afterwards?

If the answers are vague, or a cheap review comes with an "audited by" badge, walk away.

What did you do for security before you could afford a full audit? Curious what worked for other teams, and what you'd skip next time.

Adapted from a guide our team published on zealynx.io.

I wrote this with help from AI for drafting and editing. The opinions and the audit experience are mine.

Ethereum's next upgrade can break your contracts

Carlos | Zealynx — Fri, 16 Oct 2026 13:10:08 +0000

If you have a transfer(), a call{gas: 50000} or an if (gasleft() < X) somewhere in a contract on mainnet, this one is for you.

On October 6, Ethereum's next upgrade, Glamsterdam, went live on the Sepolia testnet. Most of the coverage is about throughput and block building. The part that matters for deployed contracts is quieter: Glamsterdam reprices state.

Creating a new account goes from 25,000 gas to 183,600.
A new storage slot goes from 20,000 to 97,920.
Every byte of deployed code goes from 200 to 1,530.
Changing an existing storage slot goes from 2,900 to 10,100.

The Ethereum Foundation replayed historical mainnet transactions under the new numbers. Most contracts are fine. A small set "may lead to these contracts breaking or degrading without preventative updates." The testnet announcement says it plainly: "Contracts that rely on fixed gas stipends, hardcoded gas limits, or assumptions about remaining gas may need changes." Mainnet has no date yet, and the target is this quarter.

My read

Hard forks rarely break your code. This one can, but only where you wrote down a number. Every transfer(), every hardcoded gas value, every branch on gasleft() is an assumption about what the EVM charges. If your contracts were audited, the audit checked that assumption against today's gas schedule, not the next one. Every hard fork is an audit decay event for someone.

This has happened before. In 2019, Istanbul raised the cost of reading storage from 200 to 800 gas, and the EIP itself warned that fallback functions reading storage "may in some cases require more than" the 2,300 gas a transfer() forwards. That's when the industry started telling developers to stop using transfer(). The difference now is months of warning, a public testnet, and a tool that tells you if your contract is on the list. I don't think this is a reason to panic. But "most contracts are fine" is not a property of your contracts. You have to check.

Where the new numbers bite

Hardcoded gas in calls. transfer(), send() and call{gas: N}. The 2,300 stipend stays the same, but what fits inside it changes, because touching state now costs more.
Logic that branches on gasleft(). Keepers, relayers, meta-transaction forwarders, batch loops that stop at a gas threshold. EIP-8037 even notes that metering by subtracting two gas readings can now go negative.
Anything that creates accounts or contracts. Factories, a clone per user, smart accounts deployed on first use. Account creation and code deposit both get several times more expensive, so re-check your gas budgets and your fee math.
Fixed gas limits off-chain. Presigned transactions, bots and frontends that send a hardcoded limit. A plain ETH transfer to an existing account still costs 21,000, but a transfer to a fresh address no longer does.
Indexers. Every ETH transfer will emit a log with the same topic as an ERC-20 Transfer, from a system address. If your backend listens for that topic without checking the emitter, check what it does with them.

There's good news too: the contract size limit goes from 24 KiB to 64 KiB, so fewer teams will need to split code across libraries just to deploy.

If one of your contracts is flagged and it's immutable, the fix is a migration, not a patch. If it's behind a proxy, the fix is an upgrade, and upgrades have their own ways to go wrong, so treat that upgrade like any other change that needs review.

If you have contracts on mainnet, before the fork date is set

Three things I'd do this month:

Paste your addresses into the Ethereum Foundation's repricing impact dashboard. It's free. It replays real mainnet transactions under the new schedule and tells you if yours still work, need a higher gas limit, or might be broken.
Grep for written-down gas. Search your contracts for .transfer(, .send(, gas: and gasleft(), then do the same in your frontend, bots and deploy scripts for hardcoded gas limits. Every hit is a question to answer.
Run your critical flows on Sepolia. Deposits, withdrawals, liquidations, anything a keeper triggers. A fix costs a conversation now. After the fork it costs an incident.

If you're deploying new contracts before the fork, the simplest rule is not to write gas down at all. Send ETH with a plain call behind a reentrancy guard, check the return value, and let your frontend estimate gas against the network it's actually talking to instead of shipping a constant.

One more date: the repricing EIPs are in Last Call until Sunday, November 1. If the dashboard shows your contracts breaking, now is the time to say it in the EIP-8037 and EIP-8038 threads on Ethereum Magicians, not after mainnet.

Have you run your contracts through the dashboard yet? Curious if anyone found something flagged.

Sources: EF testnet announcement, EF repricing testing post, EIP-8037, EIP-8038, EIP-7954, EIP-7708, EIP-1884.

Originally published in my newsletter, DeFi Protocol by code.

I wrote this with help from AI for drafting and editing. The opinions and the audit experience are mine.

AI helped find most of curl's 24 new CVEs. What made them real was the human check.

Carlos | Zealynx — Wed, 14 Oct 2026 11:57:43 +0000

In January, curl shut down its bug bounty. Daniel Stenberg said the goal was to remove the incentive for people to send "crap and non-well researched reports to us. AI generated or not." The last week of the program brought seven reports and none of them described a vulnerability.

Today, curl 8.23.0 shipped with 24 security fixes. AISLE says its researchers found 18 of them. The only one rated High, a use-after-free in the HTTP/2 upload path, was reported by an Anthropic researcher using Anthropic's new open source scanner. The curl team confirmed it within hours and cut the release cycle from eight weeks to six to ship the fix.

Same project, same kind of tools, nine months apart. One produced so much noise the bounty closed. The other produced real CVEs. I don't think the difference was the model.

What changed between January and October

Look at how the October reports got to the curl team.

AISLE says a security researcher reviews the complete report before submission. Then curl's own security team decides whether the behavior is real, whether it breaks curl's security policy, how severe it is and whether it gets a CVE. Stenberg describes AISLE's work as "detailed and accurate findings backed up by a team of skilled humans."

So there were two human checks before anything became a CVE. One on the side that ran the tools, one on the side that owns the code.

The January reports skipped the first check. Someone pointed a tool at curl, got something that sounded like a vulnerability and sent it. The cost of verifying moved from the reporter to a small maintainer team. Stenberg's rule was simple: never report a bug unless you actually understand it and can reproduce it.

The same thing happens in smart contract audits

I audit smart contracts, and AI is now a big part of how my team works. Last week I wrote that without prior experience auditing manually, I don't think AI auditing can be done properly. The curl story is the same point at a much bigger scale.

In my last sweep on a competition codebase I ran six agents in parallel. Five came back with reasoned negatives. The sixth produced passing PoCs, but they only rediscovered a finding we already had. None of that output could be taken at face value.

The two failure modes are the same ones curl lived through:

Agents invent findings. Ask a model to find a vulnerability and it will try hard to give you one. It sounds plausible, it has a title, sometimes a severity. That's what filled curl's inbox in January.
Agents declare things safe. A reasoned negative is useful to decide where not to spend more time. It doesn't mean the area was checked completely, and it definitely doesn't mean the audit is done.

You need someone who knows the code well enough to catch both. That's the part that didn't get cheaper.

A raw firehose is coming too

On October 8 Anthropic opened an opt-in scanning service for open source maintainers. They say plainly that its output "will be fully model-generated, without human review or triage." In their own six months of scanning they got over 29,000 candidate vulnerabilities and manually reviewed about 6,000.

I don't think that's bad. It's free, it's opt-in, and maintainers know what they're getting. But it moves the triage to you. If you enroll, the first check from the curl story is your job now.

What I'd take from this if you ship code

Whether you maintain a library or you're about to launch a protocol, a few things I'd keep in mind:

A finding without a reproduction is a lead, not a finding. In audits a PoC is what turns "this looks wrong" into "this is broken". Ask for it, or write it yourself before you spend a week on a fix.
Budget time for triage, not just for scanning. Running the tool is the cheap part now. Reading 200 results and throwing most of them away is where the hours go.
Write down why you discarded something. "Not exploitable, only the owner can call it" is a trust assumption. If nobody writes it down, nobody notices when the assumption changes.
Treat "nothing found" with suspicion too. Ask what the tool actually covered. A clean scan of one path says nothing about the others.
Keep the human who knows the code in the loop. curl's team could confirm the High one in hours because they know their code. That's the bottleneck now, and it's the part worth protecting.

curl didn't stop taking AI-assisted reports. It stopped rewarding unverified ones. Now Stenberg says the reviewed work is helping them fix vulnerabilities "at a higher rate than ever before." I think that's the right model for the rest of us.

How are you handling AI scanner output on your own projects? Do you read everything, or do you have a way to rank it first?

Sources: curl 8.23.0 release, the HTTP/2 use-after-free write-up, AISLE's write-up, Anthropic's opt-in scanner, The Register on the bounty shutdown.

I wrote this with help from AI for drafting and editing. The opinions and the audit experience are mine.

What to have ready before your first smart contract audit

Carlos | Zealynx — Tue, 13 Oct 2026 13:11:44 +0000

An audit is usually the biggest single check an early team writes. And a good part of the first days of most audits goes to things that have nothing to do with finding bugs: figuring out what the protocol is supposed to do, which files are in scope, why the tests don't run, which commit we're even looking at.

You pay for those days either way. The difference is whether they go into understanding your setup or into attacking your logic.

So this is the list I'd go through before the audit starts. None of it needs a big budget. Most of it is a few evenings of work.

1. Write down what the code is supposed to do

If the auditor has to reverse engineer your intent from the code, part of the audit is spent guessing.

NatSpec on every public and external function. @notice, @param, @return. It sounds boring, but it's one of the best bug finders there is. If the comment says "takes a 1% fee" and the code computes 0.1%, that mismatch jumps out the moment someone reads both. Without the comment, the code is just the code, and a wrong number looks like a design choice.

A short theory of operation. How the money moves, who can do what, and what must never happen. A call graph and a state machine diagram help a lot if you have lifecycles (governance, vesting, auctions, liquidations).

A one page threat model. Who is trusted (owner, keepers, oracles), what each of them could break if they went rogue, and the single assumption you're most nervous about. This is the page I'd want first. A finding is only real relative to your trust assumptions, and without them every report turns into a debate about what counts as "in scope for an attacker".

A 20 to 30 minute video walkthrough. The lead dev screen-sharing the architecture and the flow of funds. It's the fastest way to get someone from zero to useful.

2. Clean the house

Noise hides bugs. It also costs reading time, because every line has to be read before anyone can say it doesn't matter.

Run a linter (Solhint or prettier-plugin-solidity). Style comments in an audit report are money spent on things a free tool does.
Delete dead code. Unused functions, commented out blocks, leftover test helpers in production contracts. Dead code isn't always dead: an internal helper that later gets exposed by a refactor is a classic way for old assumptions to come back.
Pin your compiler and your dependencies. pragma solidity 0.8.x; with an exact version, not ^0.8.0, and locked dependency versions. The bytecode you deploy should come from exactly the code that was reviewed.

3. Test the sad paths

Low test coverage is the clearest sign a codebase isn't ready.

Branch coverage, not line coverage. Line coverage tells you the code ran. Branch coverage tells you that every require and every if was hit both ways. Most of the interesting bugs live in the paths that are supposed to revert and don't.

Run static analysis and deal with every warning. Slither takes seconds. Fix the warnings or write down why each one is a false positive. Handing over 50 untriaged warnings means someone you're paying will triage them for you.

Run an AI pass too. Finding the obvious stuff got very cheap this year, for you and for anyone who looks at your code after deploy. Do it before the audit, fix what's real, and you'll get more out of the humans.

Write invariants and fuzz them. Unit tests check the cases you thought of. Invariant tests check the cases you didn't. With Foundry or Echidna, write down the properties that must always hold (something like "the sum of user balances never exceeds what the contract holds") and let the fuzzer try to break them. Even a handful of good invariants tells the auditor a lot about how you think about your system.

4. Freeze the code

Tag the commit (git tag audit-v1) and don't touch it. Pushing "small fixes" during the audit moves line numbers, invalidates notes, and turns into a diff review you pay for on top. If you find something yourself mid-audit, write it down and fix it in the remediation round. Better yet, tell the auditors, so they look at the area around it.

Write the scope down. A scope.txt with the exact files. Exclude mocks, deploy scripts and unmodified libraries like OpenZeppelin. If you modified a library, say so explicitly, because that's exactly the kind of thing that hides in "we just use OZ".

The short version

Area	Ready when
Docs	NatSpec on every public function, a theory of operation, a one page threat model
Code	Linter clean, no dead code, compiler and dependencies pinned
Tests	High branch coverage, sad paths tested, a few invariants fuzzed for a long run
Tools	Slither and an AI pass run, every warning fixed or explained
Ops	Commit tagged and frozen, scope file written, walkthrough recorded

One more thing

An audit covers a commit. Not your deploy scripts, not your config, not the three PRs you merge the week after. So plan the launch too: caps you can raise later, a pause you've actually tested, alerts that reach a human.

If you only do one thing this week, run Slither on your core contracts tonight. If it flags things you've never looked at, that's your answer on whether you're ready.

What's on your own pre-audit list that I didn't cover? Curious what other teams do before they book.

Adapted from a checklist our team published on zealynx.io.

I wrote this with help from AI for drafting and editing. The opinions and the audit experience are mine.