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

I've heard about bots that can do more than just send price alerts, like interacting with smart contracts and making transactions using their own wallets. Anyone here ever built or tried something like that? If you have, what did you use it for and how difficult was it to get working? I'm especially interested in how people handle giving a bot access to a wallet without putting too much at risk.

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?

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.

I’ve been thinking about different ways to handle membership for a project. Say someone gets access to a private part of the community because they hold something or meet some other onchain condition. If they stop meeting that condition, should their access disappear automatically too? I can see the benefit of tying permissions directly to something you can verify onchain, but it gets weird when someone has been a useful member for months and then suddenly stops meeting whatever condition originally got them access. For anyone who has built something like this, do you let wallet state directly control permissions or use it as one signal and handle the rest separately?

Hi everyone,

I am a 15-year-old high school student from Europe studying to become an electrician. In my free time, I’ve been fascinated by blockchain technology and decided to learn Solidity and Web3 development.

I just deployed my very first experimental token called Nexora (NXR) on the Ethereum Sepolia Testnet (Contract: 0x8B9F2eE3570D0b7d9c607ED6B3Ff13ab00F3638D).

To practice my skills, I also built a simple landing page for it using HTML/CSS/JS and hosted it through GitHub Pages. The repository is completely public and open-source.

• Website: https://lotshaus.github.io/Nexora-NXR-open-source-ERC-20-blockchain-project/
• GitHub Repository: https://github.com/Lotshaus/Nexora-NXR-open-source-ERC-20-blockchain-project

Since I am a beginner, I would love to get some honest feedback from experienced developers.

• Is my repository structure okay?

Thank you so much for your time and any advice you can share!

Hi

Stepped away from this area for... well, over a year. Probably more.

Looking to create a basic Dapp, and got up to the point of Wallet Integration.

Hit a bit of a wall with this because it seems it's either
- use Appkit or Rainbow Kit, have to get a "project ID" and analytics, tracking???? Yikes
- use Wagmi/viem and just code all my own other stuff, ui etc
- option 3... ? Not even sure.

What's the standard best practice for simple, easy wallet integration on a website?
Preferably without having to submit a project id, because... Why? It's not a complex dapp and I don't need their integrated RPC/swaps/onramp.

The problem is, if I want people to access via Mobile it seems WalletConnect is like the ONLY method. Is this true?? Because I do not like the idea of tracking/analytics/needing to beg for an ID for people just to get involved with my project. Things are supposed to be DEcentralized...

Thakns all

The old OpenSea proxy drains had victims sign upgradeTo(impl) on their own OpenSea proxy. The to address is a legitimate verified contract from 2018; the malicious logic sits in impl.

I took 19 of these transactions from the PTXPHISH dataset and queried GoPlus twice for each one, changing only the address.

Query tx.to: 0/19 flagged
Query impl: 18/19 flagged

Important caveat: those 19 rows map to only 5 implementation contracts, so this is really 4/5 implementations being detected, not a meaningful 18/19 detection rate. And these drainers are labelled today, so this says nothing about what GoPlus knew at signing time.

For this specific OpenSea class, a simple warn on any upgradeTo also works: of 1,179 OpenSea proxies I sampled, only 2 were ever upgraded, both to the same drainer.

But that heuristic falls apart for general proxies. Across 800 EIP-1967 upgrades, it would warn on all 422 implementation addresses, whereas querying the implementations flags only 4. I’m not claiming the other 418 are clean.

The point is narrower: reputation checks are only as useful as the object you choose to check. With proxy upgrades, checking only tx.to can mean asking about the wrong contract entirely.

Details, code and raw outputs: https://amarshat.github.io/quantum-commit-authorization/wallet-defenses.html#ask-the-right-address

Been looking at how apps handle permissions that depend on something a wallet currently owns and there's one part I'm not sure how people handle cleanly in production. Say someone signs in with Ethereum and owns an NFT that gives them access to a private part of the app. They pass the ownership check then transfer the NFT a few blocks later. Their session is still valid but the condition that gave them access isn't anymore.

Checking ownership on every request would keep things current but now an RPC call is sitting directly in the request path. Caching the result avoids that but you're accepting a window where someone can keep access after they no longer qualify. Event based invalidation seems like another option but I assume you'd still want some kind of re-check rather than relying entirely on a listener staying in sync.

I ran into this while reading through Towns. Their Spaces can use onchain memberships and entitlement rules for access including cross-chain conditions. That's where it gets more interesting because a single permission could depend on state coming from different chains with different block times and different views of what's current.

There's also the question of what state is good enough. Ethereum RPC lets you query against latest, *safe and *finalized. I doubt every permission needs finalized state but read access to a private channel and letting someone use a bot that can perform an onchain action probably shouldn't be treated the same either. ERC-4361 helped separate the problem a bit for me. The wallet session proves control of an address but the properties associated with that address can change while the session is still active.

So the part I'm unsure about is how people handle that authorization layer in practice.

Do you cache low risk permissions and re-check before anything sensitive? Use events for invalidation with RPC checks as a fallback? And if you've worked with cross-chain conditions how do you decide when the state you're getting back is recent enough to use?

Edit: Grammar

• Sources:

• Ethereum JSON-RPC https://ethereum.org/en/developers/docs/apis/json-rpc/

• ERC-4361 https://eips.ethereum.org/EIPS/eip-4361

• Towns Protocol https://github.com/towns-protocol/towns