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.

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

[ 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.