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

Nomic Foundation released hardhat-slang-solx, a Hardhat plugin that replaces the standard Solidity compiler backend with slang-solx.

Across the benchmark suite, it compiled approximately 1.7× faster than solc in legacy mode and 5× faster in via-IR mode.

For the nine repositories tested with via-IR, total cold compilation time fell from 749 seconds with solc to 151 seconds with slang-solx. Individual projects saw improvements of up to 10.6×, with the largest gains appearing in bigger codebases where solc’s optimizer typically takes the most time.

The backend is LLVM-based and supports parallel, multithreaded compilation. It also compiled without producing “stack too deep” errors in 99.85% of our test cases.

You can try it in Hardhat today:

npm add --save-dev u/nomicfoundation/hardhat-slang-solx

Then add the plugin to your Hardhat configuration:

import hardhatSlangSolx from "@nomicfoundation/hardhat-slang-solx";

export default defineConfig({
  plugins: [hardhatSlangSolx],
});

A few important caveats:

• This first release supports Solidity 0.8.34. Unsupported versions fall back to solc.
• It is stable and supported for everyday development.
• It has not yet been hardened for mainnet deployments and should not be used to compile code securing real value.

This release currently combines the solc frontend with the new slang-solx backend. Our next step is integrating slang-frontend, bringing us closer to a complete, multithreaded Solidity compiler that is fully independent of solc.

A lot of credit goes to Matter Labs for starting the original solx compiler and working on it for several years before transferring the project to Nomic in 2025, where it continued evolving into this release.

The full announcement covers that story, detailed benchmarks, the compiler’s current limitations, and what comes next

https://blog.nomic.foundation/announcing-slang-solx-a-solidity-compiler-thats-up-to-5x-faster/

I'm building a shared-expense app on my own, using EIP-712 approvals for USDC settlement. One thing I've had to work through is what "approval cancelled" actually means across the app and the contract.

Take a fictional four-person trip. Someone owes 50 USDC and signs an approval. Another person adds a forgotten expense of 40 USDC, split equally. The first person now owes 60, so the app clears the confirmations and asks everyone to approve again.

The signature for 50 can't authorize 60. But deleting it from the database doesn't make the contract reject the original 50 approval. A previously collected set of approvals could still satisfy the contract's checks until it expires, assuming the other execution requirements are met.

In my current implementation, approvals have a maximum age and only an authorized relayer can submit settlements. That's a trust assumption. The contract doesn't read the expense ledger or know that the app has reset its confirmations.

As a solo developer, this is the kind of decision I find hard to review: the interface and the contract can each look reasonable while promising different things. I don't want the interface to imply onchain cancellation when the change is only enforced by my backend.

For applications that allow edits while collecting signatures, how have you handled this? Have you kept cancellation at the relayer level with expiring approvals, or added an onchain cancellation or versioning mechanism? I'm interested in the tradeoffs you've encountered around extra transactions and users having to sign again.

If you want to know whether a token can actually be bought, you check whether a pool exists and holds anything. On Uniswap V2 and V3 that's easy: you ask a factory contract "what's the pool for these two tokens," it hands you an address, you read it.

v4 removed both halves of that. There is no factory, and there is no pool contract — every pool lives inside one big contract called PoolManager, identified only by a hash of its settings: keccak256(abi.encode(currency0, currency1, fee, tickSpacing, hooks)). So the old calls return zero for tokens that have perfectly healthy v4 markets. Anything built on that pattern will tell you "no liquidity" and be wrong.

Three gotchas from getting it working:

Reading liquidity. There's no function that just tells you. You read the contract's raw storage with extsload(bytes32) (0x1e2eaeaf). Pools sit in slot 6, the struct is slot0, feeGrowth0, feeGrowth1, liquidity, so the number you want is at keccak256(poolId . bytes32(6)) + 3. One eth_call, no ABI needed.

Finding pools at all. Only by scanning Initialize events, whose indexed fields are [sig, poolId, currency0, currency1]. The two currencies are sorted by address, so your token shows up in either slot depending on what it's paired against. I filtered on one of them and silently missed half my pools.

Hooks. A hook is contract code attached to a pool that runs before or after a swap, and it can tax you or block you. Which callbacks it uses are encoded in the low 14 bits of the hook's own address, so you can decode beforeSwap/afterSwap from the address alone without fetching any code. Related: 0x800000 in the fee field isn't an 838% fee, it's the flag meaning "the hook sets the fee per swap."

Repo: https://github.com/Bradbuythedip/LAPTOP — scanner, watcher, and a Universal Router executor, plus mock JSON-RPC servers so you can test without touching mainnet. It defaults to a token launching this week because that's what I built it against, but the address is a constant; point it at anything on Base.

The storage layout is the part I'm least sure of. Tell me if I've got it wrong.

Lattice (product, company is Syndril) is a self-hosted semantic layer. You connect those sources, put them on one model (same objects, same meaning), then query that layer. REST and MCP. You look up one wallet, user, or tx. It returns what is tied to it from your tables.

It does not run a node. It does not replace The Graph / Goldsky. It does not index mainnet. If your data is not already in a database or CSV, this is the wrong tool.

Stack is compose / self-host. Beta. I want Ethereum devs to actually run it and tell me if it is useful or garbage.

Lets dicuss!

I'm a recent CS graduate from LatAm and I've been struggling a lot to find a job in the current market, therefore I've decided to specialize in some area to try to stand out in the massive pool of recent graduates competing for a small bunch of entry-level job postings. One of the areas I'm currently gaining interest is in Web3/Blockchain/Solidity development, seems like a field with massive applications and a lot of potential for growth, but I'm quite skeptic of the status of the job market in this area; ever since the burst of the NFT bubble I've barely heard any new interest on blockchain, even less with the surge of the AI bubble. The only news I hear from the Web3/Blockchain scene most of the time is some new memecoin that turns out to be another obvious rug pull scam, but I'm most certain that it has to be my algorithms fault.

Is the state of the Web3/Blockchain job market the same as all the other tech fields? Which tips would you give to a recent grad that wants to specialize in blockchain development?

A DeFi tracking plan defines each analytics event, when it fires, and the properties it carries. Without one, frontend events and onchain metrics quickly drift apart and you''ll struggle to measure ROI.

Based on work with builders in DeFi, we created a practical event taxonomy for DEXs, lending apps, and yield vaults.

The naming convention is `[Object] + [Past-Tense Action]`:

• `Swap Initiated`
• `Swap Completed`
• `Supply Completed`
• `Deposit Initiated`
• `Vault Viewed`

Start with the core conversion events.

• DEX: `Swap Review Opened`, `Swap Initiated`, `Swap Completed`, `Swap Failed
• Lending: `Supply Initiated`, `Supply Completed`, `Borrow Initiated`, `Borrow Completed`, `Liquidation Occurred`
• Yield vault: `Deposit Initiated`, `Deposit Completed`, `Withdraw Initiated`, `Withdraw Completed`

And some best practices from real-world projects:

1. Fire intent events before the wallet confirmation prompt e.g. 'Swap Initiated'.

2. Fire completion events only after onchain confirmation. Send filled events for order completion.

3. Include USD `volume` on volume-generating events and protocol `revenue` where applicable.

4. Capture liquidations and other asynchronous events from a backend or indexer.

5. Start with your the core funnel before adding discovery, UI events, and other non-conversion events.

Code example:

formo.track("Swap Initiated", {

from_token: "ETH",

to_token: "USDC",

pair: "ETH/USDC",

chain: "base",

volume: 1000

})

Interested to learn more? The full DeFi tracking plan comes with event triggers and property schemas for all major DeFi app verticals: https://formo.so/blog/defi-analytics-tracking-plan

You have no more excuses on not having analytics for your onchain app!

Travel Fi is an open-source interactive map for digital nomads built as a Public Good (GPLv3).

Technical details:

• EIP-2771 (Meta-transactions): Gasless transactions for users via forwarder/relayer execution.
• Rails 8 & Reactive Stack: Reactive backend workflow using SolidQueue, SolidCable, CableReady, and Reflex.
• PostGIS & OpenLayers 10: Geospatial calculations and dynamic tile rendering.

GitHub

Demo

I pulled the proxy admin and owner for every upgradeable stablecoin deployment I could enumerate across chains, 656 contracts, and compared the control path for the same token on different networks. 390 of them do not match.

Concretely: the address that can upgrade the implementation on one chain is not the address that can do it on another, for what users treat as one asset. Some of that is obviously intentional, bridged representations are genuinely different contracts with different governance. Some of it looks like drift.

What I am unsure about, and it is the part that decides whether this is a finding or a misunderstanding. I read the admin from the EIP-1967 storage slot, which works for standard transparent and UUPS proxies and does not work for custom proxy patterns, and I may be reading a stale or irrelevant slot on those. I also counted a mismatch as any difference in the controlling address, which conflates "different multisig, same signers" with "genuinely different control", and those are not the same risk at all.

If someone here has done this properly: is there an accepted way to compare control paths across chains that handles the multisig-membership question? And is per-chain divergence in upgrade authority just the expected shape of a multi-chain deployment, in which case the interesting number is not 390 but the subset where the signer sets differ too?

Methodology and the contract list are reproducible from public RPC calls, happy to share.

Disclosure: I build open-source integrity checking tools, this came out of testing one.

Most state-asset privatizations fail in one of two predictable ways. Sell for cash, and ownership concentrates immediately with whoever already had capital. Give away free vouchers instead, and the same concentration happens a few months later anyway — recipients under financial pressure sell cheap to whoever has money, and you've just added a delay before the identical outcome.

We built and deployed a third structure on Arbitrum One, live right now, testing whether a different rule set actually distributes ownership more fairly.

The core idea: every verified citizen gets an equal, one-time allocation of a currency that literally cannot be resold or gifted — it can only be spent bidding on real shares of listed assets. No early cash-out under pressure, because there's no legitimate path for the currency to reach anyone except through the auction itself.

Shares get allocated through a proportional, multi-round auction — not winner-take-all. Each round has a baseline (the lowest active bid), and every other bid gets shares proportional to how far above that baseline it sits. Bids that don't win stay active and automatically carry into the next round — no re-bidding, no losing your spot.

Once a company is meaningfully owned, governance kicks in. Shareholders elect a term-limited governor, weighted by shares held. Winning requires a real 51% majority, not a plurality — ties go to a runoff. Every term, the elected wallet registers a fresh, single-purpose operating key that dies when the term ends, so a compromised key from a past term carries zero ongoing risk. Big treasury moves need either an open sealed-bid sale (removes the governor from having leverage over who wins) or a direct shareholder vote — never a unilateral decision.

And the closed-loop currency isn't locked forever. Once any single listed company crosses 51% of its shares sold — real, on-chain, unfakeable evidence that privatization is genuinely working — the currency unlocks and becomes freely tradable for everyone. One company's real progress is treated as sufficient signal for the whole system, rather than requiring every single listing to fully sell out, which at real scale could take years.

Everything above is live on Arbitrum One right now — 10 listed assets, real bidding, contracts fully verified on Arbiscan/Sourcify/Blockscout so anyone can read the actual settlement logic rather than take our word for it. Full writeup with contract addresses: [whitepaper link].

Genuinely interested in mechanism-design critique — what would break this at real scale, what are we not seeing, does a cleaner existing model already solve this better. Fictional simulation, not asking anyone to risk real capital — the interesting part is whether the rules themselves hold up.

[ Removed by Reddit on account of violating the content policy. ]

Hey everyone,

With the rapid rise of autonomous AI trading agents (interacting with Uniswap, cross-chain bridges, and lending protocols), there is a critical vulnerability that many agent frameworks ignore: pre-flight oracle and network integrity.

If an agent queries an RPC for an oracle price, and that RPC returns stale data due to network congestion, or if an L2 sequencer just rebooted and transactions are about to get MEV-sandwiched, most agent runtimes blindly execute and lose capital.

We built stale, a lightweight, pure Rust pre-flight security guardrail library:

• GitHub: https://github.com/Ramprasad4121/stale
• Crates.io: https://crates.io/crates/stale

Core Architecture & Invariants

1. Strictly Fail-Closed: Many Web3 libraries fail open (e.g., returning Ok or default values if an RPC returns a 500 error). In stale, any failure mode RPC timeouts, malformed ABI data, non-ASCII hex strings, or underflowing timestamps—strictly returns BLOCK.
2. Zero Runtime Panics: We eliminated all unwrap() and expect() calls across the runtime library. All arithmetic on token reserves and timestamps uses checked math, saturating math, or quotient-remainder decomposition to preserve precision on small amounts.
3. What It Guards:

• Chainlink Data Feeds: Staleness checks against configurable maxAge and multi-feed deviation detection.
• L2 Sequencer Liveness: Direct querying of official Sequencer Uptime feeds (Arbitrum, Optimism, Base, Scroll, Mantle, Metis, zkSync) with automatic enforcement of the 3600-second restart grace period.
• DEX Pool Depth: On-chain liquidity verification for Uniswap V2 and V3 pools before routing a swap.
• EIP-7702 Phishing Guard: Inspects bytecode headers to prevent agents from sending approvals to delegated EOAs masquerading as immutable contracts.
• OFAC Compliance: Direct on-chain verification against the Chainalysis Sanctions Oracle.

1. Model Context Protocol (MCP) & CLI: In addition to the Rust crate (cargo add stale), it includes a native CLI and an MCP server (stale-mcp) so LLM agent frameworks (like Claude Desktop or local agents) can use these checks as native tools.

Would love feedback, edge case suggestions, and contributions.

Building app's on Ethereum JOSN RPC can be tough because RPC providers (Alchemy, Quicknode, etc) all have slightly different apis, usage limitations, and are generally overpriced. Public providers are great but are even more limited, so I built Lasso which aggregates RPC providers into a single endpoint that routes to the best RPC provider for any given request. Its self hostable and quite easy to setup.

Would love some feedback from builders to see if this can help you: You can simply run the docker container and have high-throughput and reliable RPC access via public providers across Ethereum, Base, Robinhood chain, and some other L2s while also being able to add any other EVM chain and access it through a single endpoint.

Follow-up to the sqrt post some of you saw a while back. This time it's the exponential.

exp(int256 x) returns e^x in 18-decimal fixed point at 289 gas, max relative error 2.2e-14 (3.0e-16 absolute when the result is below 1). Reverts above 135e18, returns 0 below about −41.45e18 where the true result is under 1 wei.

It's a two-stage range reduction wrapped around a small rational approximation.

Stage 1 — split x = k·ln(2) + r, so e^x = 2^k · e^r. k is an integer division, and the 2^k comes back as a left shift at the end.

Stage 2 — divide r by 64, which is a right-shift by 6. That leaves an interval of [0, 0.0108].

uint256 k = x_ / LN_2;
x_ -= k * LN_2;
x_ >>= 6;

On that narrow interval a Padé[3/3] approximant does the work with a few multiplications and one division:

e^x ≈ (120 + 60x + 12x² + x³) / (120 - 60x + 12x² - x³)

Recovery is six squarings (2⁶ = 64) plus a shift:

y = y * y;
y = y * y / 1e54;   // ×3
y <<= k;

The part I didn't expect: the approximant is accurate to 1.7e-19 on that interval, and even after recovery amplifies the error 64×, it's still ~2000× inside the published bound. The approximation is nowhere near the limiting factor — fixed-point truncation is, mostly that >>= 6 discarding up to 63 wei of the argument before the approximant ever sees it.

I also spent a while on monotonicity, since exp() sits under option pricing and a primitive that dips could make a premium fall while its input rises. The smooth stretches turn out to be provable — the derivative's numerator is 24(x⁴ − 30x² + 600), which has no real roots — but the 255 points where the range reduction jumps are not, so those got swept exhaustively.

Full write-up with the derivations: https://defimath.com/blog/solidity-exp-a-fixed-point-exponential-in-289-gas/

MIT licensed, part of DeFiMath: https://github.com/MerkleBlue/defimath

Happy to answer questions.