new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Smart Contract Auditor · all subjects

Reentrancy Detection & Mechanics

2 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

The concrete reentrancy audit checklist — what do I look for in code?

Work it mechanically: (1) enumerate every external call — .call(), .delegatecall(), .transfer()/.send(), ERC-20 transfer/transferFrom/safeTransfer, and any call into an address the user can influence. (2) For each, list state written AFTER the call — balance zeroed after .call{value:} is the classic bug. (3) Check what the callee can re-enter: same function (classic), a different function sharing the same state (cross-function), a different contract reading your mid-transaction state (read-only reentrancy in LP pricing). (4) Look for hooks that hand control to the receiver: ERC-777 tokensReceived, ERC-721/1155 onReceived, ETH fallback/receive. (5) Verify the fix pattern: checks-effects-interactions ordering, or ReentrancyGuard on every entry point touching the same state. (6) Test it: write the attacker contract whose fallback re-enters, and run it as a foundry fork test — a finding without a PoC is a guess.

I see withdraw() calling token.transfer() to the caller — is it reentrant?

Distinguish three cases. ETH via .transfer()/.send() forwards a 2300-gas stipend, which historically blocked reentry callbacks — but gas costs shift between hard forks (Istanbul broke many assumptions), so stipend-as-protection is deprecated: treat it as no protection. ETH via .call{value:}("") forwards all gas — fully reentrant. ERC-20 token.transfer() has NO stipend concept at all: plain ERC-20s (USDC-style) cannot call back, but ERC-777 hooks, ERC-1363, and any token with transfer callbacks hand control to the receiver, and a malicious custom token always can. So the answer: against known vanilla ERC-20s it's not exploitable; against ETH .call, callback tokens, or unknown tokens it is. Audit rule: never rely on the callee being benign — apply CEI or a guard regardless of which transfer flavor you see.

Give your agent this brain