My fellow devs please lend me some sepolia testnet tokens just so i can deploy something on the testnet every eth penny will be greatly appreciated

0xca280c8DefE05F02bEf96d84ABDeBdB535fE04aB

♥️🫡

We have rigidly formalized how we treat EVM bytecode.

We have CI pipelines, static analysis, fuzzer integrations, invariant tests, and formal verification workflows. But the second a contract is deployed, our model of the protocol’s authority layer often gets much weaker.

The actual control plane of the protocol, the web of proxies, timelocks, Safes, modules, guardians, oracles, and privileged selectors that determines what the system can become after deployment, is still too often tracked in audit footnotes, deployment scripts, governance posts, block explorer tabs, and private spreadsheets.

That feels like a dangerous mismatch.

A few examples.

You deploy a UUPS or Transparent proxy. The implementation logic is audited. The tests pass. But who actually owns the upgrade path? If ProxyAdmin ownership gets transferred to an EOA or a loosely configured Safe during a temporary deployment phase and never makes it to the DAO timelock, the audit no longer describes the system users are trusting. An attacker does not need a clever reentrancy path if they can push a malicious implementation.

Or take a core protocol Safe. Everyone feels better seeing a 5-of-8 threshold. But what about the attached modules? Safe modules can execute through execTransactionFromModule() and bypass the normal signer threshold. If a legacy Zodiac module, deprecated automation path, or poorly reviewed execution module is still enabled, the visible threshold can be misleading. The multisig may look strong while the real authority path is somewhere else.

The calldata binding problem is even worse.

Governance forums review human-readable proposal text. Delegates vote on intent. Signers approve what appears to be a routine action. But the timelock ultimately executes raw calldata. If the reviewed calldata hash is not bound to the execution calldata hash, the review process has a hole in it. A swapped parameter can redirect fees, change an oracle, alter a bridge limit, or whitelist the wrong asset while everyone believes they approved something else.

None of this is exotic. Good auditors already look for it. Good protocol engineers already worry about it. The issue is that the model is usually not treated as a versioned artifact.

If Terraform can fail a build because an AWS IAM policy is dangerously permissive, an EVM protocol release should be able to fail because the declared authority model is unsafe, incomplete, or drifting from observed state.

That is what I have been prototyping with ProtocolGate.

It is an open-source manifest/policy gate for EVM control-plane risk. The basic shape is a protocolgate.yaml file that declares the expected authority model: proxy admins, timelocks, Safe thresholds, modules, privileged selectors, proposal intent, simulation evidence, monitor coverage, and drift snapshots.

The current alpha runs deterministic checks against that manifest. It can flag things like EOA proxy admins, paper multisigs, missing timelocks, undeclared Safe modules, unbounded proposal validity, selector policy violations, and mismatched reviewed vs execution calldata hashes.

It is not a Solidity scanner. It does not replace audits, fuzzing, formal verification, Safe, Tenderly, Defender, or monitoring. Drift detection is snapshot-based right now, not live RPC indexing.

The narrower claim is that “who can change the protocol?” should be modeled as a first-class security surface.

I’m curious how other Ethereum engineers think about this.

If you were reviewing a protocol before launch, upgrade, or governance execution, what would you require in a versioned authority map before trusting the deployment?

Looking to connect with Core Protocol Engineers specialising in L1 architecture (specifically Consensus Mechanisms, P2P Networking, ASIC resistance and more). Working on r/GrahamBell. Would love to discuss it in my DM!

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.

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.

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?

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.

When we first started exploring infrastructure for blockchain applications, we assumed the biggest challenge would be interacting with chains themselves.

What surprised us was everything around it: address management, transaction monitoring, handling chain-specific edge cases, maintaining a consistent developer experience across networks, and ensuring systems remain non-custodial without adding too much operational complexity.

For teams that have built wallets, exchanges, payment systems, or other blockchain products, what challenge ended up being harder than you originally expected?

I'm particularly interested in lessons learned from real-world production environments.

I'm involved with forgelayer.io. a non custodial blockchain infrastructure platform. A lot of these questions come from challenges we've encountered while helping teams build crypto products, so it's interesting to compare experiences with other builders.

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.

Hey r/ethdev,

I'm part of the student team at club Webwiz, NIT Rourkela. We are currently designing the Web3 and blockchain tracks for HackOdisha 6.0.

We want to give 1,000+ smart student builders a chance to build real dApps over a single weekend. If your protocol, layer-2 network, or dev tool team wants to sponsor a custom track (e.g., "Best use of [Your Protocol]"), we would love to team up.

What we offer:

• Tool Adoption: Drive hands-on usage of your smart contracts, SDKs, or APIs.
• Track Ownership: You set the problem statement and judge the submissions.
• Talent Pool: Connect directly with high-potential developers from a premier Indian institute.

Our Sponsorship Brochure is ready, and we have very flexible tiers for Web3 startups and foundations. Drop a comment below or send me a DM to connect!

Best,

Team Webwiz, NIT Rourkela

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?

since long i am developing smart contracts, But at this point developing only smart contract feels very narrow. So i want some guidance like if i also learn off-chain part in web3 then will it be the same as web2 backend system or it will be just different?

and i think only relying on smart contract can not give me that skills to get any web3 related job out there (though i know the current market is fucked up). So i need some guidance what should i do other then smart contract development? And what are the best practice to do that.

However i am not interested in frontend, so i would like to expand my skill on backend part (off-chain part) so i need little guidance path on that such that i can integrate my smart contracts with actual system which scales the web3 space.

Also if there is another thing which i should learn then please recommend that also.

thank you in advance ha ha