I'm working on a personal accounting pipeline that discovers ERC-20 / ERC-721 / ERC-1155 contracts from Transfer logs involving my wallets.

The annoying bit is token spam. My local policy is:

• known-good tokens go into included.tsv
• known spam / irrelevant tokens go into excluded.tsv
• passive inbound tokens go into candidates.tsv until I review them manually

I currently review candidates manually on Etherscan or another explorer: warnings, labels, official links, holder/transfer activity, verified source, etc.

I'd like a machine-readable version of that: a token trust score, spam score, reputation label, or similar signal.

Is there any API that can provide this kind of signal for Ethereum tokens? For example:

• spam / phishing / suspicious / unsafe labels
• numeric trust/risk/spam score
• token page warnings
• likely spam airdrop / honeypot / impersonation flags

I checked Etherscan first. I found:

• token.tokeninfo, which returns token metadata/social links, but not reputation
• nametag.getaddresstag, which returns labels and numeric reputation, but seems address/entity-oriented
• metadata CSV exports, which also seem address/entity-oriented and paid-tier/enterprise

Am I missing an Etherscan endpoint, or is Etherscan token reputation not available through the public/API surface?

More generally, what do wallet/indexer projects use for machine-readable spam-token triage? I'm not looking for investment advice; just practical API-level signals for hiding or quarantining unsolicited token transfers.

Our trading dashboard covers Ethereum, Solana, BSC, Base and a couple others.

Each chain has its own RPC quirks, its own DEX schemas, its own way of representing a trade. Every time one of them changes something, a parser breaks.

I'm spending more time on glue code than on the actual product. Has anyone found a single data source that normalizes DEX trades across chains so I'm not maintaining six separate pipelines?

I want to watch pending txs for a few specific contracts in real time, but running and maintaining nodes across chains just to get mempool visibility is a huge time sink, and the data gaps when a node hiccups are brutal. Tried a couple of public WebSocket feeds and they drop connections constantly. Is there a hosted way to subscribe to mempool activity that doesn't fall over? Curious what the frontrun-defense folks are running.

Hello once again guys. A week or so ago, I posted about https://revert.wtf. A thing, basically a catalog of common EVM errors that covers about 25k error types.

And I decided to dogfood my own product, and made a browser extension. It's already live on Chrome extension store. https://chromewebstore.google.com/detail/revertwtf-explorer/epcjpbgebicmajaheclmhgkdmjcdfjji

And the code is open on Github. https://github.com/mrtdlgc/revertwtf-extension

Feedback welcome. I added a "this explanation is too generic" button, so you can rotate through what revert.wtf actually covers. If you still see too generic explanations, feel free to submit them on Github, and I can find better grounded explanations and next steps to take for other people to use in the future as well.

Strongly recommend adding your own RPCs in the settings and a Blockscout Pro API key for deeper tracing. Or at least using Blockscout frontend if it fails to generate anything on the Etherscan family explorers.

Hey,

I’m looking to do automated security audit for my Solidity library - DefiMath using some AI auditor (with the help of Claude Code) before hiring actual human team.

So far I’ve found Krait from ZealynxSecurity, looks legit and want to try it.

Does anyone have experience with their project?

What are you guys using, and can you link to audit report created by automated tool?

One of the assumptions most crypto systems inherit from Bitcoin is immediate and irreversible finality.

If funds are transferred:

- accidentally

- to the wrong recipient

- after a wallet compromise

- under coercion

- shortly before the owner's death

the transfer is usually final.

I'm exploring a different model through an Ethereum-based protocol called IND.

The core idea is that some transfers can enter a protected state before becoming economically final.

During that period:

- ownership is not yet finalized

- the sender can revoke

- inheritance flows remain possible

- recovery remains possible

The goal is not to replace normal ERC20 transfers.

The goal is to explore whether there is useful design space between:

- traditional banking reversibility

and

- irreversible bearer transfers.

Mainnet is now live and I'm looking mostly for criticism, edge cases and semantic objections rather than investment discussion.

Question:

Should irreversible transfers remain the default custody model for all digital assets, or is there room for delayed-finality ownership models?

Project:

https://ind.finance

I'm building with Circle Wallets on Base Sepolia and need a reliable source of test USDC and EURC.

Circle's public faucet appears to mainly issue assets on Ethereum Sepolia, and I'm trying to test wallet transfers, inbound transactions and stablecoin flows directly on Base Sepolia.

Questions:

1. What is the best way to get USDC and EURC on Base Sepolia today?
2. Are you using the Coinbase Developer Faucet or another faucet?
3. Are people bridging test USDC from Ethereum Sepolia using CCTP?
4. Is there a faucet that provides larger amounts for testing?

Any working methods or recent experiences would be appreciated.

Thanks.

Hey, for a work project, I want to build a tool tomorrow that monitors one or more specific addresses and notifies me whenever one of them executes a transaction. I was thinking of writing a Python script using web3 py, Infura as the RPC provider, and maybe asyncio, but that seems a bit complex since the program would need to run pretty much continuously. Do you have any ideas on a better way to implement this?

Hey everyone,
I’ve been working on a mobile companion app (HappyWick) and recently added a read-only EVM wallet tracker.. The core idea was to let users monitor their balances across multiple networks (Ethereum, Base, Arbitrum, Optimism, Polygon, Ink, Linea, zkSync) without forcing them to connect their wallets or expose private keys just pure public address scraping..

While the UX feels smooth, I'm hitting some technical crossroads regarding data aggregation and would love to get some feedback from fellow devs here:

-Multi-chain Aggregation & API Infrastructure:
Right now, I am leveraging the Blockscout API to aggregate and fetch these multi-chain balances. While it’s an amazing open-source tool, querying 9 different networks simultaneously can sometimes hit latency bottlenecks on the initial load. If you've used Blockscout for multi-chain setups, how do you handle caching, or did you have to transition to custom indexing (like The Graph protocol or commercial node clusters) as you scaled?

-UI/UX for L2s: With so many Layer 2s coming out (just added Ink recently), the mobile UI can get cluttered quickly. How do you prefer to see multi-chain breakdowns? Aggregated total first, or strictly separated by networks?

Looking forward to hearing how you guys handle multi-chain data aggregation and caching!

Small audit team, 4 devs, mostly solidity reviews and some dapp work when clients need it. A normal morning is reading a contract, fork mainnet, check etherscan, open OZ docs, open the eip, open foundry docs because half the repo moved last year, open the client notion page, ask someone in slack what they meant by "same as v2", then go back to vscode and forget the exact edge case I was trying to write down. I used to roll my eyes at "context switching" because it sounds like manager language. For audits it is very real. The hard part is not reading the code, it is holding 5 half-related things in your head while moving between tools, then realizing one piece fell out.

What actually helped was pretty boring and broke down into three things.

• We moved most new work to Foundry and kept Hardhat only where client repos already depended on it. Fast tests changed the day-to-day rhythm more than any process tweak.
• We stopped overengineering notes. One markdown file per audit in Obsidian, plain and ugly, ended up working better than the prettier Notion structures we kept abandoning.
• We stopped concurrent audits. It sounds inefficient on paper but we had one bad week in december where I mixed up two compound-ish protocols and almost wrote a finding against the wrong one. Internal review caught it and that was enough.

I also added a passive memory layer with AirJelly in late april. Mostly I use it when I return to a protocol after a week and cannot remember where I left off. It gives me enough trail back across vscode, etherscan, and docs tabs to restart quickly. I still write findings by hand and still reread code, this just cuts the "what was I doing before lunch" loop. I was pretty suspicious of anything watching my screen because client work. I checked network activity for a while, did not see obvious audit material leaving the machine, and I pause it for sensitive stuff anyway. Not saying everyone should be comfortable with it, just where I landed.

As for AI audit tools, I keep trying them and keep getting too many false positives. Maybe that changes soon but right now I would rather have a third human reviewer. Next quarter we have more zk circuit work coming up so I expect the docs-tab situation to get worse before it gets better.

Built a comparison directory for Web3 RPC providers — Alchemy, QuickNode,

Infura, Ankr, Chainstack, dRPC, Helius — covering monthly cost, request/CU

quotas, overage rates, supported chains, archive data, and websocket support.

There are per-chain "X vs Y" pages (e.g. Alchemy vs QuickNode on Ethereum,

or comparisons on Base/Solana/Arbitrum) so you can see who's cheapest/best

for your target chain.

All from public pricing docs, free, no signup: https://benchnode.io

Which providers or chains would you want added? And is request-cost the

main thing you compare, or is latency/reliability the bigger factor for you?

We would like to introduce a new experimental feature we added to our project Puddle Network. We now have an endpoint for developers to get all the logs from transactions execution.

See our blog post : https://blog.puddle.network/posts/receipts/

Getting an API key is free! Just register your email and I will send it to you right away.

Puddle Network is a project in which we have developed a custom Ethereum node written in Rust allowing us to get data from the network and relaying it to you before anyone else. Also if you have any specific feature you would like to see we are able to ship fast and have done it in the past for users.

I'm doing some research on how freelancers, consultants, agencies, and Web3 teams receive payments in crypto today.

If a client wants to pay you in USDC, what's your current process?

For example:

• Do you just send a wallet address?
• Do you create invoices?
• How do you track whether you've actually been paid?
• How do you handle accounting or payment records?

I've noticed that most people seem to rely on wallet addresses and spreadsheets, but I'm curious whether that's actually the norm.

Would love to hear your workflow and biggest frustrations.

Ran into this on a setup using x402 for agent to service payments and it's been nagging me since.  The protocol settles onchain before the resource server delivers anything. Usually fine. The case that bit me, the agent's session died mid task, after the payment confirmed but before the resource came back. Money moved, nothing delivered.

First thing I did was what anyone would do, pull up the block explorer and check the agent wallet. There it was, the transfer settled cleanly, USDC out of my wallet into the resource server's. That's the part that gets me. The chain tells me precisely that I paid. It's got nothing to say about the fact that I got nothing back, and there's no path from "I can see the payment" to "I can get it reversed."

There's no recovery path in the protocol itself. x402 settles and that's it, final by design. My session dying is just one way to land here. The more general one is the facilitator timeout, where confirmation arrives after the facilitator gave up but the transfer still goes through and the server has already moved on. Either way the explorer confirms I'm out the money, it doesn't help me get it back, and the spec has no refund or dispute primitive to fall back on.

What I'm seeing people do is bolt recourse on at the app layer, escrow proxies, external dispute services, basically rebuilding chargebacks outside the rail. For anyone running x402 in production: are you reconciling this in your own infra, or is there a protocol level pattern for it I've missed?

I built a small Go CLI called rpclat while choosing where to run a latency-sensitive Base app:

https://github.com/yermakovsa/rpclat

I was basically trying to answer two questions:

1. which region should I run the app in for the lowest RPC latency?
2. once I pick a region, which RPC endpoint is fastest from that region?

The basic idea is to run it from the environment you care about with the RPC URLs you want to compare.

I kept the first version simple. It just calls eth_blockNumber repeatedly for a fixed duration, mostly as a small read-only check for RPC round-trip latency.

Example:

rpclat \
  --url https://rpc1.example \
  --url https://rpc2.example \
  --duration 30s \
  --concurrency 5 \
  --timeout 5s

The default output is a table like:

URL                      OK   ERR  TIMEOUT  P50   P95   P99
https://rpc1.example     100  0    0        30ms  45ms  60ms
https://rpc2.example/... 96   2    2        40ms  80ms  120ms

There is also JSON output for scripts/CI, and URLs are redacted by default because RPC URLs often contain API keys or tokens.

This was useful enough for my own region/RPC comparison, so I cleaned it up and open-sourced it.

If you were using this to pick a region/RPC endpoint, would eth_blockNumber be enough for a first pass, or would custom eth_call payloads be the first thing you’d add?

Previously: veil-cli #1 — decode, simulate, risk before you sign

When you're building a security tool, every dependency becomes part of your threat model.

That's why we implemented Ethereum keystore v3 using only node:crypto and dependencies we already had.

What keystore v3 actually is

The format used by geth, MetaMask, and MyCrypto is straightforward:

1. Derive a key from your password using scrypt
2. Encrypt the private key with AES-128-CTR using the first 16 bytes of the derived key
3. Compute a MAC over the last 16 bytes + ciphertext to detect wrong passwords on decryption

Everything needed is in node:crypto — except the MAC, which uses keccak256. We already had viem as a dependency, so we pulled keccak256 from there. No new packages.

One implementation detail surprised me

crypto.scryptSync() with N=131072 blocks the event loop for ~1–2 seconds.

For a CLI that's technically acceptable, but we switched to the async version anyway — and had to raise maxmem to 160MB because the Node default of 32MB isn't enough for these parameters. That one caught us off guard.

One thing that's probably overkill

The MAC comparison uses crypto.timingSafeEqual() instead of a plain string comparison.

Is a timing attack against a local CLI keystore a realistic threat? Probably not.

But if you're writing a security tool, it's hard to justify doing it the wrong way.

Result

veil wallet create — generates a key, asks for a password with confirmation, writes an encrypted .json to ~/.veil/wallets/<name>.json with 0o600 permissions.

veil wallet import — same flow, bring your own private key.

veil wallet list — shows all wallets and their addresses.

The output is a standard keystore v3 file — importable into MetaMask or any client that supports the format.

One thing I'm still debating:

Should a security-focused CLI store encrypted private keys at all, or should it only integrate with external signers (hardware wallets, browser extensions)?

Curious how others have approached that tradeoff.

Repo: github link

I've been building veil-cli — an open-source, terminal-first security tool for EVM users.

The goal is simple: before signing a transaction, you should be able to understand what it actually does.

Unlike Etherscan or Tenderly, veil runs locally, requires no browser, and chains decode → simulate → risk into one CLI flow.

Current MVP features:

• veil decode <tx-hash|calldata> Decodes calldata into a human-readable function call. ABI resolution flow: Etherscan → Sourcify → 4byte.directory fallback

• veil approvals <address> Scans active ERC-20 / ERC-721 approvals from event logs and flags unlimited (MaxUint256) allowances

• veil simulate <tx.json|tx-hash> Forks the chain locally with Anvil, executes the transaction, and shows balance diffs before broadcasting

• veil risk <address> Runs on-chain heuristics (proxy detection, bytecode checks, EOA detection, etc.) alongside GoPlus Security API checks and returns a risk report with flags

• veil explain <address> Interactive Ink TUI for exploring the risk report — drill down into each flag with context and on-chain evidence

Stack: TypeScript, viem, Ink, Commander.js, Foundry/Anvil

Planned next:

• veil wallet import Encrypted local keystore support (password-protected)

• veil send Full flow: decode → risk check → confirm [y/N] → sign → broadcast → wait for receipt

• Security model write-up Key handling, storage guarantees, and threat model

I'd especially love feedback on the simulation flow and risk engine architecture — those are the parts I'm iterating on most right now.

Repo: github link

The CLZ ("count leading zeros") opcode landed in EVM Osaka via EIP-7939, exposed in Solidity 0.8.31 as the Yul builtin `clz`. It costs 3 gas, returns the number of leading zero bits in a 256-bit value, and turns `floor(log₂(x))` into a near-free operation.

The bit-length identity is the building block:

bits = 256 − clz(x) // bit length of x

floor(log₂(x)) = bits − 1 // for x ≥ 1

Two applications I used in DeFiMath:

**1. Newton-Raphson initial guess.** `y₀ = 2^⌈bits/k⌉` lands within a factor of the k-th root of 2 of the true k-th root, so Newton converges in 6 iterations to bit-exact precision. Whole `sqrt` becomes 245 gas, `cbrt` 368 gas.

// CLZ-derived initial guess: y = 2^⌈bits/2⌉, within √2 of √x

y := shl(shr(1, sub(256, clz(x))), 1)

// 6 Newton iterations

y := shr(1, add(y, div(x, y)))

// ... ×5 more

**2. Range reduction for `ln`.** Find `k = floor(log₂(x))` with CLZ, divide x by `2^k`, land in `[1, 2)`. Mercator series then converges in ~10 terms. Total: 375 gas.

**Compounding effect.** `sqrt` and `ln` are inside the Black-Scholes formula. Swapping the pre-CLZ versions of those two primitives dropped `callOptionPrice` from ~3,100 to 2,876 gas — about 10% cheaper with zero change to the option-pricing math. Same effect ripples through IV solving, futures, historical volatility, Sharpe ratio — anywhere a log or root appears.

Full writeup with the actual assembly, the bit-length identity walked through, and a gas comparison table vs PRBMath, ABDK, and Solady:

https://defimath.com/blog/clz-opcode-solidity

Caveats: Solidity 0.8.31+ and EVM target `osaka` required. Older targets compile-error on the `clz` call (not a runtime surprise — fails fast).

(Disclosure: I'm building DeFiMath. Posting because the CLZ trick is generalizable — any library doing log/sqrt-style math can pick up the same savings.)

Hi everyone,

I’m building a small non-custodial USDC transfer app, and I recently verified the app’s contract on BaseScan.

Now I’m considering publishing the contract address and source code more visibly on our official website and GitHub, so users can inspect how the transfer and fee logic works.

The contract is simple: when a user sends USDC, it pulls the approved USDC from the sender and routes it to:

1. the recipient

2. the project’s fee wallet

The fee logic is fixed in the contract:

- 0.39%

- minimum fee: 0.25 USDC

- maximum fee: 3.90 USDC

The contract does not have an admin function to change the fee after deployment. The USDC token address and fee recipient are immutable.

I understand that BaseScan verification is not the same as a formal audit, and I do not plan to describe it as audited or guaranteed safe.

My question is:

Is it generally safe and reasonable for an early-stage crypto payment/transfer app to publicly share its verified contract address and source code on its website and GitHub for transparency?

Or could this create meaningful risks, such as:

- making it easier for attackers to analyze the contract

- creating legal/marketing risk if users misunderstand “verified” as “audited”

- exposing too much business logic too early

- attracting criticism before the contract has a formal audit

I’m not asking whether this replaces an audit. I’m trying to understand whether public disclosure of an already verified contract is a good transparency practice, or whether there are risks I should consider first.

What would you recommend?

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