One thing that seems pretty common with Web3 projects is that almost everything happens in separate places. You use the actual app to interact with contracts, connect your wallet or manage whatever you're doing onchain, but then you have to go somewhere else to ask questions, discuss updates or talk to other users. It gets even more annoying when the community is supposed to be part of the product. Someone might be using a dApp regularly but still needs to join a separate server, find the right channels and figure out where everything is happening. For smaller projects I get why this happens. Building messaging into an app probably isn't something most developers want to spend time on when they've already got enough to work on.

But there are messaging protocols like Towns that let developers integrate chat into their apps, with private spaces and programmable access permissions. Seems like that could make sense for projects where users are already connecting wallets and interacting with contracts. There's also the community side of it. Instead of having people spread across different apps, you could have discussions, project updates and certain onchain features in one place. Especially for projects where membership or access depends on what someone holds in their wallet. Obviously not every dApp needs its own chat. If people are only opening it once in a while to make a transaction, there's probably not much reason to build a community around that. But for apps where people are coming back regularly, having everything connected seems a lot more practical than sending users off to another platform.

Measured from chain state today: 19,630 ETH is claimable across 220,827 addresses in six 2016–2017 contracts whose front-ends are long gone. EtherDelta V2 alone accounts for the bulk; the largest single holder is owed 604.22 ETH and hasn't touched the wallet since 2017.

The technical part is trivial and always has been. balanceOf(address token, address user) with token 0x0 returns your ETH balance, and withdraw(uint256) pays msg.sender. No approval, no allowance, no owner involvement — it is permissionless and always was.

So the money isn't stuck because of a bug. It's stuck because nobody knows they have a claim. Of the top 400 holders, 97% signed at least one transaction historically, but only 4.5% have signed anything in the last twelve months.

I built a read-only checker: https://jlicerio.github.io/etherdelta-claims/

It reads all six pools in one public eth_call and prints the exact transaction to release each claim. No wallet connection, no signature, no key input, no cookies, no analytics, no server-side code — it's a static page you can audit, and it prints the raw JSON-RPC body so you can replay it against any node with curl.

Two honest caveats. If you have lost the key to the address, none of this helps and the balance is unrecoverable — that is very likely true for a meaningful share of them. And this is my own tool, so treat it with appropriate suspicion and verify the numbers against Etherscan's Read Contract tab.

The point of the post is that the claim probably exists and takes one transaction to take.

I lead the ethdebug format, an open specification for compilers to use to produce debug data alongside their output bytecode. This allows tools to see things like which source range an EVM instruction corresponds to, where variables live in the EVM during a transaction, etc. Without it, tools can't be sure about compiler output without a lot of guesswork, and guessing is brittle.

I'm sharing this post here because I hope some of you would find this work interesting. If you build tools that decode storage or traces, I'd love to hear from you!

I have been coding is solidity for half a year now. Initial phase was quite tough to be honest even understanding a counter program drained me. But now it's opposite, it might sound weird but i am running out of contracts now. I haven't hit any client yet so i have no idea what contracts are used in industry and are made and audited. But i know the logic and can make and understand contract now. But i am tired of making and practicing same escrow contracts again and again. Is there someone who know a website where i can find sample contract which are actually good and are used in industry. It would be a great help in short i have covered the basics (more than basics) but am running out of contracts and resources now. Anything would help....Any repo, website someone's audited personal contract .......Would appreciate the help .....Thanks for your time :-)

I work on eRPC (Goldsky), an open-source (Apache-2.0) RPC proxy you run in front of several providers.

Common bug: you send a tx, poll eth_getTransactionReceipt, and a provider a few blocks behind says null. viem's fallback() switches transport only on an error, so null counts as success. Your app waits or times out.

eRPC treats a null receipt as "this node may not have it yet" and asks the next provider.

Local test, lagging node ranked first: 40/40 mined receipts returned, 0 nulls. Unknown hash: null after 1 ask per provider, no retry loop.

https://github.com/erpc/erpc

How do you handle receipt nulls today?

I've been building an open source node RPC platform for the past year and what I've realized during this journey is that, for the most part, you shouldn't use raw node RPC for indexing smart contracts.

Node RPC is a tricky api to integrate reliability for an indexing stack. The backfill->live handoff is particularly tricky and I've built enough indexers to know that rolling your own event consumer for this is usually not worth it.

You can pay a lot for indexers that do it all for you, but I think the best happy medium is to consume a raw, repayable stream for any set of events you care about. Use a simple pull loop or use SSE over raw http to backfill and consume live blocks for any smart contract event you care about. Works with pretty much any app and is simple to integrate.

I'm shipping exactly this in lasso.sh and looking for beta testers! I've built a very lively dashboard where you can monitor the streams you're subscribe to and get a deep look into the latency and performance properties of these streams.

Trying to ship this with dirt cheap event streams, and while other providers do have similar streaming-style features for onchain events, they are more expensive and more complicated than they need to be.

Please comment or dm if interested!

Hello everyone,

I am an independent Home Staker looking to join an Obol DVT cluster. I am looking for a Zero-Bond / Institutional or community squad that needs a highly reliable node to increase geographic and client diversity.

My node is fully synced, monitored via custom PDCA Bash scripts, and optimized for maximum resilience.

Infrastructure Details:

• Location: Spain, EU (Geographic decentralization)
• Hardware: Enterprise Bare-Metal HPE ProLiant Gen10 (Strictly NO Cloud / AWS / VPS)
• OS: Red Hat Enterprise Linux 9 (RHEL 9)
• Execution Client: Reth
• Consensus Client: Nimbus

Running minority clients on enterprise bare-metal ensures optimal network health and anti-slashing safety.

**My Obol ENR:**enr:-HW4QEMOWSxTB32Ij06TW5BrE2APMWF5EwnHcjoy8AL83nBmBOkOOhJewBbGwEXhtA6G2CvBcyYXa-xWAYrczXFlGFGAgmlkgnY0iXNlY3AyNTZrMaEDyowVMwA41dbTRwGDWzTDy9mJFeWOyxeuZp7-5-Qi1H4

I am currently on standby. Once a cluster is formed via the Obol Launchpad, I am ready to sign the distributed key generation, receive the cluster-lock.json file, and immediately spin up my Charon container to start validating.

Please DM me or reply to this thread if you are forming a cluster and need a reliable EU operator. Ready to deploy.

Hello everyone,

I am an independent Home Staker looking to join an Obol DVT cluster. I am looking for a Zero-Bond / Institutional or community squad that needs a highly reliable node to increase geographic and client diversity.

My node is fully synced, monitored via custom PDCA Bash scripts, and optimized for maximum resilience.

Infrastructure Details:

• Location: Spain, EU (Geographic decentralization)
• Hardware: Enterprise Bare-Metal HPE ProLiant Gen10 (Strictly NO Cloud / AWS / VPS)
• OS: Red Hat Enterprise Linux 9 (RHEL 9)
• Execution Client: Reth
• Consensus Client: Nimbus

Running minority clients on enterprise bare-metal ensures optimal network health and anti-slashing safety.

My Obol ENR:enr:-HW4QEMOWSxTB32Ij06TW5BrE2APMWF5EwnHcjoy8AL83nBmBOkOOhJewBbGwEXhtA6G2CvBcyYXa-xWAYrczXFlGFGAgmlkgnY0iXNlY3AyNTZrMaEDyowVMwA41dbTRwGDWzTDy9mJFeWOyxeuZp7-5-Qi1H4

I am currently on standby. Once a cluster is formed via the Obol Launchpad, I am ready to sign the distributed key generation, receive the cluster-lock.json file, and immediately spin up my Charon container to start validating.

Please DM me or reply to this thread if you are forming a cluster and need a reliable EU operator. Ready to deploy.

Last week we launched SwapChan (swapchan.com), a swap aggregator with an MCP server so AI agents can quote and build swaps. This week was mostly about one question: how much money is just sitting out there, forgotten?

Why we built it. I went looking for forgotten money by hand in old contracts and wallets and found about $4,000 of my own. It was tedious, and it seemed like an agent should be able to do it. So we built the tools.

You can do this with your own address right now. Go to https://swapchan.com/find-money, paste your public address (or a list of them), and it shows what's sitting unclaimed for you and builds the exact transaction. It's free, there's no signup, you never paste a seed phrase, and you sign everything in your own wallet. Or point your AI agent at the MCP server and tell it "find my money."

What we shipped

• find_money: give it a public address and it checks a registry of known stuck and forgotten money spots, then digs through the wallet's history for old contracts it touched (vaults, LPs, v3 fees, old DEX balances). Works on EVM chains, Tron, Solana and BTC.
• find_money_batch and find_money_status: paste up to 500 public addresses, labeled or not. The scan runs in the background, survives restarts, and comes back with a total, keeping exact amounts separate from estimates, plus a ranked plan to recover and swap.
• read_chain: a general read-only chain reader for agents.
• swapchan_playbook: teaches agents how to chain the tools together. Every tool description points to it.
• signing_guide, verify_tx, broadcast_tx, plus status tracking: the agent builds the transaction, verifies it, and you sign it in your own wallet. Every payload we return is checked on our server too: router allowlist, calldata decode, recipient, minimum out, value and approvals. If any check fails, nothing is returned.
• recovery_guide: if you have an old recovery phrase, it explains how to derive many addresses from it (gap limit 20 to 50+, 10 common wallet paths, passphrase candidates) and scan them with a script that runs locally and offline. Never paste a seed phrase into a chat, ours or anyone's.
• Per-contract pages starting with PoWH3D, plus a hub at https://swapchan.com/find-money

SwapChan never signs, never holds keys and never holds funds. You sign everything.

SwapChan is always free to use and ad-free, and it never controls any money. There are no subscriptions and no way to pay SwapChan. The only way we make money is a tiny fee on swaps.

What it found

We pointed it at Liquity v1's CollSurplusPool. When a trove is redeemed or liquidated above the minimum ratio, the leftover ETH waits there until the owner calls claimCollateral(). Right now 1,625.86 ETH (about $3.80M) is waiting for 195 wallets.

Two of them stand out:

• 0x4E4…: 141.30 ETH (about $330,300), no outgoing transaction since Nov 2022
• 0x151…: 131.32 ETH (about $307,000), no outgoing transaction since Feb 2025

Nothing is lost and nobody else can take it. One zero-value claimCollateral() call from the owner's wallet gets it back. If one of those is yours, run your address through find_money and it will build the transaction for you to sign.

As a sanity test we also scanned vitalik.eth (a public address): about $4,563 across 53 items.

(Prices at about $2,334.50/ETH, read at Ethereum block 26,264,722 on Oct 24, 2026.)

Thanks

• u/Bloqarl on r/ethdev flagged the Relay verification issue. SwapChan now checks every Relay deposit against the Relay Protocol v2 order (recipient, minimum out, order ID, canonical depository) and refuses anything that doesn't match. Thank you.

If you find a bug or something that should be on the stuck-money list, tell us. We'll fix it and credit you in the next update.

Try it with your own address, right now: https://swapchan.com/find-money

We see this problem constantly: a small, independent team builds a great MVP on evenings and weekends, but they have no legal entity, no audit, and no corporate history. Traditional VCs won't touch them, and a pure token launch is a massive legal liability (courts are increasingly treating anonymous DAOs as general partnerships).

At November19, we are experimenting with a different structure: financing the asset, not the company.

Instead of building a corporate shell first, the rights to the asset (future revenue, product rights) are held by a Cayman Foundation Company (a memberless foundation). The tokens representing these rights are structured as securities for qualified investors.

Here is how the governance works to prevent founders from just running off with the funds:
1. The Board: Has independent directors who are legally bound to act in the fund's interest, not the founders'.
2. The Split: Token holders vote on the budget and replacing contractors. The Board handles compliance and fiduciary duties.
3. The Enforcement: Because it’s a registered Cayman entity, if the team breaches the agreement, holders have actual legal recourse in court. It’s not just a handshake in a Discord chat.
We are documenting this whole experiment (we are heavily inspired by the PACT framework, but adding the legal teeth).

I’m curious to hear from the devs and legal folks here: Do you think this separation of control (team) and ownership (community) is viable for early-stage Web3? Or does it just recreate traditional corporate bureaucracy?

Read the full breakdown here: https://t.me/nvmbr19

Hi all, I’m researching wallet infrastructure options for a DEX and would love to hear from you guys who’ve actually used them and can share some experience.

Some context:

• Target chains: multi-chain
• Users: mostly crypto-native but want crypto beginners to involve as well
• Custody model non-custodial

What I’m trying to understand:

1. Architecture trade-offs. MPC/TSS vs. smart contract wallets (ERC-4337, passkeys, session keys) vs. traditional key management. What are the good and bad side of them?
2. Providers. If you’ve used any of Turnkey, Privy, Dynamic, Web3Auth, Coinbase CDP, Safe, or others, how was the real experience? ike integration effort, reliability, latency, and support quality.
3. Key recovery and security. How do you handle recovery, and how much do you depend on the vendor? What happens if they go down or you want to migrate away?
4. Cost at scale. Did pricing (per-wallet, per-signature, MAU-based) become a problem as you grew?

Thanks in advance!

I'm a solo dev and built SwapChan, which queries several aggregators and bridges in parallel and ranks routes by net output after gas and fees.

Things that were harder than expected: - normalizing quotes (CoW returns an order, not a tx; bridges report ETA and fees differently) - comparing "net USD" fairly when gas is on a different chain - Permit2 vs exact approvals

There's a REST API and an MCP server for agents, both free and keyless. Docs: https://swapchan.com/agents, plus https://swapchan.com/llms.txt

Disclosure: there's a 0.1% fee on swaps. Happy to go deeper on any of the integration details.

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

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?

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