Solidity Treasures

Big congratulations to the @zksync airbender team for this milestone. At this point, I consider the battle for speed to be definitively won, and the top priority for zkEVMs should shift fully to security. To me that means formally verifying (i) equivalence of the arithmetization to the ethereum spec Big congratulations to the @zksync airbender team for this milestone. At this point, I consider the battle for speed to be definitively won, and the top priority for zkEVMs should shift fully to security. To me that means formally verifying (i) equivalence of the arithmetization to the ethereum spec (ii) a hard maximum bound on (prover cost) / (amount of gas in block) (iii) security o Read more @soliditypedia

ERC-8421: Frame Transaction Alternative Mempools A Frame Transaction specific definitions for alternative mempool rules, similar in structure and mostly backward compatible with the ERC-7562 validation rules for ERC-4337 UserOperations. In the context of EIP-8141 serves as a more permissive, reputation-based system compared to the ‘canonical mempool’ defined as part of the core protocol. Conceptually, the “reputation” system of ERC-8421/E Read more @soliditypedia

Private Stablecoin on Ethereum The full paper: Private-StableCoin-On-Ethereum/private-stablecoin-on-ethereum-en.pdf at 636c0e72bbc4e14cdc59d4b88bf9f563847e5c9f · PLabs4/Private-StableCoin-On-Ethereum · GitHub Ethereum’s programmability makes it possible to issue stablecoins with built-in privacy backed by USDC/USDT. A privacy stablecoin protocol on Ethereum can offer: Trustless issuance: minting and redemption are enf Read more @soliditypedia

Accountability for Encrypted Mempools Accountability for Encrypted Mempools Authors: Aditi Partap , Arantxa Zapico Introduction The prevalence of sandwich attacks on Ethereum highlights a fundamental vulnerability in public mempools: because pending transactions are visible to all participants before inclusion, block proposers and searchers can strategically reorder them to extract value. Encrypted mempools aim to reduc Read more @soliditypedia

🧪 Sepolia gets Glamsterdam today. Beyond the 200M gas-limit target, there are several changes worth testing: - Bigger contracts 👏: runtime bytecode limit increases from 24 KiB to 64 KiB; initcode from 48 KiB to 128 KiB. - Different gas accounting: state creation is metered separately from execution. The surprising part: gasleft() can increase when state gas is returned. Code calculating gas usage with beforeGas − gasleft() needs another look. EIP-8037 - Native ETH transfer logs 👍: including internal transfers. Wallets and indexers can track ETH movements without relying on execution traces. EIP-7708 - Deeper stack access: DUPN, SWAPN and EXCHANGE give compilers more flexibility. Practical benefits depend on toolchain support. EIP-8024 - SLOTNUM: contracts can read the consensus slot directly. EIP-7843 Source @soliditypedia

EIP-TBD: Resolution — Non-Self-Authorizing State Transitions There is a common authority boundary showing up across recovery, agents, provenance, adjudication, and cross-standard composition that is worth defining directly. Anything Ethereum can define, it can put behind Resolution. Resolution is the transition between something being produced or proven and that thing acquiring authority to change consequential state. The minimum distinction is: COMPU Read more @soliditypedia

Uniswap Token Launcher Audit Summary Read more @soliditypedia

OpenZeppelin Brings Its Security Standard to the TRON Network OpenZeppelin is expanding its smart contract libraries and secure development suite to TRON. Teams can now build on audited foundations and familiar tooling, giving TRON developers instant access to production-grade security out of the box. Read more @soliditypedia

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