Getting close to deploying a dApp (Ethereum mainnet only) and I'll be running 2 of my own nodes behind it, with Alchemy or Infura as a fallback. The frontend runs in the browser, so the RPC URL is public by definition and anyone can grab it from devtools and hammer it with scripts. I want to keep it from getting flooded, whether that's an actual attack or just bots and other apps freeloading on it.

Here's what I'm planning so far.

- A reverse proxy in front of both nodes handling rate limiting, method allowlisting and caching. The nodes' RPC ports only listen on localhost/a private network, so nothing reaches them except through the proxy

- Only the P2P ports open to the internet, Engine API (8551) never exposed

- Only the eth, net and web3 namespaces enabled (no debug, trace, admin, txpool), WebSocket off unless I need it

- Caps on batch size, eth_getLogs block ranges, and gas/timeouts for eth_call and eth_estimateGas

- Origin/CORS restrictions, which at least stop other sites from using my RPC in-browser (useless against scripts, I know)

A few things I'm still not sure about.

1. Should rate limiting be per time window (X requests per second/minute) or a cap on total requests (per session or per day)? Or both, like a burst limit plus a daily quota?

2. Is it normal practice to track and limit per IP? And do people actually ban IPs that look like attackers, e.g. ones that keep slamming into the limit nonstop? If so, temporary bans that escalate, or permanent? Also, how do you avoid hurting real users who share an IP (offices, VPNs) when attackers can rotate IPs anyway?

3. Do you count HTTP requests or individual RPC calls? One JSON-RPC batch can carry hundreds of calls, and an eth_getLogs over a wide block range costs way more than eth_blockNumber. Do you weight limits by method?

4. Is "own nodes as primary, Alchemy/Infura as fallback" a sane setup? Do you fail over in the proxy or in the frontend? A key in the frontend can be grabbed by anyone, but if it lives in the proxy, couldn't an attacker just overload my nodes and burn through my provider quota?

5. How do you load balance and health check 2 nodes? I'm thinking of running a different client on each and pulling a node out of rotation when it falls a few blocks behind, so users don't see inconsistent state between requests. I'm also considering eRPC for this since it handles failover to Alchemy/Infura, caching and rate limiting. Has anyone run it in production? Should I go with it or just stick with nginx/HAProxy?

If you're running something similar in production, sharing any experience would be really helpful, even if it's just what didn't work. Thanks!

I wanted my Go app to try a backup Ethereum RPC provider when the primary started timing out or returning 503s. I didn't want to run a separate proxy just to handle that.

So I built failnext, a Go library that lets you configure a primary RPC provider and a few backups. It plugs into Go's standard http.Client, so it works with go-ethereum and other HTTP-based Go clients too.

I got some feedback here on r/ethdev, made changes based on it, and recently released v1.0.0.

Here's what you can do with it:

• Primary RPC unavailable? Try the next provider.
• A provider is lagging or degraded? If your app detects it, failnext can skip it.
• HTTP 200 with a JSON-RPC error? No automatic failover. Your app handles the error and can retry with that provider excluded.
• Want reads to fail over, but not writes? Your app can allow failover for reads and block it for writes.
• Reading after a write? Try the provider that handled the write first.
• Everything failed? See which providers were tried and what went wrong.

I wanted failnext to handle provider selection, cooldowns, and HTTP-level failover, while leaving decisions that need RPC context to the app. It doesn't interpret JSON-RPC errors or detect lagging providers, but the app can tell it which providers to skip or try first for a given request.

If you saw my earlier rcpx posts, this is the same project. I started it in February 2026 and renamed it to failnext during a larger redesign.

How do you handle RPC failover in your apps? I'd be interested to hear if I've missed any cases. And if you try failnext, let me know what doesn't work or feels awkward.

GitHub: https://github.com/yermakovsa/failnext

The problem: when an agent pays another agent, there's no way to tell whether an accountable human stands behind it, short of trusting someone's API.

What we did: each agent's passport is a canonical JSON doc whose SHA-256 is signed BIP-340 (Schnorr, secp256k1) by a hub key. The operator's identity check is referenced only as a hash and a KYC job ID: no name, DOB or documents. The verify page does the Schnorr check in plain JS (BigInt point math + WebCrypto), with no backend. I re-checked one live passport with an independent implementation written from the spec: the real signature verifies, and flipping one bit of the hash fails.

Limits: it proves a verified human operates the agent, not that the agent does good work. Today all 39 passports share one operator (me). It signs the hash; full content integrity needs the canonical JSON published next to it.

Paper: https://craigmbrown.com/blindoracle/20260620-verifiable-agent-passport-whitepaper.html · Try it: https://craigmbrown.com/blindoracle/verify/?agent=RealityCheck

Disclosure: I build BlindOracle.

Hi guys, I got into crypto a few years ago and fell in love with the ecosystem. It's fair to say Web3 completely changed my life for the better, and ever since, my aim has been to contribute meaningfully to it. One issue I've had an issue with is the persistent hacks reducing user trust in this new model of the internet we're building. So I'm proposing an AI security network to protect wallets from hacks.

You can check out the website or GitHub: https://github.com/thelennyjohnson/avalon-ai

Feedback and contributors are welcome.

There's a new Octant round active right now focused on funding teams advancing privacy on Ethereum and the open internet. There aren't a lot of programs like these anymore, so please check it out and help support your favorite projects.

• Round open until Oct 22, 08:00 AM
• Min. contribution 0.07 ETH / $20

[ Removed by Reddit on account of violating the content policy. ]

I'm maintaining a Python asyncio EVM monitoring pipeline with a PostgreSQL event journal and a durable notification outbox.

During one production session, a read-only reconciliation identified 49 candidate semantic event identities across 11 underlying transactions. Each identity reached five processing attempts without creating delivery or outbox records. Most occurred on Base.

The findings were:

• 26 identities had VALUATION_UNVERIFIED.
• 23 had both valuation issues and TOKEN_AMOUNT_UNVERIFIED.
• Those 23 identities came from only 3 transactions.

These are not 49 independent failed transactions, and this does not establish that 49 eligible alerts were lost.

We haven't determined whether each failure was caused by missing token prices, missing native-asset prices, unverified token decimals, provider/indexing delays, or an application logic bug.

The final NO_DURABLE_DELIVERY diagnostic tells us that no durable notification was created, but it doesn't fully explain which upstream evidence was missing at each attempt.

My questions:

1. What minimal per-attempt diagnostics would you capture to distinguish missing data, invalid metadata, provider/indexing lag, and application logic failures?
2. How would you preserve evidence provenance and freshness when retrying incomplete valuation or token-amount verification?
3. How would you distinguish temporary evidence failures from permanently unsupported assets without infinite retries or incorrect notification thresholds?
4. Since these 49 identities correspond to only 11 transactions, how would you correlate failures across attempts without double-counting them? Would you recommend structured reason codes, provider-evidence snapshots, or both?

I can share a small, redacted trace and relevant code excerpts if needed.

My priority is correctness. I don't want to assume 18 decimals, invent prices, weaken verification, incorrectly filter unresolved events, or blindly resend notifications.

If you are working with EIP-3009 transferWithAuthorization or x402 agent payments, there is a fundamental timing problem: settlement is immediate, but data delivery is probabilistic.

Standard facilitators run ecrecover and submit the transaction to the sequencer right away. If the upstream server is an autonomous agent that returns a 502, malformed JSON, or bad data, the nonces are consumed and the buyer's balance is deducted with no recourse.

Instead of writing complex on-chain escrow contracts that add latency and double gas costs, we put a stateless clearing flow on Cloudflare Workers:

1. Prunes circular wash-trading clusters using a Union-Find graph of Base ERC-8004 agents.
2. Holds the EIP-3009 signature in memory while firing the upstream request.
3. Runs checks on the body: compiled Ajv schema, numeric bounds, timestamp freshness, and refusal strings.
4. If it passes, it settles and returns a signed receipt. If it fails, the signature is dropped from memory, nothing is broadcast, and the buyer pays 0.
5. If fallback endpoints are provided, it tries the next candidate in the same request.

Code is up on GitHub under Nullclear-Protocol/nullclear (MIT).

It runs on Base Mainnet as Agent 124595, and the client SDK is on npm under u/nullclear/x402-arbiter.

Curious how others here are dealing with counterparty delivery risk when the payee is an LLM agent.

Between public node operators stealth-gating eth_getLogs behind archive tiers, arbitrary chunk-size caps, multi-chain cursor re-winds, and front-running bots eating standard arbitrage strategies alive, building scalable apps on transparent EVM chains feels like a constant battle against infrastructure debt.

When you look at why these failure modes happen, public mempools exposing transaction intent, lack of native state confidentiality, and fragmented cross-chain bridging, it highlights why architectural shifts toward privacy-preserving execution environments like Oasis Network’s Sapphire ParaTime are becoming necessary for complex dApps.

By utilizing Trusted Execution Environments (TEEs) at the EVM level, Sapphire handles end-to-end encryption for transaction inputs and internal state. This changes the design pattern for several common bottlenecks:

• MEV & Front-Running: Because pending calldata is encrypted in the mempool, toxic extraction vectors like sandwich attacks are mitigated at the protocol layer rather than requiring complex private relay or builder negotiations.
• Confidential State Management: Instead of writing intricate workarounds to hide sensitive variables or user intent on public chains, contracts can natively manage confidential storage variables and private logic without leaking state data to public scrapers.
• Modular Cross-Chain Privacy (OPL): Through tools like the Oasis Privacy Layer (OPL), developers can keep their main application logic deployed on standard Ethereum or Layer 2 host chains while routing privacy-sensitive or vulnerable execution steps securely through Sapphire using cross-chain messaging SDKs.

Curious how others here are architecting around public RPC decay and state privacy as they scale past a single chain. Are you building custom indexing wrappers, or shifting state logic entirely to specialized runtime environments?

New release of Dshackle Archive v0.9, now with Kafka support.

It's an open-source CLI that copies blocks, txs, receipts and traces from your nodes into Avro, exactly as the node returned them, on disk, S3, Kafka or Pulsar. You do the analysis with your own tools.

0.9.0 adds Kafka output and notifications, backpressure (much lower memory on backfills), a quick verify mode, fetch timeouts and delayed archival.

https://github.com/emeraldpay/dshackle-archive

I made a short tutorial showing the full flow of a first blockchain transaction in TypeScript: create testnet wallets, build a payment, autofill the transaction, sign locally, submit it, and verify the validated result. The example uses XRPL and xrpl.js, and I also explain Fee, Sequence, LastLedgerSequence, tesSUCCESS, and delivered_amount.

I made the video myself. If you work on blockchain dev and like end-to-end walkthroughs, it may still be useful even if you do not use XRPL day to day.

Video: https://www.youtube.com/watch?v=JuwjHLt7lHw

I want to build an MEV bot. Before going further I'd appreciate the shed of light of ETH veterans on what to keep notes of and how to proceed.

My roadmap is as follows:

1- Learn rust, solidity, DeFi protocols: Uniswap / Sushiswap, Lending protocols: AAVE

2- Test with anvil and alchemy since my laptop can't hold the base mainnet fork

This road will consume a lot of time studying and practicing. But I want to be precise in what to spend time on.

Any advice on building the stack, design architecture, estimated time for each subject with a general programming background or if this is too late and saturated already since it seems that I'm late for this, is valued.

Hey everyone,

I've been digging into MEV on Ethereum, and what started as trying to understand how sandwich attacks and transaction ordering work turned into building a bot with several working features.

The rabbit hole goes deeper than I expected. There's a big difference between understanding a strategy on paper and dealing with transaction timing, liquidity, execution constraints, and the possibility that conditions change before a transaction lands.

I'm interested in how other developers approach the engineering side of this, particularly transaction monitoring, strategy simulation, and execution reliability.

For those who've built MEV searchers or similar Ethereum tooling, what turned out to be the hardest part to get right once you moved beyond the theory?

I'm happy to discuss what I've been exploring and exchange technical ideas.

A year ago, CoinDrop was a small Discord bot that let people in a handful of servers tip each other crypto.

Today, it has:

• 6,500+ users across 500+ communities
• 100,000+ withdrawals processed and $2M+ moved on-chain
• 500+ assets across 26 chains
• Discord, Telegram, Kick, and a web wallet, all sharing one balance

I built CoinDrop as a solo developer, and most of the infrastructure and product development has been done by me.

A few things I didn't expect:

1. Tipping is the easy part.

The actual tip is basically a database update between two users.

The difficult parts are at the edges.

Deposit APIs can report the same transaction more than once. Withdrawals have to be designed so that a retry, timeout, or process restart can never accidentally send the same withdrawal twice. And once you're supporting 26 chains, every chain has its own way of confirming transactions, handling fees, deriving addresses, or dealing with failures.

If I were starting over, I'd design the deposit and withdrawal pipeline first and build the fun commands afterward.

The commands are what users see. The wallet infrastructure is what keeps everything running.

2. Every new chain is a new set of edge cases.

Supporting another chain isn't just adding an RPC URL and calling it a day.

Bitcoin-style UTXO chains, Ethereum-style account-based chains, and memo-based chains such as XRP and WAX all require different approaches to deposits and withdrawals.

Sometimes the ecosystem itself dictates how you build things. For example, WAX's best signing library for our use case is JavaScript, while most of CoinDrop is Python. So WAX runs through a small Node.js sidecar that the Python backend communicates with over localhost.

The more chains you add, the more infrastructure you have to maintain.

At some point, "supporting another chain" means supporting another collection of failure modes.

3. Small coins turned out to be some of the best customers.

I initially assumed the biggest communities would drive most of CoinDrop's growth.

Instead, some of the most engaged projects have been relatively small tokens.

One example was ETH II. The token didn't have an exchange listing, so its holders used CoinDrop to tip and distribute the token to each other. It gave the community a way to actually use the token while the development team worked on the project.

That changed how I thought about CoinDrop.

A token doesn't necessarily need millions of users to benefit from distribution infrastructure. A small community that is highly active can be more valuable than a much larger community that doesn't actually move anything.

Today, projects can pay a one-time fee to get their token supported by CoinDrop. Transaction fees then provide the recurring revenue: 0.5% on deposits and withdrawals, while internal tips are free.

4. Reliability became more important than features.

One of the biggest lessons from running CoinDrop has been that users don't really care how many features you've added if their withdrawal doesn't arrive.

I've spent significantly more time than I expected working on withdrawal queues, retries, rate limits, transaction monitoring, wallet balances, RPC failures, and making sure a failed process doesn't result in duplicate payments.

At one point, a rate limit from an external Litecoin service could cause withdrawals to get stuck. That kind of problem isn't particularly exciting to build, but fixing it is far more important than adding another command.

Eventually, the goal became simple:

If CoinDrop says a withdrawal is processed, it needs to actually be processed.

That's probably the biggest difference between building a bot and building financial infrastructure.

What's next?

CoinDrop started as a Discord tipping bot. It now has a web wallet and works across Discord, Telegram, and Kick, with the same underlying balance across all of them.

The interesting part now isn't just tipping.

It's building infrastructure that lets communities hold, send, distribute, and withdraw crypto wherever their communities already exist.

I'm still figuring out where that goes.

Happy to answer anything about running a custodial crypto wallet, building multi-chain deposit and withdrawal infrastructure, or growing a niche crypto product from a few users to its first several thousand.

If you want to try it, it's at coindrop.cc

I've been building a small Python tool that watches a wallet on BSC, Base, Ethereum, Polygon and Arbitrum and tries to answer "who is behind this transfer" instead of just showing what moved.

The heuristics are simple on purpose:

- Freshly funded wallet: the sender was created or funded recently, and the funding source looks like a private wallet rather than an exchange

- Dormant wallet: no activity for 14+ days, then it suddenly sends

- Coordinated buys: several wallets buy the same token within a few seconds with similar amounts

Each hit gets a 0-100 score, plus liquidity, market cap and token age from DexScreener. Tokens outside your thresholds are filtered out.

Things that bit me:

1. Public RPC endpoints rate-limit fast. Own key plus retry with exponential backoff fixed most of it.

2. Without filtering big tokens (WBNB, USDT) early, most alerts are noise.

3. "New wallet" alone is a weak signal. It only means something when combined with the others.

4. If you don't persist what you already alerted on, every restart re-sends old transactions.

It only reads public chain data. No private keys, no signing.

I'd like technical feedback on two things: (1) better ways to tell "funded by an exchange" from "funded by a private wallet" without paid labeling data, and (2) how you handle reorgs and missed blocks when polling over free RPCs.

Disclosure: I'm the author and I sell this as a paid tool (full source code, $49, includes 7 days of setup help): https://www.getly.store/product/tx-analyzer-evm-wallet-monitor-telegram-alert-bot

I maintain a small custom timelock where an operation stays executable forever after its delay. I initially thought moving to OpenZeppelin's TimelockController would solve that, but it has the same behavior: a ready operation remains ready until execution or cancellation.

For systems that require stale operations to expire, where do you enforce the grace window? In a TimelockController extension, in the Governor, or through an external cancellation process?

I am especially interested in what happens after expiry: whether the same operation can be scheduled again, who may do that, and whether the new schedule should require a different salt.

I run a frontend that reads the same contract on six EVM chains from free public RPC endpoints. Everything below cost me real downtime.

Endpoints rot per method, not wholesale. This is the one that actually hurt. Two providers put eth_getLogs behind an archive token or dropped it entirely while continuing to serve eth_call and eth_blockNumber perfectly. Every naive health check, mine included, called them healthy. The canvas went blank on 4 of 6 chains and the page header kept rendering fine, because the header only needs eth_call.

The fix is to probe an endpoint the way the app actually uses it, not the way a status page would: chain id, CORS from the real origin (a CORS failure from your deployed origin is invisible in curl), and a real getLogs at that chain's own chunk size. If the probe is not a miniature of your actual read path, it is decoration.

I got that last part wrong in my own probe for months, in the other direction. It only ever tested a window starting at the deploy block, so it graded every endpoint on archive depth. But the app doesn't read from the deploy block any more, it scans forward from a snapshot, so the live path only ever asks for the most recent few thousand blocks. The probe was calling endpoints unusable that were serving my actual traffic perfectly well, and I believed it. It now runs both windows and reports them separately, because "cannot serve archive" and "cannot serve anything" are different and only one of them is an outage.

getLogs chunk sizes are not portable. One chain caps the range at 1,000 blocks. Another needs 500k-block chunks to keep the call count survivable. The one alternative provider for that chain caps at 10k, which makes it useless as a substitute even though it looks like a valid fallback. Chunk size has to be per-chain config, and a fallback endpoint is only a fallback if it can serve the same range.

viem specifics that cost me time. http() defaults to a 10 second timeout, which is long enough that a dead endpoint stalls a page load rather than failing over. fallback() always walks its list from index 0, so the first endpoint absorbs every request and its rate limit is your rate limit; if you want spread you need your own rotation. And multicall's batchSize is bytes of inner calldata, not number of calls, which I discovered the way you would expect.

A rewind must only ever move the cursor backwards. My worst bug: a keep-current pass set the cursor to head - depth * 4 outright. On a slow chain that is a rewind, which is what it was written to be. On a chain minting 600 blocks a minute it is a 700-block skip forward, silently dropping events. cursor = min(cursor, head - depth * 4) is the whole fix and it should have been the whole implementation.

Cold loads. I ended up not reading history from RPC at all on first paint. The data I needed was already in each transaction's calldata, so a cron decodes it into a KV store and the browser fetches one snapshot and scans forward from there. That took a page load from ~126 RPC calls to a handful. The constraint that shaped it: Workers KV free tier allows 1,000 writes a day, so the rule became never write on a schedule, only on material change. A cron that writes every run will eat that quota before lunch.

It kept happening while I was writing this. Two of the six chains rotted in the same week, which is the reason I finally wrote any of this down.

On one chain the single surviving endpoint tightened its getLogs range from 9,500 blocks to 5,000, with no announcement I could find, and that is under the chunk size I was asking for. Nothing broke visibly, because the paginator halves the chunk and retries, so it just silently cost three failed calls before every successful one. Then two days later that same endpoint stopped serving getLogs altogether: 30 second server-side timeout, while eth_call and eth_blockNumber kept answering in under 50ms. Per-method rot again, on the endpoint I had just finished documenting as the reliable one.

Slow failure turned out to be worse than fast failure. A dead endpoint gets skipped in milliseconds; one that accepts your request and times out at 30 seconds stalls whichever unlucky page load rotation sent its way. I pulled it from the pool entirely, and that chain now has no endpoint at any price that will serve a deploy-block query, so the snapshot is not an optimisation on that chain any more, it is the only way the history is readable at all.

Meanwhile a second chain's two main public endpoints both dropped their getLogs range to 2,000 blocks, four days after passing the same probe at 9,500. Both are operated by the same company, which is worth noticing: I had four endpoints listed for that chain and thought I had redundancy. Two were the same operator, one had been discontinued, and one had started answering invalid params to every getLogs call. Count operators, not URLs.

Context if it matters: it is a million-pixel canvas contract deployed on six chains, and the contract was genuinely the easy part. I am happy to go deeper on any of this, the RPC probing especially, since I could not find anyone else writing about the per-method failure mode.