My brother and I are building Twirl, a prediction-market platform, and this week we worked on a problem that sounds simple until money is involved:

What happens when a user places an order, but the trading engine doesn’t give you a clean response?

Previously, an order could depend too heavily on an immediate response from the CLOB.

We’ve now changed the flow so Twirl first records the order and reserves the correct funds or trading position before sending the request to the trading engine.

Each order also gets a Twirl-owned unique reference.

That means retries reuse the same identity instead of accidentally creating a second order.

If the trading engine is slow or the outcome is unclear, Twirl doesn’t immediately assume the order failed and release the user’s funds.

Instead:

• The recorded order remains the source of truth.
• Retries happen safely within a limit.
• Unresolved orders remain locked rather than guessed.
• Sell positions stay reserved while the state is uncertain.
• We added protection against duplicate executions and late fills after cancellation.

The backend test suite currently passes 339 tests with no failures.

We’re still not treating this as real-money readiness.

Remaining work includes PostgreSQL migration rehearsal, full reconciliation after outages or mismatches, atomic fill/cancellation handling, oracle and settlement safety, and proving the frontend recovers correctly from refreshes, offline states and failed responses.

For anyone who has built trading or payment infrastructure:

How do you handle orders where the client times out but the backend or matching engine may still have processed the request?

And what’s your preferred approach to distinguishing “failed” from “unknown” in financial systems?

Dshackle is a load balancer that sits between your app and your blockchain upstreams (your own Geth, Infura, QuickNode, any mix of them). It tracks each upstream's block height, sync state and supported methods, and routes each request to one that is healthy and caught up.

- JSON-RPC over HTTP and WebSocket
- Automatic failover and retry
- Tracking upstream status
- Height-aware method routing
- Chain-aware caching (in-memory or Redis)

v0.18 is a rewrite from Kotlin/JVM to Rust. There are no new features. Config, API and behaviour are the same. Memory use is down ~75% and latency is 10–20% lower.

https://github.com/emeraldpay/dshackle

Solidity v0.8.38 fixes a low-severity bug in the Yul optimizer, makes compilation with the Yul optimizer faster, and warns about identifiers in Yul and inline assembly that are going to be reserved starting from the Amsterdam EVM version.

Yul optimizer bug fix

• When a Yul variable used to compute memory or storage addresses was reassigned, the Yul optimizer did not always notice that its knowledge about those addresses had gone stale.
• As a result, a load could be replaced with an outdated value, or a needed store could be removed.
• Versions 0.8.19 to 0.8.37 are affected, only with the Yul optimizer enabled.
• With --via-ir, any code may be affected. With the default evmasm pipeline, only compiler-generated Yul utility functions and some inline assembly blocks may be affected.
• The fix changed no bytecode in verified contracts on Sourcify, which suggests the bug is very rare.
• The write-up has the details and explains how to check your contracts: Yul Optimizer Knowledge Base Stale Bookkeeping Bug

Other changes

• The release improves the performance of the DataFlowAnalyzer, which several Yul optimizer steps are built on. As a result, compilation with the Yul optimizer enabled is faster.
• In the IR pipeline, the function dispatcher now uses one fewer instruction to check that the calldata is long enough to hold a function selector.
• The compiler now warns when swapn, dupn or exchange is used as an identifier in Yul or inline assembly. EIP-8024 adds opcodes with these names in the Amsterdam network upgrade, and the names become reserved starting from the Amsterdam EVM version. Solidity identifiers are not affected.

Links

• Release post: https://soliditylang.org/blog/2026/10/22/solidity-0.8.38-release-announcement/
• Full changelog and downloads: https://github.com/argotorg/solidity/releases/tag/v0.8.38

I run a small audit firm, so weigh my bias.

curl 8.23.0 shipped earlier this month with 24 security fixes, and most were found with AI-assisted research. The same thing is happening onchain, if you've seen in Anthropic’s SCONE-bench, agents wrote working exploits for about half of 405 real hacked contracts, at around $1 a run...

What this basically means is that the quiet window after deploy is basically gone. Anyone can point an agent at your contracts the hour they go live, so “audit once we have traction” is a worse bet than it used to be.

What’s one thing you do before mainnet now that you didn’t a year ago? Which Claude skills are your must-run?

remittance product for us brazil corridor, brazil has pix making the local receiving side fast n finding infra that handles us origination with proper msb licensing plus usdc to brl conversion and pix delivery cleanly has been the challenge

most options strong on us origination but brazil specific pix integration is either missing or via third party partner adding uncertainty, anything handle this end to end?

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

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.

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.

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?

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

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

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.

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.

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