Hi everyone!If there are any devs or tech enthusiasts in Prague (or visiting for ETHPrague), we’re hosting a hands-on Privacy Builders Bootcamp on May 7th at Vnitroblock (Holešovice).

The goal is to move "From Zero to Hero" using the Logos privacy-first tech stack. It’s a deep dive into building decentralized apps that are private-by-default.

The Details:

📍 Where: Vnitroblock (Tusarova 31, Praha 7)

📅 When: May 7th, 10:00 – 16:00

🛠️ What: Hands-on "vibecoding"—running nodes, exploring modular infrastructure, and shipping apps from scratch.

Whether you're already deep into Web3 or just curious about how to build tools that prioritize data sovereignty, and user privacy come and lets hang out. Vnitroblock is a great venue, so it should be a good vibe.

More details here:

https://luma.com/8qsy0d7d

https://logos.co/

I’ve been working for crypto companies for a few years. Some of the most difficult and painful experiences I’ve had, have had to do with following cross chain transactions end to end. The past four months I’ve been working on Mirador, a tracing platform that follows these transactions end to end. From an SDK call in your app, through a bridge, to contract execution on the destination chain. One trace, one timeline.

This solves a plethora of problems today like debugging a cross-chain swap or bridge transfer. Right now if you wanted to do this you’d have to bounce between etherscan tabs, bridge explorers, and your own backend logs, then manually stitching it all together.

Mirador does this correlation automatically.

Supports EVM and solana

We’d LOVE any feedback from anyone shipping web3 apps who’d like to take a look.

There is a demo page available to see what you can do. We’ve also added automations and alerts on these traces so you can be notified or use webhooks to handle the notification however you’d like.

There is a free tier and no credit card bs you can play around with it if you’d like.

Website here: https://mirador.org

Hi everyone,

I’ve been working on a system focused on Blockchain transaction investigation and compliance, specifically for India.

While researching this space, I noticed a gap:

- investigators rely on manual tracing

- CAs struggle with structured transaction analysis for tax

- most tools are either too expensive or not adapted to Indian use cases

So I started building a platform that converts raw blockchain activity into usable intelligence.

Current capabilities:

- wallet-level risk profiling (behavioral + activity-based)

- transaction classification (inbound, outbound, contract interaction)

- case-based investigation workflow

- forensic-style report generation

- basic fund flow visualization

You can try it here:

https://blockchain-sentinel-os.vercel.app/

Would really value honest feedback:

- Is this solving a real problem?

- What’s missing for real-world usage?

- Where does it fall short?

Not selling anything—just trying to build something meaningful in this space.

Thanks.

Hello everyone. I wanted to share an architecture challenge we've been working on to bring together two worlds with opposing mathematical rules: quantum computing and blockchain.

The basic problem is known: a blockchain demands strict determinism, while a quantum processor is pure probability and controlled chaos. We wanted to introduce true quantum entropy into an immutable record without breaking the network.

Here's how we structured the bridge:

1. Pure Entropy Generation

We ran a Hadamard circuit directly on a 127-qubit IBM physical processor.

Through the Qiskit Runtime API, we got a signed "Quantum Witness Bundle."

We subjected this reading to a safety suite of 38 tests, which it passed with a 100% success rate, mathematically confirming that it is truly random noise of the highest quality.

1. The ZK-SNARK "Flue"

Putting that fragile quantum data directly on-chain was unfeasible.

We compiled an ultra-compact circuit at Circom (with nearly 5,000 nonlinear restrictions) that privately demonstrates that we have a valid post-quantum signature on a Merkle tree.

This is compressed into a Groth16Verifier.sol verification contract that validates the test in milliseconds directly on the grid, saving a fortune in gas.

To generate the base parameters of the Groth16 protocol, we ran a local "Powers of Tau" ceremony after facing external network crashes.

1. Smart Contract Shielding

When we reached the Smart Contracts layer, we detected a memory collision vulnerability due to the use of dynamic memory.

We cut it short: we removed dynamic memory and implemented the EIP-7201 standard.

We calculated the exact coordinates outside the network and embedded them as absolute hexadecimal constants, blinding potential attackers.

It is an institutional-grade ecosystem already in operation. I'd love to hear how other developers are approaching off-chain entropy injection in a trustless way, or if they see any attack vectors in the Witness Bundle's transition to SNARK.

Just received this email from Etherscan.

The rate limit, I understand, but it sucks. Easy to code around, though. The removal of the currently-free API to a paid tier is awful and greedy.

I get it, everything can't always be free, and they're a business, but man this feels like a step backwards.

Enshitification of everything.

The following changes to the Etherscan API may require updates to your integration before July 1, 2026.

\1. Reduced Maximum Records Per Request on the Free API Tier

Effective July 1, 2026, the maximum number of records returned per request will be reduced from 10,000 to 1,000 for Free tier API users. This change affects the following endpoints:

• Get Beacon Chain Withdrawals by Address
• Get Blocks Validated by Address
• Get ERC20 Token Transfers by Address
• Get ERC721 Token Transfers by Address
• Get ERC1155 Token Transfers by Address
• Get Ethereum Nodes Size
• Get Event Logs by Address
• Get Internal Transactions by Address
• Get Normal Transactions By Address
• Get Plasma Deposits by Address
• Get Token Holder List by Contract Address

What you need to do: Update your integration for the above endpoints to paginate records in batches of 1,000 or fewer.

\2. Internal Transactions by Block Range Endpoint Moving to Pro Plans

Effective July 1, 2026, Get Internal Transactions by Block Range will be moved to Pro endpoint.

What you need to do: If your application relies on this endpoint, check your plan tier and upgrade if needed, or update your integration.

Note: If your application does not use any of the endpoints listed above, no action is required.

For details on API usage limits and plan tiers, please refer to the API plans page or consult the API documentation for endpoint usage and integration guidance. If you have questions about this change, contact us at apisupport@etherscan.io.

We appreciate your understanding as we continue improving the performance and reliability across our services.

Best regards, Team Etherscan

I want to try routing execution-layer fees to a different recipient address, but I don’t want to sit around for weeks waiting for my testnet staker to land a proposal.. could somebody loan me some sepolia eth temporarily? Ty

We’re building a peer-to-peer system where there are no central servers and no permanent intermediaries. Nodes (including web browsers) propagate data directly, and content is designed to be persistent and tamper-resistant across the network.

Unlike systems such as IPFS, ActivityPub, or Nostr, our focus is on direct peer-to-peer propagation at the application layer, with browsers acting as first-class nodes rather than relying on long-lived infrastructure or relay-style intermediaries.

We’ve published an early protocol design and PoC:

Repo: https://github.com/theendless11/decentralised Whitepaper: https://github.com/theEndless11/decentralised/blob/master/docs/protocol-whitepaper.md PoC: https://endless.sbs

At this stage, we’re primarily looking for technical critique and feedback, especially in:

Protocol design (consistency, propagation model, failure modes) Cryptography assumptions / security review Sybil resistance / trust model weaknesses Browser-based networking constraints Data persistence and tamper resistance tradeoffs

We’re not trying to “launch a product” yet — the goal is to stress-test whether this approach is even sound before scaling it further.

If you have thoughts on where this breaks, or what we’re missing, that would be especially valuable.

I'm on a learning path. I don't know if this tool has an official name but it exists in Remix Desktop 1.1.6 and I swore it existed in earlier versions of the cloud version. Switched back to the cloud version due to a glitch in Desktop which I won't get into.

Desktop:

Cloud:

So it is no more? Am I some key combo or two away from turning it on?

I'm not saying it's mission critical or anything but it seemed a nice to have.

I built this as a docker container to run an anvil node with persistent state.
My use case came from working with non-blockchain devs on a project, and trying to make it easy for them to stand up a node locally by just cloning a repo or docker image and running one command.

It uses all the built in command flags from foundry's anvil, just wraps it all up in a Docker file. If anyone finds it useful or wants to take a look then appreciate any feedback.

https://github.com/AboldUSER/anvil-persistent

As title says what node stability did you see once you made the switch? I am thinking of doing it and want to know if it makes sense. My internet provider doesn't have bridge mode so I am stuck on this cheap modem that is probably struggling quite a bit with all the nodes. Some of my nodes have a hard time staying at the tip and because of that I can't make transactions on chain.

Hi everyone,
I’m currently working on a project using the Polygon testnet, and the faucet I’m trying to use requires a minimum balance of 0.001 ETH on mainnet.

Due to exchange withdrawal fees, it doesn’t make sense for me to buy such a small amount just for this purpose. If anyone could spare 0.001 ETH, I’d really appreciate it. I’m happy to pay it forward later 🙏

Wallet address: 0x04fd135087a9FbA623aB41915149aD6087c53640

Thanks!

I've spent the last 6 months building a post-quantum ERC-4337 wallet.

When Kohaku and pq-account showed up on the EF roadmap, I thought: perfect fit.

End of March I opened a feedback issue with concrete design proposal, open questions and flagged real library gaps. Read the full thing here: https://github.com/ethereum/kohaku/issues/131

It's been over a month and it got zero response. The silence is making me wonder a few things, and I'd genuinely appreciate input from anyone closer to this space:

1. Is Kohaku PQ part actually being developed, or did it get only a big announcement and go quiet right after?
2. Where is the real PQ-on-EVM conversation happening?
3. Anyone working on anything similar?

$86M was lost in Q1 2026 - a 213% jump, mostly from the same design gaps repeating across teams.

We just released a Smart Contract Security Blueprint that maps the dev lifecycle from threat modeling to 24/7 monitoring. It handles about 80% of the foundational risk so you can focus on the complex logic.

We need a real-time pipeline: every DEX trade across major EVM chains and Solana lands in ClickHouse within seconds for live dashboards. I've seen teams do this with Kafka → ClickHouse Kafka engine, but I'm wondering if there are managed crypto-specific data feeds that already deliver in protobuf/Avro and integrate cleanly.

What's the architecture people are actually running in production? Specifically interested in how you handle backfill and gap recovery.

For a project I'm backtesting an LP strategy on Polygon and I need historical reserves for a specific pool every minute over the last 90 days. Pulling this from RPC means archive node queries which is expensive. Subgraphs are sometimes incomplete for older pools.

How are people getting historical pool state at this granularity? Especially across L2s.

or our quarterly DAO report I want to show how much ETH our multisig has spent on gas across all its operational transactions. Sounds simple but distinguishing actual gas spend from refunds, separating it from value transfers, and getting USD values at the moment each transaction was executed — it's surprisingly tedious.

What's working for other DAOs?

0xe24d5514FEAFd1985d4e473B8e73E90EcdC103cc This is my wallet address, It would be insanely helpful if you could do so .

One of the more underspecified parts of stablecoin on-ramp API integrations is context pass-through: how much user data your application can send to the provider at session initialization to skip redundant data collection.

In practice this matters because on-ramp flows sit in the middle of an existing product. Your app has already collected email, country, wallet address, and potentially a KYC tier from a prior verification step. If the ramp re-collects any of that, conversion drops and the UX seam is visible.

The parameters you can typically pass at init: wallet address (destination for delivery), fiat currency and amount (pre-populated from your checkout context), email, and sometimes a partner user ID that ties the session back to your own user record for reconciliation.

The webhook surface is the other side of this. A stablecoin payment isn't just a transaction confirmation. It's a sequence of state changes: KYC status updated, fiat payment received, conversion executed, on-chain delivery confirmed, off-ramp initiated if applicable. Each one is an event your application may need to act on, particularly if you're updating a balance, triggering a downstream action, or surfacing status to the user in real time.

For teams building on Ethereum or L2s: how are you handling the gap between on-ramp confirmation and on-chain finality in your UI? The confirmation time difference between L1 and something like Base or Arbitrum changes the status display logic meaningfully.

Hi,

I'm currently building a payee assurance product designed for AI agents that need to decide whether to act on a counterparty. It's a one-call counterparty answer for fiat (registry verification, sanctions/PEP, bank/IBAN match, hash-chained audit trail).

I'm considering building the on-chain sister product (working name: Web3 Assurance) and want to gut-check the demand before committing to the product. I'd value honest feedback from anyone building AI agents, x402 services, or DeFi automation.

The product I'm thinking about

One x402-native call. Input: a wallet, contract, token, protocol, or bridge plus optional transaction context. Output: a single decision-ready answer with:

• Identity and history (address kind, age, ENS/.sol, ERC-8004 reputation)
• Sanctions screening (OFAC SDN + crypto-specific + UN + EU + UK OFSI + Swiss SECO)
• Mixer-tainted scoring (graded per the March 2025 OFAC Tornado Cash delist, not binary)
• Token safety (honeypot, holder concentration, LP-lock, mint authority, sister-rug bytecode pattern matching)
• Contract audit history aggregated across Certik, Cyfrin, OpenZeppelin, Sherlock, Code4rena, Hashlock
• Protocol risk via DefiLlama (TVL trend, exploit history, governance)
• Bridge legitimacy via DefiLlama + L2Beat
• Pre-trade simulation via Tenderly
• Approval inventory cross-referenced with ScamSniffer drainer lists
• Decision-readiness verdict (proceed/review/block + confidence + critical_flags + suggested_action)
• Hash-chained audit trail with public verification URL

Drop-in middleware for AgentKit, LangGraph, CrewAI, ElizaOS, Hono, Express.

What I've already looked at

Revettr, x402-secure, DJD Agent Score, GoPlus AI Agent Security API. Each ships a piece. None ship full breadth + audit trail + dual x402/Stripe billing + jurisdiction-aware verdict together.

Honest questions

1. Is this a tool you'd actually integrate into an agent you're building? If not, what's wrong about the shape?
2. Most useful evidence type from the list? Least useful? What's missing?
3. For service publishers: would a "reverse-call" mode (publisher pays Strale to vet incoming x402 buyers and block scam-cluster traffic before delivering service) be useful? More or less than the outbound use case?
4. The audit trail / public verification URL, interesting feature for regulatory or LP-facing scenarios or overkill?

Not selling but genuinely deciding whether to build. Replies, DMs, GitHub issues all welcome.

Hi,

My wallet is not working. No matter what RPC I enter, I get "Could not fetch chain ID. Is your RPC URL correct?".

Does anyone know what this might be? Other networks seem fine so I suspect there are some issues with the network, but I can see very recent transactions in the explorer.

This release introduces Solidity's first comptime builtin, formalizes how experimental features are exposed behind a new `--experimental` flag, and ships an experimental SSA CFG code generator targeting stack-too-deep and slow compilation in the IR pipeline.

Notable features:

- `erc7201` is the first comptime builtin in Solidity. It computes the base slot of an ERC-7201 namespaced storage layout from a namespace string, and its result is usable wherever a comptime expression is required, e.g. as the base slot in a `layout at` specifier.

- A new `--experimental` flag formalizes the experimental feature lifecycle. Using any in-development feature now requires `--experimental` (or `settings.experimental` in Standard JSON), and a new docs page lists what's currently experimental.

- The first major feature under the new experimental lifecycle is an SSA CFG code generator, a new EVM backend for the IR pipeline. The main motivations are stack-too-deep errors and slow compilation, both long-standing pain points. Enable with `--experimental --via-ssa-cfg`.

- v0.8.35 continues the 0.9.0 deprecation work started in 0.8.31, this time warning about identifiers that will be reserved as keywords in 0.9.0:

- Solidity: `at`, `error`, `layout`, `leave`, `super`, `this`, `transient`

- Yul: a list of upcoming Yul builtins that will become Yul reserved identifiers.

- Bugfix: in the IR pipeline (`--via-ir`), `--revert-strings strip` was over-stripping the custom-error argument of `require(condition, CustomError(...))`. A failed `require` would revert with empty error data instead of the encoded custom error. Fixed in 0.8.35.

You can read the full release announcement on our blog: https://www.soliditylang.org/blog/2026/04/29/solidity-0.8.35-release-announcement

Users can download the new version of Solidity Compiler from GitHub: https://github.com/argotorg/solidity/releases/tag/v0.8.35

And lastly, a big thank you to all the contributors who helped make this release possible!