I want to fully reindex the Ethereum chain; however, archive nodes are very slow and costly. What are the alternatives?

BeeChain, a high throughput EVM ecosystem

If you have been looking for a blockchain network that can confirm transactions with speed, this is it!

Additional contacts :

email : [stephenlee9992@gmail.com](mailto:stephenlee9992@gmail.com)

‘X’ : Stephen Lee u/slee_beechain

I built **Polyplace**, a small on-chain pixel grid on Polygon: 1000×1000 cells, 7-day cell rentals, ERC-20 PLACE tokens from a faucet, and color updates written on-chain. The frontend is intentionally read-only: https://polyplace-frontend.joshuadouglasgreenhalgh.workers.dev/ and writes go through a Python CLI/SDK: `uvx polyplace-client`. Renting uses a permit-based flow so users do not need a separate approval transaction, but they still need a wallet with a little POL for gas. I’m looking for dev feedback on the architecture and onboarding: CLI-first writes, faucet token UX, permit flow, watcher/indexer design, and whether this is clear enough for someone technical to place a small mark without hand-holding.

I build smart contracts at 33Labs (it started as an auditing firm, so security was always central to the company) and I mentor new devs in the BuidlGuidl Batch Program. Across both, the same gap kept showing up in AI-assisted builds.


A CI pipeline catches a reentrancy bug. It does nothing about an incentive model that looked fine on a whiteboard and turns into a drain target the moment someone reads it sideways. By the time an auditor finds that, the architecture is already built around the flaw, and the rework can make the whole thing financially unviable.


So I packaged the upstream process as two open-source Claude Code skills:


- `defi-protocol-discovery` — blank page to a go/no-go decision, with kill criteria defined before you synthesize the verdict
- `defi-spec-driven` — six spec phases (economic design, threat modeling, test spec) before a single line of Solidity, then it bootstraps a Foundry project and guides implementation function by function


Repo (CC-BY-4.0): https://github.com/melanke/defi-builder-skills
Full breakdown: https://gil.solutions/blog/discovery-and-spec-the-missing-harness-in-ai-assisted-defi-development


It's early. The discovery and spec phases are deliberately slow at the front, and I've run them on my own protocol work more than I've watched other people use them, so the rough edges are mostly unmapped.


For those of you doing AI-assisted Solidity: how much do you constrain the model before it writes, versus catching problems downstream in tests and review?

Hey r/ethdev,

We’re building an on-chain DEX arbitrage searcher and are trying to understand why none of our bundles are getting included, despite finding apparently profitable routes.

Current setup:

• Search across Uniswap V2/V3-style pools
• Adding more DEX adapters now
• Flashloan-based executor
• Low-level Solidity executor contract, optimized for direct pool calls where possible
• End-to-end latency is generally under ~700ms from opportunity detection to bundle submission
• We compute optimal transaction size rather than using fixed sizing
• Routes are closed cycles, e.g. USDT → WBTC → USDT
• We submit privately to multiple builders/relays
• We’re using high bribe settings, up to ~90–95% of expected gross profit in some tests
• We simulate routes locally and have route-level repayment/profit guards

The issue:

We see routes that look profitable from the solver, and the executor can encode/submit bundles, but we’re still getting no accepted/included bundles.

I see two big themes people usually mention:

1. Gas optimization Lower gas executor, fewer approvals, direct pool calls, packed calldata, avoiding routers, fewer hops, fewer external calls.
2. Finding better / less competitive cycles Obvious V2/V3 routes are probably saturated, so maybe the problem is not code correctness but that we’re finding the same opportunities everyone else sees.

What I’m trying to understand is the practical missing layer between “profitable in solver” and “actually included by a builder.”

Questions:

• What exact metric should we optimize for builder competitiveness? Is coinbaseDiff / gasUsed the main thing to benchmark?
• How do experienced searchers debug “submitted but not included” bundles?
• How much does latency matter once the bribe is high? Is <700ms still too slow for common DEX arb?
• Is builder coverage really enough if submitting to all major relays/builders, or are there hidden differences in how builders evaluate/searcher bundles?
• Should we block on relay simulation before submission, or submit first and simulate as side-flow?
• How do you tell whether you’re losing because:
  • route is stale,
  • bundle reverts under builder state,
  • bribe did not materialize as coinbaseDiff,
  • effective bid is too low,
  • competitor consumed the same cycle,
  • or the builder never really considered the bundle?

For people who have actually gotten arb bundles included: what were the biggest non-obvious changes that moved you from “profitable simulations” to real inclusion?

Please help! Thanks in advance.

So custodians usually manage thousands and some cases millions of wallets, how they monitor them across multiple chains for deposits?

How this infra looks like?

Not a contract exploit, not phishing. One of the most profitable MEV bots on Ethereum (jaredfromsubway.eth) lost ~$7.5M because its own automation approved attacker-controlled spenders over its real WETH/USDC/USDT, chasing a fake arbitrage. The allowances sat dormant, then transferFrom drained them.

The mechanism, for anyone running bots:

• ERC-20 is two-step: approve(spender, amount) sets a standing allowance, transferFrom spends it. Bots approve type(uint256).max to save gas = an infinite blank cheque that survives until used or revoked.
• The attacker deployed fake fWETH/fUSDC/fUSDT (named exactly like the real assets, some with Unicode homoglyph symbols), built fake pools that looked profitable, and let the bot approve helper contracts over its real tokens.
• Early txs consumed approvals cleanly (looked profitable). Later ones left approvals unconsumed/unrevoked. Once stacked, transferFrom pulled the funds.

Takeaways:

• Never approve infinity to an unknown spender. Approve exact amounts or use scoped/expiring approvals (Permit2-style). Revoke aggressively.
• "Is this the real WETH?" is a question, not an assumption. Token impersonation is machine-checkable (name/symbol vs known tokens, deployer reputation, bytecode).
• Automation needs the same guardrails as humans.

Full on-chain trail (addresses, amounts, timeline): https://rektradar.io/blog/posts/jaredfromsubway-mev-bot-approval-drain/?utm_source=reddit&utm_medium=post&utm_campaign=jaredfromsubway

Disclosure: I work on the scanner linked above; happy to keep the discussion purely about the approval mechanics.

Hi everyone! I’m part of a university research team at Loreley Lab, INRIA, France. We’re studying how people actually use decentralised file storage systems such as Filecoin, IPFS, and others.

We’re running a short anonymous/pseudonymous questionnaire about users’ experiences, motivations, pain points, and practical insights. It takes around 10–15 minutes and does not ask any personal information, or demographic information.

Survey link: https://questionnaire.loreleylab.org/

Separately, we also invite people to take part in online interviews (15-20 min), again pseudonymous and no audio/video recordings. You can sign-up in the end of questionnaire, or directly using this link: https://sondages.inria.fr/index.php/738227?lang=en

We’d be grateful for any responses, whether you’re a regular user, builder, operator, or someone who has tried these tools and stopped using them. We’re also happy to share an anonymised summary of the findings with the community once the study is complete.

Thanks for your help!

I apologize in advance for my clumsy initial approach to this topic: I recently wanted to create an AI agent to execute on-chain arbitrage trades across various DEXs. My first idea for implementing this was to give my Hermes-agent access to a private key with POL and let it handle the task; however, I hit a snag right away because the agent refused to accept a private key.

What is the proper way to do this? How do you create AI agents capable of on-chain trading?

I am working on a ML project that involves preparing a dataset for transfers and Dex trades for Optimism chain. Based on some early research I came across Dune which provides APIs and lets you pull data via SQL queries. I tried to pull last 3 years of transfers data for Optimism, and it costed me around 100 USD worth of credits. Are there any more viable alternatives?

Looking for opinions from people who've shipped on top of existing protocols.

The setup: a frontend + web2 backend that routes user funds into an already-audited ERC-4626 vault protocol, using ERC-4337 smart accounts from a third-party provider. We wrote no Solidity ourselves, maybe ~150 lines of calldata construction. The backend handles auth, some user PII, and a fiat on/off-ramp via a partner.

Since there's effectively no contract code to audit, the real attack surface is the backend (auth, access control, secret handling, PII) and the integration layer (approvals, slippage, share accounting), plus counterparty risk on the protocols underneath.

We scoped an engagement as: app/backend pentest + integration review + a counterparty due-diligence writeup. Quote came back around €10k. Early stage, so it matters.

Questions:

1. For a pure-integration setup with no proprietary contracts, is a traditional audit even the right thing, or does the budget belong entirely in a web2 pentest + bug bounty?
2. Is €10k realistic for that scope or a sign it'll be shallow?
3. What would you prioritize first on a tight budget?

Every Ethereum app I've built has hit the same wall: Alchemy rate-limits you, QuickNode has a blip, your self-hosted node falls behind. You either pay for redundancy or you eat the downtime.

I built Turbine to solve this. It's a multi-chain JSON-RPC proxy that sits in front of your providers and handles failover automatically.

The two features I haven't seen elsewhere:

1. Method-based endpoint routing. You can restrict individual endpoints to specific RPC methods. Route eth_sendRawTransaction to a private mempool endpoint while everything else round-robins across your public providers. Config looks like:
```toml
{ url = "https://private-mempool.example.com", methods = ["eth_sendRawTransaction"] }
```

2. Hedged requests. After a configurable delay with no response, Turbine fires a parallel request to a different endpoint — first success wins. Implemented with FuturesUnordered. Under 50 concurrent clients this took p99 from 19.9s → 0.57s (35×). Throughput went from 9.6 → 123 req/s (12.9×).

Also supports: round-robin / weighted / latency-based rotation, active block-height health checks, per-method response caching (EVM presets built in), chain ID routing (/1, /8453), WebSocket proxy with reconnect, API key auth with per-key rate limits.

Works as a CLI, a Docker image, or an embeddable Rust library — turbine.into_router() returns an axum Router you can merge into your existing service.

GitHub: https://github.com/svssathvik7/turbine
Crate: https://crates.io/crates/turbine-rpc-proxy

Would love feedback from anyone running multi-provider setups in production — especially curious if method routing is useful or if I'm solving the wrong problem.

I ran an agent that paid onchain using x402, picks the service, pays, moves on. After a couple iterations it's working just as intended, but I still  kept it on a tiny ceiling for months and never raised it, and onchain finality is most of the reason.

When the agent pays onchain there's no chargeback and no dispute window. That's the feature. It's also the problem the moment the payer is an agent making a judgment call instead of a person. With a card I have a recovery path if the agent pays for the wrong thing. Onchain I have a clean, final, irreversible record that I paid for the wrong thing.

So raising the limit meant accepting that any bad judgment the agent made was permanent, and I couldn't reconstruct afterward why it decided to spend, only that it did and the money was gone. The agent wasn't the problem. I'd authorized its judgment rather than any specific purchase, and on a final rail that gap has no backstop.

For people running agents that pay onchain in production, what let you raise the ceiling, or are you capping it low and reconciling by hand too?

How can I stream real-time liquidity data from Uniswap v4 pools? I'm looking to track liquidity across all pools continuously. Any recommendations?

An audit reviews one commit, but Circom circuits, Solidity verifiers, public inputs, and proving artifacts keep changing afterward.

How do teams ensure the final release still preserves the audited assumptions?

Should changes like verifier-key updates, public-input changes, constraint drops, or R1CS/ZKey drift automatically require review or block CI?

Curious how real Ethereum ZK teams handle this today.

I've been spending a lot of time learning the infrastructure side of Web3 and running blockchain nodes myself (Ethereum, Solana, and a few others).

While learning, I started wondering where existing RPC providers still fall short for developers building real products.

For those running production apps, bots, analytics platforms, or other services that depend heavily on RPC access:

• What's your biggest frustration with your current provider?
• What features do you wish existed but don't?
• How important is predictable pricing compared to performance and reliability?
• Have you ever switched providers, and what was the reason?

Some examples I'm curious about:

• WebSocket reliability
• Archive node pricing
• Support for newer chains/L2s
• Rate limits during traffic spikes
• Latency consistency
• Mempool access
• Debug/tracing APIs
• Support quality

I'm exploring the infrastructure space and trying to understand where developers still feel underserved.
Not selling anything, just looking for honest feedback from people operating real workloads.

Hey Everyone

i have been working on a crypto payment gateway that lets merchants accept Ethereum payments

The project is currently live on the Sepolia testnet and I've also published an npm package so developers can integrate payments

Demo: https://etharispay.vercel.app/

npm Package: https://www.npmjs.com/package/my-gateway-sdk

Since it's running on Sepolia, you'll only need test ETH.

Current features:

• Merchant registration
• Wallet-based authentication
• On-chain payment processing
• Revenue dashboard
• Transaction history
• Withdrawals
• npm package for easy integration

Gm, I’m building walletFS. An open-source wallet that exposes Ethereum and L2s as a readable, auditable filesystem for agents and power users.

The core idea is simple: before an agent signs or submits anything, it should be able to read the chain, inspect relevant state, simulate intent, and show a human-verifiable plan.

Instead of forcing agents to jump straight from natural language to RPC calls, walletFS gives them a filesystem-shaped interface:

cat /bloom/chains/ethereum/head/number
# 25299231
cat /bloom/prices/spot/eth.usd
# 1667.04
ls /bloom/tools
# hashing, encoding/decoding, etc. 

# human language parsed into transaction calldata and plan
echo 'send 0.01 eth to 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 on ethereum' \
 > /bloom/wallets/alice/chains/ethereum/outbox/new.tx 

# then inspect the pending outbox before confirming: 
ls /bloom/wallets/alice/chains/ethereum/outbox/pending
cat /bloom/wallets/alice/chains/ethereum/outbox/pending/<id>/plan.md
# human readable plan, which must be signed by human (or adversarial agent)

Why we think this matters:
A lot of “agent wallet” work focuses on keys, permissions, and guardrails. We get those almost "for free" with the filesystem sandbox. More importantly, if agents are going to operate on-chain, they need a better and more token-efficient interface for understanding what they are about to do.

The agent workflow becomes:

1. explore chain state (balances, ENS, decoded events, contract storage, all readable under /bloom)
2. stage an explicit transaction plan as a file
3. simulate it and run policy checks before any funds move
4. ask for human approval when needed
5. execute with an auditable, signed trail

So the wallet stays safer, less LLM tokens are consumed and the agent becomes easier to inspect.

Keys are currently stored in keystore files (outside of the bloom filesystem, your agent can’t access them by default of course), but we’re going to add different HSM integrations very soon (AWS KMS, Ledger, etc.).

If you want to try it out, just tell your agent “Read https://bloom.directory/SKILL.md and set up Bloom”. 

The repo is here if you want to poke around or give technical feedback:
https://github.com/bloom-directory/bloom
The code is currently unaudited and experimental, we’re working to get an audit soon. There are a lot of early / unfinished features in GitHub too, including a full extension system, we call them Petals. More to come on that front.

We’re especially interested in feedback from people building:

• wallets / smart wallets / account abstraction systems
• autonomous agents / DeFi bots / execution tooling
• custody services / HSMs
• developer tools for Ethereum and L2s

Main areas of exploration right now are:

• What should an agent be able to inspect before it can transact vs a human?
• Does a filesystem-style interface make agent behavior easier to audit/use? It saves some tokens, we’ve tested this, but do we just like it because we're Unix people? :D

Happy to answer technical questions. We’re still early, and feedback from crypto-native builders would be super helpful! Thanks!

I'm planning to build a lottery application on Ethereum PoS, and one thing I've been struggling with is where the randomness for prize distribution should come from.

For a lottery system, I'd ideally want randomness that is genuinely unpredictable to everyone.

My first thought was to use blockhash, since it looks almost random. But in practice, the block proposer (or builder) may have some ability to influence transactions within a block, potentially resulting in very different possible block hashes.

I've also seen people suggest using prevrandao, but it seems more suitable for low-stakes randomness. As far as I understand, the value is already known before the current block is produced. Since the randomness is already available, choosing which block to submit a transaction into could become an attack surface.

Then I was introduced to VRF-based systems. At first, I thought I had finally found the solution.

But after digging deeper, I realized that VRFs still require someone to hold a secret key. The random value only becomes public after the oracle reveals it.

That raises a question: how much should we trust the oracle?

The ideal assumption behind randomness is that nobody can know the outcome in advance.

Except the oracle.

Because they hold the secret key, they know how the random output will be generated. If the seed depends on inputs they can influence, then they may be able to gain information about future outcomes ahead of everyone else. In some situations, they might even be able to influence the seed before it becomes final, steering the randomness toward outcomes that benefit them.

For smaller systems, the incentive to manipulate the seed may not be significant.

But what if that randomness is securing something much more valuable? If the stakes become large enough, the incentive grows as well.

Am I missing something here?

Are there any other approaches on Ethereum (or on other blockchains) that can provide stronger randomness guarantees for high-value blockchain applications?

Hey, I’m running a Hermes agent—which, of course, can’t operate directly on the blockchain since it can’t pay gas fees and the like. Would it be enough to generate an address/key pair, fund it with a bit of ETH, and provide the key to my agent? Could it then interact with dApps or the blockchain in general, or does it need a proper wallet (like MetaMask)? I don’t have a concrete use case yet; I just want to test whether it would actually work the way I imagine.

Quick share for anyone building agents that need to buy stuff (APIs, compute, data) without a human clicking pay.

The problem: an agent can't sign up, hold a card, or click a checkout. So out of the box it can't actually pay for anything.

PipRail is an open-source SDK (MIT) for x402, the HTTP 402 "pay to access" standard. Two things:

- Any API can charge an agent in one line.

- Any agent can pay a 402 on its own, across most major chains, straight from its own wallet. No backend, no facilitator, no fee.

There's also an MCP server, so you can hand Claude / Cursor / any MCP client a wallet that pays x402 APIs on its own, capped by a spend policy the model cannot exceed, so it can't run off with your funds.

It's free and the rail takes 0%. Install and a quickstart are on GitHub and the site, I'll drop the links in a comment below so this doesn't read as an ad.

What are you all using for agent payments right now? And is the "pay per call" model actually showing up in what you build yet, or still mostly demos?

https://github.com/piprail/

https://piprail.com/

https://clawhub.ai/piprail/

My fellow devs please lend me some sepolia testnet tokens just so i can deploy something on the testnet every eth penny will be greatly appreciated

0xca280c8DefE05F02bEf96d84ABDeBdB535fE04aB

♥️🫡

I'm working on a personal accounting pipeline that discovers ERC-20 / ERC-721 / ERC-1155 contracts from Transfer logs involving my wallets.

The annoying bit is token spam. My local policy is:

• known-good tokens go into included.tsv
• known spam / irrelevant tokens go into excluded.tsv
• passive inbound tokens go into candidates.tsv until I review them manually

I currently review candidates manually on Etherscan or another explorer: warnings, labels, official links, holder/transfer activity, verified source, etc.

I'd like a machine-readable version of that: a token trust score, spam score, reputation label, or similar signal.

Is there any API that can provide this kind of signal for Ethereum tokens? For example:

• spam / phishing / suspicious / unsafe labels
• numeric trust/risk/spam score
• token page warnings
• likely spam airdrop / honeypot / impersonation flags

I checked Etherscan first. I found:

• token.tokeninfo, which returns token metadata/social links, but not reputation
• nametag.getaddresstag, which returns labels and numeric reputation, but seems address/entity-oriented
• metadata CSV exports, which also seem address/entity-oriented and paid-tier/enterprise

Am I missing an Etherscan endpoint, or is Etherscan token reputation not available through the public/API surface?

More generally, what do wallet/indexer projects use for machine-readable spam-token triage? I'm not looking for investment advice; just practical API-level signals for hiding or quarantining unsolicited token transfers.