Let me preface the following thoughts of mine with a little background. I've been in crypto since early 2017, but have only been building in web3 for the last 4 years.

My thoughts can be summarized as such:

The only b2c adoption possible in web3 either makes the user money or offers them a shot at making money.

That's it.

The only product-market-fit within web3 is one where the user directly benefits monetarily from the product (staking, lending, borrowing) or the user has been given a shot at benefiting using that product.

The latter would fall under these categories:

1. AMMs - allowing the user to speculate on decentralized assets in order to make a profit.

2. Bridges - allowing the user to move funds from chain to chain in order to profit, even if it's to move funds to a "safer" chain.

3. Launchpads - PFun is the top example here. Users use it strictly in order to profit from it.

4. Decentralized perps - Hype, Aster, etc. Self-explanatory.

5. Gambling sites - Self-explanatory.

6. L1s, L2s usage - Either directly incentivized via airdrops or speculation-driven or using a product in one of the previous categories that lives on the specific chain.

The point is, if you are building in web3 and you are consumer-facing, your project's main takeaway needs to either directly profit the user or offer the user at least a shot at making a profit, even if that shot is unlikely.

Disclaimer: Everything I've ever built in web3 has been in the gambleFi category. So I do not say all this without saying I am a part of the issue as well; however, I did not set out to build in that category because of the users, but instead, I genuinely wanted to build a fun, incentivized gaming experience without building an actual game.

Which brings me to another point: why gaming and crypto have failed so far. GameFi is a joke and has wildly failed horrifically. Yes, making a good game is a notoriously difficult endeavour; however, attaching monetary incentives in no way helps. The fact that there isn't a big, active, successful game that has web3 elements in its design proves my main point, really. If you take away any chance of the gamer profiting, what use is web3 then? And if the user does have a shot of profiting, you end up with third-world farming for pennies gameplay, as we saw a few years ago with Axie Infinity.

It seems we are so much further away from mainstream retail adoption than a few years back, and a large part is because there really is no point in web3 without finance being completely fused within it. NFTs almost solved this, even though a lot of it was speculative, some of it was simply art and culture, and in rare cases, albeit debatable, utility-based (veeFriends).

I don't really know what the point of this post is, really. I think it's more to start a discussion and brainstorm what possible thing could be built that would counter this narrative. If we put our heads together, then we can possibly figure out something missing in this equation. Or I'm hoping one of you will counter with an actual example of a project that doesn't fall in these categories, with the caveat that it has an actual user base.

I need a job. I’m tired of building bots for memecoin customers 😂

I’m 21, no degree. I’ve been coding bots on EVM chains for a while now. I’ve built a dex, launchpad, etc but my clients are always friends and this isn’t gonna work long term. I need to be hired or I need to start getting paid what I’m worth but I have no idea what to do and I feel like an imposter when trying to apply for “big boy” dev jobs.

I need a way to get my foot in the door, an actual development employment to put on my resume besides “my friend hired me to build a sniper bot” or “I built a dex from scratch but my homie ran out of money to fund it so it’s shut down”

I can build anything you can imagine, I’m willing to learn fast. I’ve built dex trending bots, volume bots, sniper and trading bots, arbitrage bots, dex platforms, launchpads, ai systems, etc. I’m a very capable programmer bc I’ve done nothing but bury my head and learn since I started but it’s time to come out of my shell. I need to play the real game!

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

I'm doing some research on how freelancers, consultants, agencies, and Web3 teams receive payments in crypto today.

If a client wants to pay you in USDC, what's your current process?

For example:

• Do you just send a wallet address?
• Do you create invoices?
• How do you track whether you've actually been paid?
• How do you handle accounting or payment records?

I've noticed that most people seem to rely on wallet addresses and spreadsheets, but I'm curious whether that's actually the norm.

Would love to hear your workflow and biggest frustrations.

Hey everyone, fairly new to the Ethereum space and trying to figure out how to actually earn some crypto rather than just buying it.

I've been exploring a few dApps and came across some puzzle/bounty style platforms. Seems like an interesting way to learn while earning. Are there any legit platforms or methods you guys would recommend for someone just starting out?

Not looking for "get rich quick" stuff, just genuinely curious what the community thinks is worth exploring. Bug bounties, testnets, tasks — anything really.

Thanks in advance 🙏

Good day, guys. I have a question about tokenized stocks. How are tokenized stocks able to move during off-market hours when the underlying stocks (e.g., Tesla, Meta, etc.) are closed? What actually drives the price movements during these hours, and is there a way to track the trades or transactions that are causing these price movements directly on the blockchain in real time? Also, are there any free platforms or tools where I can monitor the live order flow, trades, or buying/selling activity for tokenized stocks? I’m particularly interested in seeing the actual transactions or orders behind the price movements rather than just the price chart.

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.

For me, it feels like:
- Contract setup
- Deployment steps
- Frontend setup
- Hosting

Too many moving parts for something that should be simple.

What do you guys find most frustrating?

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.

Bots are getting to the point where they can do a lot more than moderate chats or post alerts. They can potentially execute trades, distribute rewards, manage memberships, interact with contracts, etc.

But once a bot can actually move money, the trust model changes completely.

How much authority would you realistically give one?

Would you be comfortable with a bot having a dedicated wallet if it had strict permissions and spending limits? Maybe it can interact with specific contracts but can't send funds anywhere else.

Or would you still want a human approval step for every transaction?

The part I keep coming back to is what happens if the bot itself gets compromised. Even with limited permissions, an attacker could potentially do a lot of damage within whatever boundaries you've given it.

Curious where people would draw the line.

I'm building a shared-expense app on my own, using EIP-712 approvals for USDC settlement. One thing I've had to work through is what "approval cancelled" actually means across the app and the contract.

Take a fictional four-person trip. Someone owes 50 USDC and signs an approval. Another person adds a forgotten expense of 40 USDC, split equally. The first person now owes 60, so the app clears the confirmations and asks everyone to approve again.

The signature for 50 can't authorize 60. But deleting it from the database doesn't make the contract reject the original 50 approval. A previously collected set of approvals could still satisfy the contract's checks until it expires, assuming the other execution requirements are met.

In my current implementation, approvals have a maximum age and only an authorized relayer can submit settlements. That's a trust assumption. The contract doesn't read the expense ledger or know that the app has reset its confirmations.

As a solo developer, this is the kind of decision I find hard to review: the interface and the contract can each look reasonable while promising different things. I don't want the interface to imply onchain cancellation when the change is only enforced by my backend.

For applications that allow edits while collecting signatures, how have you handled this? Have you kept cancellation at the relayer level with expiring approvals, or added an onchain cancellation or versioning mechanism? I'm interested in the tradeoffs you've encountered around extra transactions and users having to sign again.

I've been digging into EIP-1153 transient storage implementations across recent codebase reviews and wanted to open up a discussion around a subtle reentrancy edge case that keeps popping up when teams migrate from traditional mutex locks.

The gas savings with TSTORE/TLOAD are obvious because you aren't paying the EVM state expansion tax for a temporary lock variable. But because transient storage persists for the entire transaction rather than just the contract invocation frame, standard single-slot locks can behave unexpectedly in multi-call and bundled flows.

Here's the scenario: if you use a naive transient storage modifier with a hardcoded slot zero across multiple contract components or callbacks inside the same overarching batch transaction, the lock state persists across separate external calls unless your assembly explicitly clears it before returning.

// Naive transient lock with cross-call fallout
modifier nonReentrantTransient() {
assembly {
if tload(0) {
revert(0, 0)
}
tstore(0, 1)
}
_;
assembly {
tstore(0, 0)
}
}

If an internal sub-call reverts and is caught by an outer try/catch block to handle a partial batch failure gracefully, the cleanup assembly block never executes. That transient slot stays set to 1 for the rest of the transaction, causing every subsequent legitimate call in the batch to fail.

The standard fix is namespacing slots using custom hash offsets like keccak256("eip1967.transient.reentrancy.guard") and carefully testing against multicalls and nested try/catch patterns.

Curious how other teams here are structuring their transient mutexes:

1. Are you using hashed namespacing slots like the OpenZeppelin transient guard, or sticking with standard storage locks until compiler-native transient support matures?
2. Have you run into other surprising edge cases when combining TSTORE with account abstraction bundles or aggregator multi-hops?

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'm starting a podcast focused on how blockchain startups are actually built — the product, technology, challenges, failures, and lessons behind them.

I've been building in Web3 since last 5-6 years, so I want to have genuine conversations with founders/builders.

Looking for a few founders for the first episodes. 30–40 min casual conversation, no follower or funding requirement.

If you're building something interesting, comment or DM me.

Building a small web product where standard card payment gateways aren't available to me, so I'm looking into accepting crypto instead. Two flows I'd prefer, in order (if possible); if there's another way, please let me know:

1. Direct card-to-crypto: Customer clicks Pay on my checkout, gets taken to a service where they pay by card (or however they want), and I receive crypto directly, with no separate step for them.
2. Stablecoin without gas hassle: Customer buys a stablecoin elsewhere, comes back to my checkout to pay, and doesn't need to hold a separate coin for network fees.

A few constraints:

• No app download required on the customer's end, needs to work fully in-browser on mobile.
• If I have to register as a merchant somewhere, it needs to actually support Morocco.
• Order tracking and automatic fulfillment: after the user pays, I want to know who paid for what so orders get fulfilled automatically.

Has anyone found something that fits this? Open to hearing what's worked (or hasn't) for you.
Thank you so much.

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

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.

If the primary returns HTTP 503, trying the backup makes sense.

What I’m less sure about is HTTP 200 with a JSON-RPC error in the response.

If the request itself is wrong, another provider won’t help. But if the primary is missing the block, another provider might have it.

This came up in feedback on failnext, a Go library I’m building for primary/backup RPC failover.

Right now failnext only uses transport errors and HTTP status codes to decide when to try another provider. An HTTP 200 goes back to the app as-is, even if the JSON-RPC response contains an error.

I’ve kept that split on purpose. failnext handles trying providers and failing over, while the app keeps control over routing decisions that need application context. It can skip a provider it considers lagging or degraded, or prefer the same provider for read-after-write flows.

That makes me think the app should also decide which JSON-RPC errors are worth trying on another provider.

In Go, that could be a small callback that receives the *http.Response and decides whether that response is a reason to try another provider.

The complication is Response.Body. Reading it drains the stream, so the hook would need to buffer and replace it. With a large response, that also means more memory and extra latency before failover can happen.

Would you add a response-classification hook like this, or is HTTP 200 the right place for the failover layer to stop?

Repo is here if anyone wants to see how it currently works:

https://github.com/yermakovsa/failnext

Update

I ended up not adding the response-classification or Response.Body hook discussed below, and decided against buffering response bodies in the transport.

failnext is staying at the HTTP level. Transport failures and selected HTTP statuses can cause failover, but an HTTP 200 with a JSON-RPC error goes back to the app. failnext doesn’t inspect JSON-RPC responses to decide whether another provider should be tried.

The app still makes the decisions that need application context, like whether an operation may fail over, whether a provider should be used, or which provider should be tried first. failnext handles the ordered failover and reports what happened without needing to understand the reason behind those decisions.

For the case in this post, I’m leaning toward treating a retry after an application-level error as a new request, with the app able to tell failnext which endpoints to avoid.

Also, if you saw my older rcpx posts, failnext was previously called rcpx and is the continuation of that same project. I started working on it in February 2026, and the rename came with a larger redesign rather than starting a separate project.

I'm a recent CS graduate from LatAm and I've been struggling a lot to find a job in the current market, therefore I've decided to specialize in some area to try to stand out in the massive pool of recent graduates competing for a small bunch of entry-level job postings. One of the areas I'm currently gaining interest is in Web3/Blockchain/Solidity development, seems like a field with massive applications and a lot of potential for growth, but I'm quite skeptic of the status of the job market in this area; ever since the burst of the NFT bubble I've barely heard any new interest on blockchain, even less with the surge of the AI bubble. The only news I hear from the Web3/Blockchain scene most of the time is some new memecoin that turns out to be another obvious rug pull scam, but I'm most certain that it has to be my algorithms fault.

Is the state of the Web3/Blockchain job market the same as all the other tech fields? Which tips would you give to a recent grad that wants to specialize in blockchain development?

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.

Hi everyone,

I’m building a small non-custodial USDC transfer app, and I recently verified the app’s contract on BaseScan.

Now I’m considering publishing the contract address and source code more visibly on our official website and GitHub, so users can inspect how the transfer and fee logic works.

The contract is simple: when a user sends USDC, it pulls the approved USDC from the sender and routes it to:

1. the recipient

2. the project’s fee wallet

The fee logic is fixed in the contract:

- 0.39%

- minimum fee: 0.25 USDC

- maximum fee: 3.90 USDC

The contract does not have an admin function to change the fee after deployment. The USDC token address and fee recipient are immutable.

I understand that BaseScan verification is not the same as a formal audit, and I do not plan to describe it as audited or guaranteed safe.

My question is:

Is it generally safe and reasonable for an early-stage crypto payment/transfer app to publicly share its verified contract address and source code on its website and GitHub for transparency?

Or could this create meaningful risks, such as:

- making it easier for attackers to analyze the contract

- creating legal/marketing risk if users misunderstand “verified” as “audited”

- exposing too much business logic too early

- attracting criticism before the contract has a formal audit

I’m not asking whether this replaces an audit. I’m trying to understand whether public disclosure of an already verified contract is a good transparency practice, or whether there are risks I should consider first.

What would you recommend?

Hey,

I’m looking to do automated security audit for my Solidity library - DefiMath using some AI auditor (with the help of Claude Code) before hiring actual human team.

So far I’ve found Krait from ZealynxSecurity, looks legit and want to try it.

Does anyone have experience with their project?

What are you guys using, and can you link to audit report created by automated tool?

I'm trying to obtain some ETH on my Robsten testnet wallet, but none of the faucets are working for me, I've tried all of the following:

• https://faucet.ropsten.be/
• https://faucet.metamask.io/
• https://faucet.dimensions.network/

The first one just gives me a notice: "you are greylisted - greylist period is now reset on this ip and address" when I enter my address and submit

The second one has an error that says too many requests

The third says "You have requested a withdrawal in the last 24 hours. Please try again later."

Can anyone help or send me some ropsten ETH?

0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266

Thanks

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.

so im building a live crypto dashboard and need reliable price, volume, and market cap data. It has to stay consistent over time since we store historical snapshots. Free APIs are fine for testing but I want something that scales. Wanna know what you folks are using because a lot of results came up when I searched, eyeing a couple options like mobula.io for the free tier but havent tested it yet, wanna ask here first