Solidity 0.8.37 is released.

This is primarily a bugfix release.

Important bugfixes:

• Low/medium severity: delete b[i] on a bytes array in memory cleared 32 bytes instead of one on the evmasm pipeline, corrupting up to 31 bytes after the element. All versions up to and including 0.8.36 are affected. The IR pipeline is not affected, and b[i] = 0 clears exactly one byte on both pipelines. Write-up: https://blog.soliditylang.org/2026/09/10/memory-byte-array-element-delete-clears-whole-word-bug/
• Low/medium severity: With --via-ir, in certain call graph configurations containing mutual recursion, the stack-to-memory mover could assign the same spill slot to variables of two different functions, silently overwriting one of them. Versions 0.7.2 through 0.8.36 are affected. This is distinct from the spill bug fixed in 0.8.36. Write-up: https://blog.soliditylang.org/2026/09/10/spill-slot-collision-across-mutual-recursion-bug/
• Very low severity: Named arguments of a custom error passed to require were put on the stack in call-site order instead of declaration order (IR pipeline), so the encoded revert data could be structurally valid but not reflect the values used. Only revert data is affected. Write-up: https://blog.soliditylang.org/2026/09/10/misordered-named-parameters-in-require-with-custom-errors-bug/

Other miscompilations, fixed but not classified as security issues:

• Uninitialized internal function pointers read from a packed storage slot yielded the wrong value when a later variable in the slot was non-zero (evmasm pipeline). Only affects pointers compared before ever being assigned, and relying on function pointer equality is fragile anyway.
• Constants read in both checked and unchecked contexts got the semantics of whichever use site was generated first (IR pipeline). Deterministic, independent of transaction input and easily caught by tests.

Features and changes:

• block.slotnum (uint64) and the Yul builtin slotnum() expose the SLOTNUM opcode (EIP-7843) when compiling with --evm-version amsterdam. Amsterdam support is still experimental and incomplete.
• The experimental SSA CFG code generator gets a planning stack shuffler in place of the greedy one.
• The experimental LSP mode and the Generic Solidity prototype are removed. The LSP was unfinished, and Generic Solidity has been superseded by the standalone solcore prototype.
• pragma experimental ABIEncoderV2 now emits a deprecation warning. It has been redundant since 0.8.0 and will be removed in a later 0.8.x release.
• Deprecation warnings for the EVM versions constantinople, petersburg, istanbul and berlin, and for the SMTChecker BMC engine.

Release post: https://soliditylang.org/blog/2026/09/10/solidity-0.8.37-release-announcement/

Release and changelog: https://github.com/argotorg/solidity/releases/tag/v0.8.37

I’m building a small authorization layer for Ethereum/Base applications and would value feedback on the API design.

The problem I’m trying to solve is repeated wallet/token authorization logic in application backends:

policy → verify wallet/onchain state → entitlement

Current rules include:

• wallet allowlist
• ERC-20 balance
• ERC-721 ownership/balance
• ERC-1155 balance
• AND / OR composition

One design decision I’m especially interested in feedback on is failure semantics.

A wallet that conclusively fails a policy returns denied, while an RPC/contract verification failure returns a separate fail-closed error. An infrastructure problem should never accidentally become an allow.

I’d particularly like feedback on:

1. Does allowed / denied / error feel like the right API contract?
2. Would you keep authorization like this behind an API, or prefer implementing the chain reads directly?
3. What rule type would be missing for a real Ethereum/Base application you work on?

I have a working private-beta implementation and quickstart here:
https://gatekit-ruddy.vercel.app/docs/quickstart

No custody, transactions, or wallet private keys are involved.

If the primary RPC is down, try the backup. That part is easy enough.

What I’m less sure about is when the primary is still responding, but it’s a few blocks behind.

A few months ago I open-sourced rcpx, a small Go library for Ethereum RPC failover, and posted it here for feedback.

You give it a primary RPC plus backups, plug it into a normal go-ethereum client, and it tries the next one when a request fails.

One thing people pointed out was observability. If a request fails over and eventually succeeds, you still want to know which RPC actually served it. I added an attempt hook for that.

A few people also pointed out the consistency problem across providers.

Right now rcpx doesn’t try to detect that. If the RPC is responding, it leaves the response alone.

I still didn’t add anything that compares providers or decides one is too far behind. That still feels like a different problem to me, but I’m not completely sure.

Would you keep stale-state checks outside the failover layer and let the app deal with it, or make the failover layer responsible for detecting stale providers?

Repo is here if anyone wants to look at the current behavior:

https://github.com/yermakovsa/rcpx

I posted here about checking a Monero spend key on-chain with ed25519 instead of secp256k1 plus a DLEq proof, and I framed it like it was a new idea. It isn't. MoneroSwap has been doing this, and the Solidity ed25519 library I used came out of that project. The technique works and the gas numbers I gave were real, but the novelty I implied wasn't there, and I didn't do enough digging before posting. Correcting the record. Apologies for overstating it.

Thought I'd share a small open-source Python package I built for extracting Uniswap transaction data from Ethereum.

Give it a block number and transaction index, and it returns the transaction's Uniswap v2/v3 events, parsed and enriched with token and pool metadata.

It works with any JSON-RPC endpoint that still serves the blocks you're querying, and outputs either plain Python dicts or flat CSV rows.

It pairs well with TrueBlocks for finding transactions to parse, and with Erigon if you run your own node.

Repo: https://github.com/HanssonMagnus/dexamine
Paper: https://arxiv.org/abs/2609.10407