Solidity Treasures

Deploy at the same address on every chain, without shipping initcode.

Plain CREATE2 ties the deployed address to the init code hash, so any constructor change or compiler bump shifts your address across chains. CREATE3 breaks that link: the final address depends only on the deployer and salt, never on the bytecode. Deploy a minimal proxy via CREATE2, then have it CREATE your real contract, so the address is stable even if the contract itself changes.

createx packages this as a single deployed factory (same address on many chains) exposing CREATE, CREATE2, and CREATE3 helpers with salt guards against front-running and cross-chain replay.

One boundary worth knowing: with CREATE3 the constructor runs inside the intermediate proxy call, so msg.sender at construction is the proxy, not the factory or your EOA. Design initialization around that.

pcaversaccio/createx

@soliditypedia

An on-chain guard for AI-agent transactions moves the trust to whoever signs the attestation

A new draft ERC, IAgentTransactionGuard, proposes that an autonomous agent must present a proof-of-safety attestation before a call executes. The guard contract checks the attestation on-chain and reverts if it is missing or invalid, so the intent is a gate between an agent deciding to act and the action landing.

The mechanism is sound; the boundary is not the contract. An on-chain check can only verify that some attester signed off. It cannot verify the transaction is actually safe. You have relocated the problem from "is the agent trustworthy" to "is the attester trustworthy, live, and not the same key the agent controls." If the attesting service is compromised or lazily rubber-stamps, the guard passes malicious calls with a green light attached.

Before adopting a pattern like this: separate the attester key from the agent key, define what a revoked or stale attestation looks like, and treat a valid signature as authorization, never as a safety proof.

Ethereum Magicians: IAgentTransactionGuard draft

@soliditypedia

A generalized MEV bot beat the attacker to the rsETH exploit in the same block

When the exploit transaction hit the public mempool, a searcher's bot copied the payload, paid a higher priority fee, and landed first. Roughly 2,882 rsETH went to the front-runner's address instead of the original attacker.

The lesson for anyone testing an exploit or running a rescue: broadcasting a profitable, self-contained transaction to the public mempool hands it to every generalized front-runner watching. If the calldata alone extracts value, whoever pays the most gas wins, not whoever wrote it. Use a private relay (Flashbots and similar) for anything valuable, or design rescues so the recipient is fixed in the contract logic, not decided by who mines the block.

The Defiant

@soliditypedia

Public-mempool gas sponsorship can't have all three: no locked money, no off-chain trust, public relay

You want a contract to pay gas for someone else's transaction and have the public mempool relay it. The impossibility result: pick at most two of unlocked funds, no trust, and open relay.

The reason is timing. A relayer front-runs by broadcasting the sponsored tx and racing the payment. If the sponsor's funds aren't committed before relay, a griefer drains sponsorship without ever landing the intended call, or the payer can renege after inclusion. Nothing on-chain binds the promise at broadcast time.

So any working paymaster design pays for it somewhere: an escrow that locks funds per request, a slashable bond, or a trusted relayer you fall back on. ERC-4337's escrow model is the first branch made explicit.

ethresear.ch

@soliditypedia

A QEMU/KVM sandbox is not a boundary for a cyber-capable agent

Trail of Bits gave a frontier model a single task: escape the VM they normally use to sandbox untrusted code. It found and chained a hypervisor-level path out. The takeaway for smart-contract teams: the isolation you rely on when running agents against your codebase, fuzzers, or generated exploit PoCs is weaker than you assume.

If you let an agent execute code, treat the host as compromised by default. No shared secrets, no signing keys, no RPC creds on the same machine. Run it on disposable, network-segmented infra you can burn, and keep deployment keys on hardware the agent never touches.

The old mental model that a VM contains whatever runs inside it does not hold once the thing inside is actively probing for escapes.

Trail of Bits: VMs won't contain cyber-capable agents

@soliditypedia

This week in Solidity

Allbridge halted its core bridge after a $1.65M exploit: a $1.12M Kamino flash loan skewed its Solana stablecoin pools, and the profit was bridged out to Ethereum. Classic single-block price manipulation against pool-derived pricing. The Defiant

A compiler bug worth checking: require with a custom error using named-parameter syntax placed arguments on the stack in call-site order, not definition order, under the IR pipeline. If you use named args in require reverts, verify the error data. Solidity blog

Solidity v0.8.37 is out with the fix and other changes. Release notes

@soliditypedia

Two Solidity codegen bugs disclosed via the EF bug bounty

Both are silent memory corruption — no revert, wrong state.

delete on a memory bytes element clears a full word. Applying delete to an element of a bytes array in memory writes 32 zero bytes starting at that offset instead of zeroing the single byte. It stomps the following 31 bytes of adjacent data. Reported by shaheenfazim. write-up

Spill-slot collision across mutual recursion. The IR pipeline's stack-limit evader spills locals to fixed memory offsets. Under mutual recursion, two functions could be assigned the same offset, so one call clobbers the other's live variable. Reported by Ng Sze Hon. write-up

If you use either pattern, check whether your deployed bytecode was compiled with an affected version before you upgrade past it.

@soliditypedia

Delegate execution to a rotatable hot key, keep the cold wallet as root

ERC-8391 proposes a standard interface for splitting authorization from operation. You authorize a delegation contract once from a cold wallet or multisig; that root can then assign, rotate, or revoke an operational key without ever touching the integrating protocol again.

Why it matters: today most contracts bind authority to a single owner address. Rotating a compromised key means re-approving everywhere. With a delegation layer, the operational key is disposable — burn it and mint a new one, integrations stay pointed at the same delegation contract.

The hard part is scoping: an over-broad delegate is just a fancier hot wallet. Watch how the draft bounds what a rotatable key can call, and whether revocation is atomic.

ERC-8391 discussion (Ethereum Magicians)

@soliditypedia

Foundry v1.8.0 makes isolate mode and dynamic test linking the defaults

Two changes that alter how your suite runs, not just a version bump:

Isolate mode is now default. Each top-level call executes as its own transaction, so gas accounting and warm/cold storage costs match mainnet instead of collapsing into one frame. Tests that silently under-reported gas will shift.

Native symbolic testing (opt-in preview). Prove properties over all inputs, not just fuzzed samples — symbolic execution moving into the same harness you already run. Mutation testing lands alongside it to score how much your tests actually catch.

The language server (solar) is now embedded in Forge, and dynamic test linking speeds recompiles on large repos.

Re-run gas snapshots after upgrading: isolate mode will change the numbers.

foundry-rs/foundry v1.8.0
@soliditypedia

Skip the enumerable mapping: batch-mint NFTs without per-token storage writes

Most ERC-721 batch mints loop _mint, paying a fresh SSTORE for every token's owner slot. On a 20-item mint that's 20 cold writes just for ownership.

ERC721F takes the ERC721A-style approach: on a batch it writes the owner slot once, for the first id in the run, and leaves the rest empty. ownerOf(id) then walks backward to the nearest set slot to resolve the real owner.

The trade-off is explicit: minting gets cheap, but ownerOf and the first transfer of a token in a batch cost more (the read-time walk, plus initializing the slot on transfer). It also drops on-chain enumeration by default. Good default for large drops, wrong one if your contract reads ownership in hot paths.

github.com/FrankNFT-labs/ERC721F
@soliditypedia

RWA tokenization: the standards stack most demos skip

Most RWA repos stop at an ERC-20 with a whitelist. Real asset tokens need identity, transfer restrictions, and forced recovery baked into the token itself. QuillAudits' reference handbook maps the actual stack:

ERC-3643 (T-REX): permissioned transfers gated by an on-chain identity registry, so transfer reverts unless both parties hold a valid claim. Compliance lives in the token, not off-chain.

ERC-4626: the vault layer for yield-bearing wrappers over the underlying asset.

The hard part is the admin surface: forced transfers, freeze, and mint/burn for redemptions are power tools that widen your attack surface. Every privileged path needs its own access-control review, not a blanket onlyOwner.

Ships with Foundry code and an audit methodology.

Quillhash/Real-World-Assets-RWA
@soliditypedia

On-chain penalty enforcement, and the MEV vectors it opens

The DMQ framework makes "panic states" programmatically enforceable: penalties execute on-chain rather than living in off-chain policy. The author deployed it to Sepolia and collected real execution data instead of stopping at a model.

Why it matters: the moment a penalty is an on-chain state transition, it becomes an MEV surface. Anyone who can order, front-run, or trigger the enforcement tx can extract value or grief the penalized party. Proof-of-execution on testnet is exactly where these vectors show up before mainnet.

Takeaway: if your protocol enforces slashing or penalties on-chain, treat the enforcement path as adversarial ordering. Assume the trigger can be MEV'd and design for it (commit-reveal, private submission, or making the penalty ordering-independent).

ethresear.ch: DMQ Framework
@soliditypedia

Spending policies enforced by a ZK proof, not a trusted signer

Most wallet spending limits leak intent: the contract sees the amount, the recipient, the rule. ERC-8366 proposes a composable interface where any fund-holding contract — an escrow, ERC-4337 account, or EIP-7702-delegated EOA — releases funds only against a zero-knowledge proof that a policy was satisfied, without revealing the policy inputs on-chain.

The mental model: separate who may spend from under what constraints. A verifier checks a proof that (balance, limits, epoch) hold; the escrow never learns the private thresholds. Because it's a function set, one policy circuit can back many account types.

The hard part is nullifier and epoch design: without them a valid proof replays, letting a caller drain repeatedly under a spent limit. Treat the proof like a one-shot capability, bound to state, or the privacy win becomes a double-spend.

ERC-8366 draft
@soliditypedia

ERC-4337 paymasters that accept ERC-20s, signatures, or NFTs

OpenZeppelin Contracts v5.7 ships composable paymaster primitives, so sponsoring gas becomes a policy you write, not a bespoke contract.

The hard part in a paymaster is validatePaymasterUserOp: you must decide who to sponsor and how to charge, then reconcile in postOp after the real gas cost is known. The new base contracts split this into pluggable checks: an ERC-20 paymaster pulls token payment at that price, a signature paymaster verifies an off-chain grant, an NFT-gated one checks ownership.

Watch the postOp refund path: overcharge on validation, refund the delta after execution, or a reverting token transfer can grief the bundler. Test the postOpReverted branch.

OpenZeppelin Contracts v5.7
@soliditypedia

Uniswap v4 hooks move security into your code — and the defaults bite

Hooks let pools run custom logic on swaps and liquidity changes: dynamic fees, custom accounting, external calls. That flexibility relocates trust boundaries into hook code, and two real incidents (Cork, Bunni) show where it breaks.

The recurring failures Trail of Bits flags:

Access control: hook callbacks must reject any caller that isn't the PoolManager, and validate the pool key. Anyone can call your hook directly otherwise.

Reentrancy via the unlock pattern: v4's flash-accounting unlock lets external calls re-enter mid-settlement. Never assume balances are final inside a callback.

Arithmetic/rounding: custom accounting that rounds in the user's favor leaks value over many swaps — the Bunni-class bug.

Treat hooks as untrusted-by-default: authenticate the caller, guard reentrancy, round against the user.

Trail of Bits: Building secure Uniswap v4 hooks
@soliditypedia

OpenZeppelin 5.7.0 breaks EIP-712 domains that relied on long name/version

If your contract passes a name or version longer than 31 bytes to EIP712, upgrading to 5.7.0 will now revert in the constructor with ShortStrings.StringTooLong.

Earlier versions kept a storage fallback for values that didn't fit a ShortString. That fallback is gone: the domain is stored exclusively in immutables. Cheaper reads and a simpler _domainSeparatorV4(), but a hard failure mode for anyone who leaned on the fallback.

Before bumping: audit every EIP712(name, version) call. Long protocol names or semver strings with build metadata are the usual offenders. If you need a long name, hash it down or shorten before passing.

OpenZeppelin Contracts v5.7.0
@soliditypedia

Instant redemption is the wrong default for illiquid RWAs

Tokenize an asset that settles T+2 off-chain, then let it redeem instantly on-chain, and you have created a liquidity mismatch: the vault promises what the underlying can't deliver on demand. Two design responses are converging.

Async settlement: ERC-7540 splits redemption into request then claim, so the vault can honor real settlement windows instead of pretending everything is T+0. Centrifuge ran this across $1.6B+ in RWA pools before it landed as a reusable building block in OpenZeppelin Community Contracts.

Overcollateralization: a parallel ethresear.ch proposal hardcodes 200% collateral to absorb the redemption gap when instant settlement is unavoidable — trading capital efficiency for solvency guarantees.

Takeaway: match your redemption semantics to the underlying's settlement latency. If you inherit ERC4626 for an illiquid asset, you probably want ERC-7540's request/claim flow instead.

Centrifuge / OpenZeppelin · ethresear.ch
@soliditypedia

Pricing a prediction market on-chain with LMSR, no order book

A new ERC draft binds each binary (YES/NO) market one-to-one to an ERC-721: question, odds, pool, and resolution all live on-chain and render into the tokenURI. The interesting part is the pricing.

Instead of matching buyers and sellers, it uses Hanson's Logarithmic Market Scoring Rule. A single liquidity parameter b sets depth; the cost to move the market is the difference of a cost function:

C(q) = b * ln(exp(q_yes/b) + exp(q_no/b))
price_yes = exp(q_yes/b) / (exp(q_yes/b) + exp(q_no/b))

Any trade size gets a deterministic price, so there is always liquidity and no counterparty needed. The hard part on-chain is the exp/ln math: fixed-point implementations (PRBMath, ABDK) are mandatory, and overflow in exp(q/b) is the real footgun — bound q/b or the cost function reverts.

ethereum-magicians.org
@soliditypedia

Study real exploits by running them, not reading about them

Most exploit write-ups leave you guessing about the exact state and call sequence. The evm-hack-registry is a self-contained, offline-runnable archive of DeFi exploit proof-of-concepts spanning the full history of EVM hacks (2017 to 2026).

Each entry forks the pre-exploit state and reproduces the drain in a test, so you can step through the actual call trace, tweak balances, and confirm which invariant broke. Far higher signal than a post-mortem paragraph.

Practical use: before an audit, grep the registry for the class you're reviewing (reentrancy, price-oracle manipulation, unchecked delegatecall) and re-run the closest match against your own contract's assumptions.

github.com/sanbir/evm-hack-registry
@soliditypedia

Upgrading an EOA to a smart wallet without losing its address

EIP-7702 lets an EOA set code via a signed authorization, but you still need a storage layout that survives implementation swaps. Base's eip-7702-proxy is a minimal ERC-1967 proxy that delegates a plain EOA to CoinbaseSmartWallet, keeping the account's address and history intact.

Why it matters: the naive approach points the EOA directly at wallet logic, freezing you on one implementation and exposing you to initialization races. Routing through a 1967 proxy gives a stable upgrade slot and a controlled first-init path — the same discipline you already apply to contract upgrades, now for EOAs.

The subtle risk: an unguarded first delegation is front-runnable, so init authorization must be bound to the account. Read the proxy as a reference for that binding.

github.com/base/eip-7702-proxy
@soliditypedia