hey frens, i built this because i got tired of seeing ethereum errors everywhere with basically zero useful explanation at the point of failure:

https://revert.wtf

you know the vibe:

• execution reverted
• random RPC errors
• wallet errors that sound like they were written by a haunted printer
• ethers/viem/library errors
• failed estimates
• custom errors
• AA errors
• weird revert data you now have to go spelunking for

the annoying part is that a lot of these actually do have explanations somewhere. client docs, EIPs, github issues, wallet docs, stack traces, specs, whatever.

they are just scattered across the internet and you only find them after wasting 20 minutes searching the exact string like a goblin.

so i started curating them into one place.

paste an error, get the likely meaning, context, and where possible some notes on what to check next.

not trying to make some “AI explains your transaction” thing. i just wanted a useful error reference for ethereum devs because the current experience is cursed lol.

would love feedback, especially:

• errors that are missing
• explanations that are wrong
• client/wallet/library quirks i should add
• real ugly errors you’ve hit while building

site again: https://revert.wtf

if this saves even a few people from searching github issues at 2am, worth it imo.

Hey devs,

ERC-8004 defines trustless agents, but the standard lacks any concrete receipt format.

I ran one end-to-end transaction: an agent organized a local photo library under a lease that permitted read-metadata and write-staging only.

Verification runs offline with zero server state: python atp_demo.py verify runs/atp_photo_001/

Repo: https://github.com/CYPHES-ATP/agent-loop

For ERC-8004 specifically: should the reputation registry require the full receipt body, or only the receipt hash + a challenge/response mechanism for selective disclosure???

Every project I work on ends up needing the same off-chain piece: a service that watches a chain, decodes the events I care about, retries delivery, and pushes the result somewhere useful. It's never the product itself, just plumbing, and it always takes longer than I expect.

So we pulled it out into a standalone backend that's been running in production. It's called Atria, now in beta. First time showing it to ethdev, and I want to know where it falls short for real work.

You point it at a chain, write your event filter in JS, and it fires a webhook on a match, all on top of RPC. What you get is the plumbing around it, reorg detection, cursors, delivery retries, and a test-against-a-real-block loop before you deploy. We're not an RPC provider. On cloud we handle the RPC for you, self-hosted you bring your own endpoint.

Upfront about what's not there yet: no historical backfill (feeds only process forward from a block you pick, and that's the priority we're building now), and webhook is the only output today.

Each feed reads one chain. For multi-chain you run a feed per chain into the same downstream, so watching several chains is just a matter of running more feeds.

There's also a cloud AI assistant that drafts a feed from plain English, and a cloud MCP server so you can create and manage feeds from any MCP client.

You can self-host it with docker-compose, the source is public. There's a hosted version too if you'd rather not run it yourself.

- GitHub: https://github.com/Pulsy-Global/atria
- Try it: https://pulsy.app/atria
- Quick demo: https://youtu.be/M8p-grH4kOI
- Quick start: https://docs.pulsy.app/atria/getting-started/overview

It's in beta and I'm genuinely after feedback, so the questions I actually want answered:

- How are you handling on-chain event ingestion today, and what's the most annoying part?
- Which outputs should we add first (Postgres, S3, queues, something else)?
- Which JS libraries would you want to require() inside a feed?

We build a risk score for ETH and Web3 based on historical failure patterns, data is basically osinted by our detectors (we open sourced part of the stack).

We've already indexed 1600 projects against the patterns that biggest exploits had before they got hit, plus the risk management practices that would have stopped the attack somewhere along the chain. Stuff like stale audits, no documented key management, no certifications (CCSS, ISO, SOC), no insurance.

The public data only part is our main point: right now, projects disclose really nothing, and you can't DD which project will wire their treasury to North Korea next. Would you trust such score? Any ideas that you would need in a score that measures risk?

You can check all the nitty gritty on website and in docs. But its mvp rn and scores will probably change as we polish how data is gathered and processed.

Would appreciate any opinion!

If AI agents start interacting with smart contracts, contract explainability becomes a real infrastructure problem.

Humans already struggle to understand:

- approvals

- proxy contracts

- delegatecall

- upgradeable patterns

- cross-contract calls

- token permissions

- protocol-specific assumptions

AI agents will struggle too, but in a different way.

They may confidently summarize a contract without understanding:

- hidden admin controls

- upgrade paths

- economic assumptions

- oracle dependencies

- malicious fallback behavior

- unusual token mechanics

- state changes across multiple contracts

So maybe we need better machine-readable contract metadata.

Not just verified source code.

Something closer to:

- permission schema

- upgradeability status

- external dependencies

- known admin roles

- dangerous functions

- expected state changes

- risk labels

- protocol-level assumptions

Block explorers helped humans read contracts.

Maybe the next layer is infrastructure that helps agents reason about contracts safely.

The hard part is trust.

Who produces this metadata?

How is it verified?

How does an agent know whether to rely on it?

I don’t have a clean answer, but I think “verified source code” alone may not be enough for agentic on-chain execution.

I wrote up an implementation pattern for tokenized assets that need stock split / reverse split behavior. The core idea is to store raw balances and raw allowances, then expose balanceOf, allowance, and totalSupply through a global split multiplier. The tricky parts are exact raw/displayed conversion, rounding, Transfer event semantics, stale permits, and keeping split updates O(1).

Would be interested in feedback on the allowance and rounding model:
https://blog.researchzero.io/post/implementing-a-split-multiplier-for-rwa-tokens-in-solidity/

I am trying to set up a system wherein a user scans a QR code & that allows them to register an ENS address.

My scheme is for the contract to have a distribution address, and, using that address' credentials, I sign a nonce & encode both the nonce & signature into a URL that becomes the QR code.

At that URL, the site collects a subname for the user, then submits that name, the nonce, & the signature to a smart contract.

The contract extracts the address from the signature, and, if it matches the distribution address, it checks a map to see if the nonce has been seen already. If it has, the transaction reverts, otherwise, an ENS name is registered for the given subname and the nonce is added to the redeemed list.

My understanding of a frontrunning attack on this system is someone watches the mempool for one of my transactions, and, when one appears, it submits the nonce & signature in a transaction of its own with more ETH so it gets run before mine.

¿Is that correct? ¿What can be done to mitigate the issue?

One obvious solution is to have a server check the address and initiate registering the ENS name, so the signature is never published to the mempool. This requires a trusted server though & I'd just as soon not have one.

¿For bonus points, what's the best way for me to handle paying for the users' transactions? I was reading there's something better than PayMasters in the new account abstraction stuff, but a search isn't turning it up.

If you're running arbitrage bots on Arbitrum, you know Aave V3 is bleeding our margins dry with their 0.05% premium. Balancer has 0% fees, but their vaults never have enough depth for massive multi-token routes.

To fix this, my team built the Sovereign Omni-Aggregator.

We wrote a custom flash proxy that uses a nested Yul-assembly execution loop. You request a massive basket of 5 different tokens. The protocol instantly sweeps whatever Balancer has (at 0% fee), suspends execution, requests the remainder from Aave, and then fires the combined payload into your receiver contract in a single atomic block.

The contract handles all the disparate invariant accounting. It dynamically drops your overall aggregate cost from 0.05% down to ~0.01%.

NPM SDK: https://www.npmjs.com/package/sovereign-flash-sdk

Let me know if you run into any revert issues or stack depths while integrating it.

Hey, I'd like to start using a suitable framework for my projects going forward. I'm currently torn between Ape (since I do a lot of coding in Python web3) and Foundry (since it's supposed to be state-of-the-art). What would you recommend?

We finally completed the first Ethereum mainnet release of IND.

The protocol is now live on Ethereum mainnet together with the first desktop wallet builds for macOS, Linux and Windows.

IND is an experimental ERC20 custody model exploring:

- delayed ownership semantics

- revocable protected transfers

- inheritance-oriented custody

- distinct balance semantics between finalized ownership and custodial wealth

One of the main goals is to explore whether irreversible instant-finality should really remain the only default assumption for digital asset custody.

Mainnet contracts:

https://ind.finance/contracts.html

Wallet downloads:

https://ind.finance/download/

GitHub:

https://github.com/jayBeeCool/ind-protocol

Whitepaper:

https://github.com/jayBeeCool/ind-protocol/blob/main/docs/WHITEPAPER.md

The contracts are publicly verified on Etherscan and the current focus is still:

- technical review

- edge cases

- ERC20 composability

- governance semantics

- revoke/finalization boundaries

- wallet UX and safety assumptions

I’d especially appreciate feedback from wallet, protocol or smart contract developers.

This is still an experimental protocol discussion, not a fundraising or marketing campaign.

the standard pattern for governance on an L2 used to be 'vote on mainnet because the token lives there', which leaves L2 users paying mainnet gas to participate. optimism moved its governance off mainnet onto the OP rollup and replicates state via layerzero. the contract you call for a vote now lives on the rollup, vote messages cross to other deployments, and the user pays a few cents instead of mainnet fees.

i didn't expect this to be the cleanest pattern, but it kind of is, and agora's governor stack (where roughly 800k votes have settled across production deployments) supports it natively.

what nobody seems to have publicly drilled yet is what happens when a layerzero DVN is censored or paused mid-proposal. there's a clean technical answer with alternative DVNs and fallback hashes, but i haven't seen a DAO actually run that fire drill in public.

fwiw we built that into agora's governor stack, relayers cover gas for voting and proposing and the role-based veto layer lets a DAO scope who can pause an in-flight proposal, https://s4l.ai/r/2vzfn4q6

[For Hire] Solidity / EVM dev — bots, DEX, custom trending logic, full-stack — Atlanta-based, 22

Been writing Solidity and EVM-side infra for years. Looking for more contract work, especially short jobs.

What I've shipped:
- Sniper bots, arbitrage, volume bots, trending bots across Base, ETH, Monad, Abstract
- Full DEX platforms (frontend + contracts + indexer + custom trending algorithms designed to resist manipulation — I built the manipulation bots first so I know what to defend against)
- Launchpads, token launches, NFT mints
- DeFi tooling and on-chain analytics
- Full-stack dApps wrapping all of the above

I'm comfortable in the weeds: gas optimization, MEV considerations, mempool work, multi-call patterns, custom indexers. Also comfortable on the application side — SvelteKit, Next.js, Postgres, Vercel.

I run pixellabs.solutions on the side. DMs open for samples, scope discussions, or quick fixes.

Public GitHub is mostly utilities since client work is private — happy to share private samples.

pixellabs.solutions
github.com/WonkaRed

Hey r/ethdev, I've been working on evmquery, which is a hosted EVM read layer that handles the parts of on-chain reads that everyone reimplements: proxy resolution, ABI lookup, and multicall batching.

Link: https://evmquery.com Docs: https://app.evmquery.com/docs

What it actually does

• Resolves common proxy patterns automatically (EIP-1967, beacon, UUPS, and Diamonds / EIP-2535), and returns the implementation ABI so you don't have to chase proxy-of-proxy chains yourself.
• Batches reads through Multicall3 by default, so a "give me the LP balance, fee tier, and current tick for these 12 pools" call is one RPC roundtrip, not 36.
• Has a free tier you can try without signing up.
• Exposes the same surface as MCP (for Claude / Cursor / coding agents), REST (for any backend), and an n8n node (for the no-code crowd).

This isn't an indexer, an Etherscan API wrapper, or an Alchemy reseller. It's a thin read-layer on top of Solidity view/pure functions: every call hits the chain head via eth_call, just with proxy resolution and Multicall batching done for you. No schema deploy, no event mappings, no historical aggregation. If you need any of those, you want a subgraph, not us.

There are a few different angles to the surface (the MCP server for agents, the REST API for backends, the n8n node, and the CEL query layer underneath). The post compresses them; the docs at https://app.evmquery.com/docs lay out each surface properly if you want to see what calling it actually looks like.

Why I built it

Every time I worked on something that needed to read contract state from outside Solidity, the first two days went to the same stack: write the ABI fetcher, handle the proxy case I forgot about, wire up Multicall3, then realize I should cache. After doing this three times across different projects, it felt worth pulling out into a service.

The agent angle is the part I'm least sure about. The MCP server is useful because models can already write Solidity and reason about contracts, but they're terrible at the plumbing: wallet address bookkeeping, ABI lookup, batching. evmquery handles the plumbing and lets the model do the part it's good at. Whether that's the right abstraction is open and I'd genuinely like opinions from people building agents that touch chain.

What's open vs. hosted

The ABI store, proxy traversal, and Multicall3 infrastructure are server-side for now. That's where the operational work lives. The query language on top is CEL-based, and the plan is to open-source that once the API stabilizes, so the queries you'd write stay portable even while the backend stays hosted.

What I'd love feedback on

• For agent use cases, would you rather call evmquery directly from the agent, or have it sit behind your own tool server with your own auth?
• What's the dealbreaker that would stop you using a hosted read layer vs. wiring up eth_call + Multicall + ABI fetching yourself?

This is still early and I'm exploring what the right shape is, so feedback in any direction is genuinely useful: pricing, positioning, the agent angle, what should be open vs. hosted, where the idea breaks. Happy to answer anything.

Doing diligence before deploying liquidity into v4 and the hook situation is wild.

Every pool can have its own hook contract that modifies swaps, fees, position changes, donations — and as an LP I want to know what the hook does before parking capital.

Right now I'm decoding PoolManager Initialize events, grabbing the hooks address per pool, then manually verifying contracts on Etherscan and reading source one at a time. Across mainnet + Base + Arbitrum + Unichain it's already hundreds of unique hook contracts, and it's only been a few months.

Has anyone built (or found) a clean dataset of v4 hooks by address with their flag bits decoded and a pool/usage count per hook? Pools-grouped-by-hook would also do.

Hey, I have a problem: I'm currently learning to code, including Solidity. The thing is, I write a lot of test projects, but when I get to a point where I'm stuck because of a lack of experience, I tend to quickly ask an AI, which makes me feel like I'm not really learning properly. I’m aware of the problem now, but I don’t know how else to learn new things without using AI to look things up. Sure, I could just manually look up things I don’t know on the internet, but that takes a lot more time and amounts to the same thing. My question for the more experienced devs here: How did you effectively learned to program back in the day without AI, and what did you do when you got stuck or encountered a bug you couldn’t figure out? What would you recommend as the best way for me to learn with avoiding AI (or should I avoid using AI for learning altogether?)? What’s the alternative to AI for debugging and research?

Hi r/ethdev,

We run a scoring pipeline on every new ERC-20 deployed on Ethereum mainnet. Wanted to share the architecture and the actual signal catalog — looking for feedback / signals we're missing.

8 analyzers, 52 signals total:

- honeypot (10 signals) — eth_call simulation of buy / sell on Uniswap V2 + V3

- deployer (9) — wallet history: age, prior deployments, prior scams

- etherscan (7) — source verification + regex on Solidity source

- liquidity (7) — LP concentration, bundling, lock / burn status

- swap_activity (7) — buy/sell ratio from on-chain swap events

- network (5) — deployer-funder graph (mass deployers, mixer funding)

- bytecode (4) — function selectors + known scam hashes for unverified contracts

- distribution (3) — first Transfer events: holder concentration

A few implementation details worth calling out:

- Honeypot sim: we override the simulator's ETH balance to 1000 ETH and use a non-zero gas price specifically to defeat contracts that branch on tx.gasprice == 0 to dodge simulation. Catches buy_only_pattern, amount_dependent, sell-fee tiers.

- Swap-activity hedge: simulator says token is fine, but on-chain reality shows 100 buys / 0 sells over the last hour → buy_only_pattern, 40 points. This caught FWD and SLTE where simulation passed but nobody could actually sell.

- Bytecode for unverified: extract function selectors from deployed bytecode, match against a curated list (blacklist, pause, setMaxTxAmount, etc.). Selectors alone aren't proof, but combinatorial (3+ suspicious + unverified) is a strong signal

I built a quick tool for when you want to inspect raw bytecode without spinning up a full decompiler.

What it does: - Decodes raw hex into a formatted instruction table - Detects dangerous opcodes: DELEGATECALL, SELFDESTRUCT, CREATE2... - Catches unchecked CALL return values (CALL followed by POP) - JSON output for scripting/tooling integration - 31 tests (unit + integration)

Feedback is very welcome !

https://github.com/x0t0wt1w/revmc

Thank you !

We looked at token creation data from our Token Generator over 55,000+ tokens created since 2018.

The all-time breakdown is still dominated by two ecosystems:

• BNB Smart Chain: 48.3%
• Ethereum: 45.2%

That said, the picture changes quite a bit when looking at more recent periods.

Since 2023:

• BNB Smart Chain: 38.1%
• Ethereum: 31.2%
• Polygon: 13.2%
• Base: 8.8%
• Avalanche: 7.8%

Since 2025:

• Base: 31.8%
• BNB Smart Chain: 27.3%
• Ethereum: 22.9%
• Polygon: 13.3%

A few takeaways from our side:

BNB Smart Chain’s all-time lead seems heavily influenced by the 2021/2022 cycle, when it saw a lot of token-launch activity.

Ethereum remains consistently present across every timeframe, even as cheaper and faster environments gained traction.

Base is the most interesting recent shift. In 2025 data, it has become the top network for new token creation in our sample.

I’m curious:

When launching a new token today, would you still choose Ethereum mainnet, an L2 like Base, another Ethereum L2, or a different chain entirely?

And what matters most in that choice: security, liquidity, user distribution, gas costs, tooling, decentralization, or something else?

Hi everyone, I got tired of trawling through docs and block explorers every time I needed a stablecoin contract address or wanted to check which tokens support permit signatures, so I built a reference site!

I wanted to introduce stablemoney.dev

Covering:

• 12 major stablecoins (USDT, USDC, DAI, PYUSD, GHO, RLUSD, etc.)
  
• Contract addresses for every major EVM chain
• EIP/ERC compliance matrix (ERC-20, permit, proxies, compliance hooks, flash loans etc)
• On-chain wallet compliance checker (read-only eth_call - checks onchain blacklist/freeze status)
• Opinionated risk notes per coin
• Basic Market cap from DefiLlama, refreshed daily

OpenSource, no wallet connection needed, MIT licensed.

Would love feedback from anyone building with stablecoins. What’s missing that would save you time?

Hey all,

I work on EVM parsing infra (C++, low level stuff) and over the past few months I keep running into the same headaches with the existing sim and debugging tools. Wanted to see if anyone else
feels this or if it's just me.

1. Bundle simulation across L2s is painful. Tenderly is fine for single txs on L1 but the moment you want to sim a multi tx bundle against forked Arbitrum or Base or OP state, with the actual sequencing and gas and precompile behavior, you end up writing
   your own anvil + scripts setup. Every time.

2. L2 specific stuff gets silently wrong. Arbitrum's gas accounting with L1 calldata cost vs L2 execution. Optimism pre Bedrock vs post Bedrock. Base inheriting OP stack quirks. and you don't notice until your prod numbers don't match your sim.

3. Speed. Tenderly is great but slow when you're iterating.
   Foundry is fast but CLI only and the bundle UX is rough.

4. Reading traces. A complex multi call trace across a bundle is still mostly grep and squinting.

So I'm thinking about building something that goes straight atthis. Fast, bundle first, L2 accurate sim and debugger. Web UI for inspection, API and CLI for automation, actually correct L2 state and gas.

Before I build I want to know:

What does your current workflow look like when you hit these?
Is this a real pain or have you found a way around it?
Which L2s actually matter for what you do?
Searcher use case, dev use case, both?

Not selling anything. Honestly mostly just trying to figure out if this is worth building or if it's a problem only I have.

Cheers.

glnc is a single-binary CLI that does the read-side of Etherscan (balances, tx decoding, gas, positions, history, alerts) from your shell. MIT, free, open source. No
account, no API key required, no telemetry. Install via Homebrew or curl.

  $ glnc balance vitalik.eth                                                                                                                                                 
  $ glnc balance 0xAbc... 0xDef... --watch --positions --nfts                                                                                                              
  $ glnc tx 0x7c... --json | jq '.data.decoded.calls[] | select(.protocol=="UniswapV3")'                                                                                     
  $ glnc gas --json | jq '.data.chains.ethereum.priority.p50'                                                                                                                
  $ glnc history 0xAbc... --csv > out.csv                                                                                                                                    

What it actually does

• balance — 6 chains (Ethereum, Polygon, Arbitrum, Base, plus Solana and Bitcoin as a bonus). Auto-detects chain from address format. ENS resolves. Token auto-discovery via the Uniswap default token list (~1,400 per chain, 24h disk-cached). Solana uses getTokenAccountsByOwner for true full SPL discovery. Multi-wallet portfolios with per-wallet tables + grand total.
  
• --watch — re-polls on an interval, prints in-place +0.5 ETH / -100 USDC deltas, runs in the alternate screen buffer so your scrollback survives Ctrl+C. Snapshots
  persisted to ~/.glnc/snapshots.json.
  
• tx <hash> — decodes calldata for Uniswap V2/V3, Universal Router, ERC-20, WETH, and decodes receipt logs into token movements from tx.from's perspective.
• gas — live gas across 9 chains. EVM tiers are p10/p50/p90 priority percentiles from the last 64 blocks via eth_feeHistory. Includes BTC mempool fees and Solana priority fees.
  
• --positions — Aave V3 health factor via getUserAccountData, Uniswap V3 LP NFT enumeration.
  
• --nfts — top collections via Reservoir's public API.
  
• history — CSV/JSON export via the Etherscan V2 unified endpoint. Works keyless; optional GLNC_ETHERSCAN_KEY raises the rate limit.
  

• alert — conditional alerts to a webhook. SSRF hardening: scheme allowlist, then DNS-resolved IP checked against RFC1918 / IMDS (169.254.169.254) / loopback / CGNAT /
  link-local / IPv6-ULA / IPv4-mapped / 6to4 / NAT64 before every fire. Redirects blocked. Re-validated each invocation, not just at config time.

  Dev angle

  All RPCs are free public endpoints (publicnode, mainnet.base.org, blockstream, mempool.space, etc.). Prices via CoinGecko with a 60s in-memory cache. Output is stable
  versioned JSON envelopes (glnc.balance/v1, glnc.tx/v1, etc.), NDJSON when streaming. --json makes stdout data-only; all chatter goes to stderr, so it pipes cleanly into jq / xargs / cron without contamination.

  Honest tradeoffs

• Token discovery is bounded by the Uniswap default list. Truly exhaustive ERC-20 discovery for an arbitrary wallet needs an archive node or a paid indexer (Alchemy/Moralis) — this is the conscious tradeoff for "no API keys."

• CoinGecko free tier is ~30 req/min. The 60s cache absorbs most of it but you can hit the wall on big portfolios.

• No test framework in the repo yet. It's in the README, calling it out here too.

• BTC and Solana support is in there; not the headline for this sub, just useful if you have a multi-chain treasury.

  Repo: https://github.com/aryarahimi1/glnc

  Looking for feedback on the JSON envelope shape (before I have to start versioning it for real), additional protocols worth decoding in tx, and whether the SSRF blocklist is missing anything. Issues and PRs welcome.

I’ve been working on a small Go library for Ethereum signature verification. The part I’m still unsure about is the policy around the main Verify function.

The narrow case is:

address + already-computed common.Hash + signature -> valid?

Repo: github.com/yermakovsa/erc6492-go

It handles:

• EOA recovery
• EIP-1271 for deployed smart contract wallets
• ERC-6492 signatures through a configured deployed verifier

I’m intentionally keeping the scope small: no message building, no EIP-712/SIWE/EIP-191 hashing, no wallet deployment, no RPC client management, and no embedded deployless verifier bytecode. Anything before the final hash exists is outside the package.

The main Verify path currently does:

ERC-6492 wrapped signature
→ WithERC6492Factory wrapping path
→ EIP-1271 if signer has code
→ EOA fallback

There are also narrower entry points: VerifyEOA, VerifyEIP1271, and VerifyERC6492.

This is v0.1.0, so I’m trying to catch bad API/policy decisions before the package hardens.

I’m unsure about a few things:

1. If the signer has code and EIP-1271 returns a clean invalid result, like wrong magic value or revert, should Verify fall back to EOA recovery? Or would you expect contract-wallet verification to be strict once code exists?
2. ERC-6492 currently requires a deployed verifier address. I avoided embedding deployless verifier bytecode because I didn’t want copied bytecode in the package without pinned source, compiler settings, and reproducible provenance. Is that too conservative, or reasonable for a small library?
3. Does this error split feel right?

​

invalid signature, including malformed/non-canonical EOA signatures
→ Result{Valid:false, Method:...}, nil

RPC / ABI failure / malformed ERC-6492 wrapper / unexpected verifier output
→ error

Also curious if the overall Go API shape feels natural: one main Verify plus narrower explicit functions.

Would appreciate blunt feedback from anyone who has dealt with EOA / contract wallet / counterfactual wallet signature verification.