r/ethdev

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%.

Smart Contract (Verified on Arbitrum): https://arbiscan.io/address/0x64dFe266E88c5c44883711F424Ed374b3D677F5D#code

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.

Python SDK for the Uniswap Universal Router

Mainly technical improvements, but this version adds support for the Universal Router v2.1.1 swaps (V2, V3 & V4 pools), thus introduces breaking changes.

Another change worth noticing: this Python SDK supports now asynchronous development.

• ➡️ Update UR address and abi to match the UR v2.1.1
• ➡️ Add support for UR v2.1.1 swaps
• ➡️ Add async support
• ➡️ Add tick, sqrtPriceX96, and liquidity related functions
• ➡️ ... see full release notes here

Installation: pip install uniswap-universal-router-decoder==3.0.0

Useful links:

• Doc/Repo
• PyPI

Feel free to give me any feedback on this release here, or open a discussion or a ticket about a feature that should be in the next one!

Happy development!! 🙂

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.

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?

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.

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.

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

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.

We looked at token creation data from our Token Generator across 54,900+ tokens created since 2018.

https://preview.redd.it/x56uytthzv1h1.png?width=1284&format=png&auto=webp&s=7c6a611e6db2fd0dba0100af194bc35ecc21de09

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:

https://preview.redd.it/wswqhd1kzv1h1.png?width=1284&format=png&auto=webp&s=c48ef687ae2e2f6fa9c9a5d8d1386c5d4f211ea0

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

Since 2025:

https://preview.redd.it/lh0akv9lzv1h1.png?width=1284&format=png&auto=webp&s=618d1ee87067f943d38b47135bdc32e679cef6c8

• 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?

https://preview.redd.it/i2c8rdbtaw1h1.png?width=2040&format=png&auto=webp&s=0237b44cb3ba15461006e88c8271d1d2a50e9cdc

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.

Heyy Guys, im back from learning foundry and next looking to build some projects and host them in the testnet.

I was thinking of building a standard and solid project (like DAO/DEX) instead of small projects..

So when i looked up, i came to know that uniswap is very useful in developing commercial level projects and has many built-in features ideal for production grade apps..

Now should i learn Uniswap and then build a solid project or just build a project and then learn Uniswap..

Thanks in advance...

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.

Most blockchain tools stop at transaction viewing.

I wanted to explore what happens after that:
investigations, fund-flow tracing, cybercrime analysis, compliance workflows, and forensic reporting.

So I started building Blockchain Sentinel OS — a digital financial investigation platform focused on:
• multi-hop wallet tracing
• blockchain crime intelligence
• case workflows
• forensic-style reporting
• India-focused compliance direction

Still evolving heavily, but the platform is finally starting to feel like a real investigation workspace instead of just another explorer.

Would genuinely love feedback from people in security, forensics, compliance, AML, or blockchain infra.

https://blockchain-sentinel-os.vercel.app/

A question for Web3 developers who have actually worked as developers at relevant companies: What does the actual day-to-day work of a Web3 developer look like? What percentage of the work is *actually* spent writing smart contract code, and what does the rest of the job entail? I would also be grateful for a brief insider's perspective on the current job market.

We've all seen the scenario where our agents plan the perfect holiday, find the perfect hotel and ticket deals and you just approve the transaction: "Yes, buy them". I do think this is definitely in the future of agentic payments, but not the current reality.

After doing some research, I noticed two different layers normally get lumped together as "Agentic Payments". The payment layer is x402 (Coinbase started it, Linux Foundation now), agents programmatically paying for things. Then we have the execution layer which looks more like OKX's Agent Trade Kit, Kraken's CLI, Binance AI Agent Skills, etc, basically agents placing orders directly on exchanges. Some teams stack both, pay for market data (Coingecko, CMC) via x402 and execute via CEX toolkit.

x402 is mostly agents paying for their own APIs/infra. Hyperbolic for GPU inference. Neynar for Farcaster data. Cloudflare's pay per crawl. Token Metrics swapping subscriptions for per call analytics. The agent isn't buying for a human (at least not directly), it's keeping itself running.

The consumer scale story lies on the execution layer. CEX agent trading, Polymarket bots, platforms like SaintQuant running across exchanges. Notice the trend? Agents trading on behalf of users, not agents buying flight for them (yet).

Is there any "real agent doing your shopping" for you out there?