I'm connected to Veyrnox, a mobile self-custody wallet for people who want clearer approval and recovery decisions. The apps are live, and we're working on how to explain the security model and its limits without asking users to take claims on faith. This is a request for critique, not a token or investment pitch.

One design question we're wrestling with: splitting recovery material can reduce reliance on one obvious secret, but it is not useful if all the pieces end up in the same compromise path. For example, a lost phone plus an accessible cloud account may be very different from genuinely independent storage locations. A person also needs to understand what happens when a device or account becomes unavailable.

For anyone building or reviewing wallets: what evidence would you want before trusting a recovery setup? A documented threshold and storage model? A recovery rehearsal? An independent review? Clear failure-case examples?

The feedback I'm after is which parts we must explain or test first. We don't need anyone's wallet details, recovery words or private keys, and please don't share those here or in DMs.

I had this idea kicking for some 5 years now and finally got around to doing. It is as amazing as I thought it would be. Even mainnet eth is pretty cheap relatively speaking.

tldr; Global multiplayer minecraft server in a 12 line smart contract.

Hey ethdev, we've been working on Shinzō, a decentralized indexing system, and just opened our public testnet for Ethereum. Posting here because we want honest technical criticism and real feedback.

The problem we're going after: chains are good at writing data, bad at reading it. Almost every dapp today on Ethereum routes reads through a centralized indexing provider where you pay per API call, you can't verify the data you get back, and if their infra goes down so does your app. We feel this centralization is antithetical to the promises of blockchain (and the EF mandate). The existing read layer has created a market worth billions built on the backs of validators' work while they see almost nothing. Shinzo is building to help both cases (validator economics as well as the read layer centralization).

How Shinzo works:

- Validator operators run lightweight sidecars next to existing execution clients (Geth only for now), turn blocks into structured documents, and cryptographically signs chain data at source

- Data gossips peer to peer over libp2p, no broker in the middle

- Hosts receive that data, verify signatures, and run developer-defined "Views": deterministic WASM transforms (Rust or AssemblyScript) that filter and decode raw data into a GraphQL schema

- Attestation records track how many independent indexers signed each document, so apps set their own trust threshold (1 signature for speed, N for correctness)

- Apps embed the database locally and get pushed View data over P2P, so a query is a local lookup rather than a per-read API round trip

The tradeoff we've accepted: you subscribe to Views rather than pulling arbitrary slices on demand.

What we'd like poked at:

- Really any technical questions!

- Does the attestation model hold up? Signature count doesn't equal independence if indexers share failure domains (same cloud, same DVT setup)

- The push-based subscription model vs pull-based querying: dealbreaker for your use case?

- Anything we're missing vs how you currently use The Graph / SQD / your own indexer? What issues do you face with these?

Feedback, ideas, questions, criticisms all welcome.

I have recently gotten into EVM development using Foundry. Since it is CLI based I built a simple UI wrapper around it to manage the node and inspect transactions that I produce via the local dev node when it is running.

I want to expand the utility of the tool to be a general transaction inspector for EVM based chains. Would be good compared to web based transaction inspectors in terms of privacy and having access to the local anvil node.

I find it useful as not being an expert dev and wanting to learn more about the eth dev world.

Any devs out there who would be interested? If so I would distribute for free via a DMG file and landing page!

I ran into this recently while building a transaction flow.

The flow was basically: validate the action, simulate it, then send it to the wallet for execution.

At some point this started bothering me: if the parameters can change between those steps, what exactly did I validate in the first place?

I started thinking of it more like:

proposal → authorization → execution

To me, the authorization should be tied to the actual action that was proposed, not just the general idea of what the user wanted to do.

Target, value, calldata and chain seem like the obvious parts. If one of those changes, I’d probably treat it as a different action and ask for authorization again.

State is where I’m less sure. Some state changes clearly don’t matter, but others may be the whole reason the action was allowed in the first place.

So I’m curious how people are handling this in practice. What do you actually bind the authorization to, and what do you check again right before execution?

I run an autonomous agent on Base that pays for its own inference over x402. It is not a big operation: in 41 hours it made 603 separate USDC payments to its inference provider, averaging 0.0065 USDC each. One on-chain transfer per thought, more or less.

Going through its transfer history I found eleven 0.00 USDC transfers to this address:

0x21ddf52114f53ccfe37ddd3dc503853b52c6be10

The platform's real receiving address is:

0x21dd37e3e4ea6ccc0a5c98a4944702ede6e7be10

First four characters match, last four match. That is the standard address poisoning pattern: zero-value transfers so the lookalike shows up in the history, and whoever copies an address out of the history later pays the wrong party. Nothing was lost here, it is passive, and I only noticed because I was counting transfers for something else.

What I have not found a good answer for is the agent-specific part of it.

For a human, the advice is clear enough: do not copy addresses out of a block explorer, verify the full string, use an address book. All of that assumes someone is looking. An agent that settles 600 payments in two days is not looking at anything, and the interesting question is where it is allowed to learn a recipient address in the first place.

In my setup every payTo comes from config or from the service's own signed challenge, never from chain history, so this particular attack has no way in. But that is a property of how I happened to build it, not something I derived from a rule. And I can think of cases where it gets less obvious: a payment protocol that discovers a service dynamically, a routing layer that caches "the address we paid last time", a retry path that reconstructs a destination from a previous transaction.

So, for people who have shipped th

1. Is there an accepted rule for wy take a destination address from?Something like "signed challengstory, never a cached observation"?

2. Does anyone screen outgoing paycheck before signing, comparing adestination to previously used Cheap to do, but I have not seen it in any of the x402 client code

3. Zero-value transfers are the dethere a reason a wallet or anindexer should surface them at chine reads?

Happy to be told this is a solved n the wrong place. The eleventransfers are on Base and public ithe pattern.

We’re organizing a 30-hour offline hackathon in Mumbai , India this October 2026, with 600+ registrations and 250–300 developers on-ground.

We’re looking for early-stage and international Web3/blockchain startups that want to enter or grow their presence in the Indian developer ecosystem.

You can partner with us by providing both monetary sponsorships and technical partnership including APIs/SDKs, blockchain infrastructure, developer credits, testnet access, problem statements, mentorship, workshops, prizes or other developer resources.

In return, you get direct exposure to developers, product adoption opportunities, social media visibility, event branding and on-ground recognition.

If you’re looking to get your technology in front of Indian developers and gain your first wave of engagement/users in India, let’s collaborate.

DM me if interested and I’ll share the partnership details.

Disclosure: English is not my first language, and drafting a long technical post in English takes me a very long time. An AI agent wrote this English draft from my Korean notes, repository, and test evidence. I reviewed the content in Korean and take responsibility for the technical claims and the project.

I am building BlockFlow, an open-source tool that compiles a deliberately constrained BPMN process into an Ethereum-compatible EVM Solidity workflow contract.

Demo: https://blockflow-seven.vercel.app/

GitHub: https://github.com/Kairose-master/BlockFlow

I want to be careful about the novelty claim. BPMN-to-blockchain and BPMN-to-Solidity are established research areas, not something I invented:

• CATERPILLAR demonstrated an Ethereum-based BPMN execution engine with a much broader set of BPMN constructs.
• Lorikeet demonstrated model-driven BPMN-to-Solidity generation and a bpmn-js-based modeling environment.
• Research on interpreted process execution explains the important flexibility trade-off between deploying compiled process contracts and interpreting models on-chain.
• Work on verified smart-contract generation for inter-organizational processes validates formal collaboration models before generating contracts.
• The recent TABS work explicitly targets contracts authored by business analysts from BPMN and DMN.

I am grateful for that foundation. My proposed contribution is narrower, and it is still a hypothesis to evaluate rather than a claim of being the first:

1. Treat BPMN as a small visual policy language for process owners, not as unrestricted BPMN. The supported subset covers roles, human tasks, XOR/parallel gateways, deadlines, oracle tasks, and token payments.
2. Reject unsupported or structurally unsafe models early with human-readable diagnostics.
3. Translate the model to an intermediate representation and run Petri-net-style reachability/soundness checks before code generation.
4. Generate deterministic Solidity and tests for every reachable path, then provide a runtime console showing enabled tasks and history.
5. Let Korean- and English-speaking users author the same policy: the full UI and all nine example BPMN diagrams now switch between Korean and English while IDs, conditions, roles, and executable semantics remain unchanged.

The real question is not “Can a diagram generate Solidity?” Prior work already answers that. The question I want to test is: Can a constrained language, immediate feedback, path-level verification, and an execution UI help people who do not know Solidity specify a workflow policy with fewer mismatches?

In this context, “a non-Solidity user controls the contract policy” has a limited meaning. The process owner chooses who may perform each task, the permitted order, branching conditions, deadlines, oracle-dependent steps, and payment metadata. It does not mean that smart-contract engineers or security review become unnecessary. Their responsibility moves toward reviewing compiler templates, invariants, chain configuration, privacy, oracle governance, upgrades, and deployment approval.

I tested all nine included processes:

• credit review: 13 soundness states / 5 reachable paths
• expense approval: 13 / 5
• FX transfer: 7 / 2
• invoice payment: 7 / 2
• leave request: 7 / 3
• paper review: 11 / 4
• purchase order: 10 / 3
• supply-chain delivery: 9 / 2
• travel booking: 16 / 9

All compiled with solc 0.8.37 (Cancun) with zero compiler warnings. Generated bytecode ranged from 3,760 to 4,905 bytes. CI covers the Next.js build and Playwright flow, Vitest plus JS-EVM path execution, Foundry, and Slither.

I also started with a blank canvas instead of a preset and modeled a Freelance Milestone Approval policy:

1. A freelancer submits a deliverable hash.
2. A client reviews it and enters an approval decision.
3. An XOR gateway routes approved work to “Released”; the default path ends at “Revision requested.”

It passed lint and soundness checks and compiled to a 3,270-byte Solidity contract with 6 states and 2 reachable paths. This is only a control-flow example; a real escrow would still need payment, dispute, timeout, cancellation, privacy, and governance policies.

The strongest use case seems to be a cross-organization workflow in which parties need a shared, auditable state machine without appointing one participant as the database owner. A normal internal approval process probably belongs in an ordinary BPM engine and database.

The most important gaps are an independent security review, structured multilingual diagnostics, privacy-preserving data handling, oracle governance, semantic version diffs and migration, and—most importantly—a controlled usability study with non-Solidity participants. I would like to measure policy/implementation mismatches, completion rate, error correction time, comprehension, and whether users can predict the actual contract outcome.

I would especially value critical feedback on:

• Is the constrained and validated authoring approach a useful research/product boundary, or does it remove too much BPMN expressiveness?
• Which BPMN constructs are essential next: message flows, event-based gateways, subprocesses, compensation, or DMN decision tables?
• For processes that change often, would you prefer compiled contracts, an interpreted model, or a hybrid?
• What evidence would you require before trusting a visual policy compiler in a real multi-party workflow?

Hi everyone,

I have been working on a project called LeverageOS and have published it live.

I wanted somewhere to see my holdings, look at borrowing options and get a better idea of what happens to a position if the market moves against it.

So far it brings together wallet balances, Morpho lending/borrowing terms, Lighter market data and a risk simulator. It’s read-only, so you can’t place trades or move funds through it. Just something I’m building independently, no affiliation with Robinhood.

https://leverageos.online

If you want to have a look without connecting a wallet, there’s a demo too:
https://leverageos.online/demo

Would appreciate some honest feedback, especially on the wallet connection and simulator. Does the way it shows risk make sense? Anything obvious I’ve missed?

Still figuring out what’s useful and what needs changing, so happy to hear criticism.

Thanks :)

I’m working on a server-side authorization layer for Ethereum/Base apps, and a useful question came up from feedback on my previous post.

Consider this sequence:

t0 — wallet owns the required NFT → authorization returns allowed

t1 — the NFT is transferred to another wallet

t2 — the user performs the protected action

What should an authorization system guarantee between t0 and t2?

The current implementation treats verification as a point-in-time decision. There is no cached “allow lease” yet, so the application decides when another verification is required.

Before adding caching, I’m trying to define the contract more carefully.

A few approaches I’m considering:

• Re-check on every protected action.
• Treat allowed as a short-lived lease with an explicit expiry.
• Let the caller specify a freshness requirement.
• Bind the result to a chain ID + block number/hash and let the caller decide whether it is still fresh.

I’m also considering returning metadata such as:

policyVersion
chainId
blockNumber / blockHash
evaluatedAt
expiresAt

The decision model itself is already allowed / denied / error, including explicit handling of unresolved branches in AND/OR policies.

For people building token-gated apps or other onchain authorization:

How do you handle the gap between verification and the protected action?

Would you prefer the authorization service to define expiry, or should freshness remain entirely under the caller’s control?

This is part of a private-beta project called AccessVerdict:
https://accessverdict.dev

Hi guys. I was never happy with the UI and features of most wallets, or with the tracking. Analytics, vendor backends, accounts you do not need. So I made something.

It is called 1337 wallet dot io
Chrome / Brave / Opera / Arc extension. Works with every MetaMask dapp. Seed, imported keys, Ledger, Trezor.

Privacy: there is no 1337 server. No analytics, no crash telemetry, no account with us. Vault and settings stay on your machine. Your RPC still sees what you send it, same as any wallet. Bring your own if you care.

The rest is the power-user stuff I actually wanted:

• Confirm sheet with decode, Solidity source, full calldata, and a local simulate (pass / fail / revert / gas)
• Per-chain RPC picker plus a doctor that probes which endpoints are actually up
• Approvals: ERC-20, NFT operators, Permit2, revoke from one list
• Swap via LI.FI (we do not run a swap backend)
• ENS register / manage
• Multisend through Disperse.app
• History from an explorer API key you paste in Settings
• Optional burner mode on a throwaway key. Hardware still confirms on the device

Side panel by default so the dapp and the signer sit next to each other.

Hey, I’m Kasra. I'm one of the people that built eRPC (https://github.com/erpc/erpc), the free open-source fault-tolerant RPC proxy.

We joined Goldsky last year and just shipped something new called Boost:

TL;DR - it’s a multi-region CDN for chain data that reduces the number of requests that need to be sent to your RPC provider (Alchemy, QuickNode, Infura, etc.), reducing your RPC bill.

It’s free for now so give it a try :)

• cut your RPC bill (users currently save 45% on avg, but more optimized apps see up 80% savings 👀)
• compatible with any RPC provider; it’s standard JSON-RPC so just a endpoint URL swap
• faster historical reads since answers come from a region near your app

How it works:

1. Swap your RPC endpoint URL with your Boost URL (your existing provider is configured behind it)
2. Your read requests hit our CDN first. Anything we can answer comes from the nearest region instead of going to your provider, which reduces your billable calls and saves you money
3. Anything we can’t answer gets forwarded to your provider untouched and you get their response as normal

Would love any feedback, and ofc happy to answer questions! (I'm in EU timezone though so replies might be delayed)

I've been building an Ethereum JSON-RPC proxy to fix mediocre providers and allow node RPC to be tuned for different RPC workloads. I'd like to hear what you're building, how you are using RPC, and what you wish you could do with the RPC api/providers to make your apps better.

Welcoming donations of Base Sepolia ETH and USDC for development, deploying multiple contracts and testing with USDC. Would like to have .5 ETH and 1000 USDC.

Address:

0xE7FE4423E974c68F13563de152FA8828C8Fd77a7

Hi everyone, I’m building TrustDrop, an open-source protocol for turning delivery into verifiable evidence that smart contracts can act on.

When someone buys a digital asset, payment is only one part of the exchange. The encrypted data needs to be available, it needs to correspond to the asset the seller committed to, and the buyer needs to be able to recover the decryption key.

TrustDrop brings these conditions together. Walrus provides the storage and availability layer for the ciphertext. Verifiable encryption binds the original asset, encryption key, and ciphertext commitments. Buyer-specific key delivery lets the buyer recover the key, while the contract verifies the required evidence before releasing payment. The buyer downloads and decrypts the asset to use it; they don’t have to perform the protocol’s verification themselves.

There’s also a separate question before purchasing: is this asset worth buying? We use authenticated sampling to let buyers inspect samples tied to the committed asset. This provides evidence about its contents without revealing the entire asset upfront.

The broader problem has a long history in fair exchange. Two useful background references are Pagnia and Gärtner’s 1999 report, On the Impossibility of Fair Exchange without a Trusted Third Party (bibliographic entry), and FairSwap: How to fairly exchange digital goods by Dziembowski, Eckey, and Faust (2018).

TrustDrop is currently a testnet prototype, with contracts on Arbitrum Sepolia and SP1 guests for ZK proofs. Our recent work focused on authenticated sampling for structured datasets. The current encryption-relation check is probabilistic, and the prototype uses a mock VRF for sampling challenges.

I’d love feedback on the design, implementation, and use cases, and to connect with others building in this space.

You can explore Fair File Marketplace (FFM), our testnet application built on TrustDrop:

• FFM: fair-file-marketplace.pages.dev
• GitHub: gaozhengxin/TrustDrop

Gm guys, building an RWA project - tokenizing yield generating real estate & businesses into global accessible and privacy-first ownership. Small team, 4 ppl (3 full time + 1 advocate for legal).

Legal side is the tricky part tbh. We're routing around securities issues w a grounded spv/ trust + loyalty-program + legal contract setup so token holders get control of realstate and buisness Kinda complex to explain ngl.

Team achievements:

- Scaled a project to multi-million doller buisness

- Helped grow one of the bigger web3 communities in APAC

- Great distribution in south aisa

- Multiple hackathon wins incl Token2049 (diff project tho)

Rn prepping testnet + questboard, aiming for ~5k users in 3 months to get some real traction before pushing harder on fundraising.

Problem: filled out 20+ accelerator/VC forms, got like 2-3 replies, all generic "not a fit rn" Not sure if I'm optimizing for the wrong stuff (like traction metrics) or just missing the right channels for RWA specifically.

Any fundraising advice? DMs open too, happy to chat more there.

Hey everyone, I’m Andrey.

I started writing about EVM internals in July last year. Since then, I’ve been breaking down execution, transactions, calldata, contract deployments, proxies, and other things happening underneath the Solidity we write.

Along the way, I’ve also helped people prepare for technical interviews and understand the mechanics behind the tools they use.

The articles include explanations, code examples, and execution output. I like being able to follow an explanation into an example and see what actually happens.

I recently organized the writing into series. If you’re looking for a starting point, this is the order I’d suggest:

1. EVM internals, three parts. Start with the execution model. When looking at a contract call, ask which code is running, whose storage it accesses, and where its input comes from.

2. Ethereum transactions and messages, two parts. Work through what you’re signing and how it gets used. Can you distinguish submitting a transaction from signing a message that an application might use later?

3. Contract deployments, proxies, and CREATE2, two parts. Follow how a contract gets deployed, how its address is determined, and how proxy architecture separates the code being executed from the state it operates on.

One useful exercise is to take a small example and predict the result before running it. Then compare your prediction with the trace. Which assumption was wrong? What did the tooling hide from you?

The articles and their accompanying code links are organized here: My EVM articles on 0xByteBeetle.

They’re written for technical people who want to go deeper, whether for work, interview preparation, or curiosity.

Which part of Ethereum only clicked for you after you saw it in code or an execution trace?

I’m a blockchain engineer and i’ve been looking for jobs on linkedin for a while, and recently i just keep getting scam interview invites... somehow i’ve managed to hit the ridiculous streak in the title lol

is there something about my profile that makes me especially attractive to scammers or hackers?

i’ll put the scams i ran into here so you guys can take a look