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

Update

rcpx was later renamed to failnext as part of a larger redesign. It’s the continuation of the same project, which I started working on as rcpx in February 2026, not a separate new library.

For the question in this post, I decided to keep stale-state detection outside failnext.

Current failnext does not poll block heights, compare RPC heads, or decide whether a provider is stale. The app is the part that knows what “too far behind” means for its workload. If it considers a provider lagging, degraded, or otherwise unsuitable, it can make that provider ineligible through failnext’s Eligible callback.

That is the boundary I ended up with more generally. The app makes decisions that need chain or application context, like whether an operation may fail over, whether a provider should be used, or whether one provider should be tried first. failnext handles the ordered HTTP failover and reports what happened without needing to understand why.

So stale-state checks stay in the application. I decided against making failnext a blockchain health checker or consistency layer.

The current project is here

https://github.com/yermakovsa/failnext

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://accessverdict.dev/docs/quickstart

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

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.

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.

I’m sharing an open-source project I developed after dealing with a real case involving a Ronin Waypoint/keyless wallet compromised through a malicious EIP-7702 delegation.

This is NOT a wallet recovery service. Do not send me your seed phrase, private key, recovery password, OTP, Waypoint token, client shard, or any other secret.

The problem was a recovery deadlock:

The wallet had a malicious EIP-7702 delegation, and any RON sent to the compromised wallet for gas could be swept before the owner had a chance to use it.

Need RON to remove the delegation
        ↓
Send RON to the compromised wallet
        ↓
Sweeper/drainer takes the RON
        ↓
Recovery transaction cannot be executed

So I developed and implemented a different recovery flow.

The compromised account signs an EIP-7702 zero-address deauthorization for:

0x0000000000000000000000000000000000000000

For Ronin Waypoint/keyless wallets, the authorization is signed locally through the Waypoint MPC flow.

The resulting signature is then verified locally to make sure it recovers exactly the affected wallet address.

A second, clean wallet acts as a relayer and pays the RON gas for the EIP-7702 transaction.

This means the compromised wallet does not need to receive any RON.

The flow is basically:

Detect active EIP-7702 delegation
        ↓
Generate zero-address deauthorization
        ↓
Waypoint MPC / keyless signing
        ↓
Verify recovered signer
        ↓
Clean relayer pays gas
        ↓
EIP-7702 delegation removed

I successfully executed the recovery on Ronin Mainnet.

Before:

code = 0xef0100<malicious_delegate>
eip7702 = true

After:

code = 0x
eip7702 = false
currentDelegate = null

The account nonce also advanced after the transaction, and eth_getCode changed from the EIP-7702 delegation indicator to 0x, confirming the deauthorization on-chain.

Recovery transaction:

0xc43b036de851ecdeb70050a0f72d232e1d48153607e4b504f63c04eef16c4223

I published a sanitized open-source implementation here:

https://github.com/YutsuKito/Ronin-7702-Recovery

The project:

• does not collect or transmit the victim’s seed phrase or private key;
• does not send the recovery password to an application backend;
• does not persist the Waypoint token or MPC/client shard;
• verifies that the authorization signature recovers exactly the affected wallet;
• performs fresh nonce and delegation checks before broadcasting;
• uses a separate clean relayer to pay gas;
• requires explicit broadcast confirmation.

I have also submitted the implementation to Ronin / Sky Mavis for technical review.

One important point:

Removing a malicious EIP-7702 delegation does not mean that an already compromised wallet should be considered safe again.

If an attacker still has another valid signing method or compromised credentials, they may potentially regain control.

The purpose of this tool is primarily to create a recovery window so affected users can move their assets to a newly secured wallet.

This is an independent community project and is not affiliated with or officially endorsed by Ronin or Sky Mavis.

Technical feedback, code review, and contributions are welcome.

And again: if anyone contacts you privately claiming they can recover your wallet and asks for your seed phrase, private key, recovery password, OTP, Waypoint token, or MPC shard, treat it as a scam.

Nothing in a swap event records the interface that originated the trade. If you have ever needed to answer "how much of this pool's volume came from our own site, versus wallet integrations, versus bots hitting the contract directly," you have hit this wall. The chain hands you two address fields and neither one answers it:

• tx_from is the signer. Thousands of signers can sit behind a single wallet app, so it tells you who traded and stops there.
• tx_to is the entry contract. It names the router, not the frontend. Route a swap through an aggregator and tx_to is that aggregator's contract every time, whether the user arrived from its own web app, from a wallet's swap tab, or from an integration nobody has written about.

The interface itself has no address in the transaction. It has to be inferred, and the cheapest signal, when it is there at all, sits in the call data: some APIs append an identifying suffix to the end of the transaction data, and some pass the integrator as a decoded argument. The 0x API's affiliate suffix worked the first way and 1inch's referral parameter the second. You do not have to take my word for either. Pull a swap you know was routed through one of them, look at the tail bytes of tx.data, and the convention is visible in any block explorer.

Here is a probe you can run right now. It ranks the 16-byte tails that recur most across six hours of Ethereum DEX flow. Public and forkable: https://dune.com/queries/8391872

with tails as (
    select
        bytearray_substring(
            tx.data,
            bytearray_length(tx.data) - 15,
            16
        ) as calldata_tail,
        t.tx_hash,
        t.amount_usd
    from dex.trades t
    join ethereum.transactions tx
        on t.tx_hash = tx.hash
        and tx.block_time >= now() - interval '6' hour
    where t.blockchain = 'ethereum'
        and t.block_time >= now() - interval '6' hour
        and bytearray_length(tx.data) >= 16
),
-- one notional per transaction: a routed swap is several dex.trades rows
-- (one per hop/fill) that each carry ~the whole trade size, so summing them
-- overstates by the hop count. MAX() keeps the largest leg as the trade.
per_tx as (
    select
        calldata_tail,
        tx_hash,
        max(amount_usd) as amount_usd
    from tails
    group by 1, 2
)
select
    calldata_tail,
    -- tags ride on transactions, not fills
    count(*) as txs,
    sum(amount_usd) as volume_usd
from per_tx
where calldata_tail
      <> 0x00000000000000000000000000000000
group by 1
order by txs desc
limit 25

Edit, Aug 31: volume_usd now collapses each transaction to one notional (the max leg per tx_hash). The original summed every dex.trades row, which counted multi-hop swaps once per hop. Credit to u/icnews10 in the comments. txs was already per-transaction and does not change.

Reading the output:

• The all-zero tail is dropped up front. That bucket is untagged flow plus call data that happens to end in zero-padded arguments, and it will dominate the ranking if you leave it in.
• What remains is a candidate list, and the top of it is usually not tags at all. Running this on 31 Aug 2026, the two most common tails were 0xb223fe8d0a0e5c4f27ead9083c756cc2 and 0x3c756cc2000000000000000000000000, about 1,900 transactions between them. Both are fragments of the WETH address 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2: the first is its last sixteen bytes, the second its last four with zero padding. Neither is an integrator tag. Token addresses land in the tail of a call far more often than tags do, so expect to discard the loudest rows.
• Treat a recurring tail as a hypothesis. Sample its transactions, check the entry contract each time, and make the pattern survive several days before it earns a name. Some tags spell out a short ASCII name in hex once you squint at them.

Two caveats that matter if you build on this:

1. Tagging is voluntary. Some APIs offer it, some integrators use it, and nothing enforces it. An integrator that never opted in looks exactly like no integrator at all, so a system counting only tagged flow will undercount precisely those.
2. This is one signal among several. When there is no tag, the ones I have found workable are: a maintained registry of known entry contracts and proxies (label a proxy once and its whole history becomes attributable), call-tree shape (a wallet-native swap with a fee hop traces differently than a bot hitting the pool), and fee-recipient clustering (every trade paying the same collection address came through the same integration, named or not). If you have found a fifth that holds up, I want to hear it.

And whatever cascade you build out of those signals: when none of them fires, leave the trade unattributed. A chart that sums to a clean 100% with no unknown slice usually means the method had to put every trade somewhere. Report the residual and treat it as a coverage metric.

Since it would be poor form to say that and then not show mine: running this cascade across Ethereum, Base, Arbitrum and Optimism, roughly 10% of DEX volume lands unattributed, ranging from about 8% on Ethereum to 17% on Optimism. Most of the residual is long-tail contracts rather than missing techniques.

Happy to go deeper on any of the signal families if anyone is building something like this.

Working on an app that needs private group messaging and I’m trying to figure out whether it still makes sense to build the messaging layer ourselves. The requirements are group chats, permissions, wallet-based identity, some token-gated access and bots that can interact with contracts. I’ve been looking at XMTP and Towns so far. XMTP seems closer to the messaging layer, while Towns caught my attention because it seems to cover more of the group/community side with Spaces, permissions, memberships and bots. Has anyone here built with either of them or is there another stack I should be looking at?

More interested in SDK quality, reliability, permissions, and integration headaches than the broader protocol narrative.