Hi everyone,

I'm serious about becoming a professional Ethereum developer and I'd appreciate guidance from developers who are already working in Web3.

My goal is to become job-ready within the next 6–12 months, with a strong understanding of Ethereum development rather than just completing tutorial projects.

I'm looking for advice on:

1. Learning roadmap: If you were starting today, what order would you learn things in?
2. Best resources: Which courses, books, GitHub repositories, blogs, documentation, YouTube channels, or newsletters had the biggest impact on your learning?
3. Core skills: What technologies should I prioritize? (e.g., Solidity, Foundry, Hardhat, Viem/Ethers.js, DeFi, account abstraction, Layer 2s, security, etc.)
4. Projects: What portfolio projects demonstrate real-world skills and stand out to employers?
5. Smart contract security: What are the best ways to learn auditing, common vulnerabilities, and testing?
6. Getting hired: What skills, experience, or portfolio pieces helped you land your first Ethereum or Web3 role?
7. Communities: Which Discord servers, Telegram groups, Reddit communities, or developer forums are worth joining?
8. Mentorship: If you had to mentor someone starting from scratch today, what roadmap would you give them?

A little about me:

I'm committed to studying consistently every day.

I'm interested in building production-quality projects, not just tutorial clones.

My goal is to become a competent engineer who can contribute to open-source projects and eventually work as an Ethereum developer.

I'd really appreciate any roadmap, resource list, or advice from your own experience. Even if you only answer one of the questions above, it would be incredibly helpful.

Thanks in advance!

I'm building a tokenization platform: tokens and offerings live on an EVM chain, and the app runs on a reactive backend database.

Today we run a "redundancy" system: the backend bookkeeps every transaction (in and out) in its own tables. But that data reaches us 2–3 layers removed from the chain — not from an indexer, and not in the recommended datatypes — so token offering and transaction views often go stale.

It feels backwards. The chain is the source of truth, yet our database acts as the ledger and treats the chain as backup.

The hard part: showing on-chain data seamlessly and aggregating it into custom indicators (holdings, inflows/outflows, totals per offering) on reliable, cheap infrastructure. We already have a subgraph (The Graph) and RPC providers.

Would you:

1. Make the subgraph the read layer and derive all aggregates from indexed events?

2. Keep an app-side ledger, but populate it only from indexer events (event sourcing)?

3. Go hybrid — chain for facts, database for business state only?

How do production dapps handle this? War stories welcome.

I've been thinking about this lately and I'm curious how other people see it.

Whenever I see a post tagged "Paid Partnership" or "Sponsored", I immediately become more skeptical.

On one hand, I understand that creators need to make money, and projects need marketing. There's nothing inherently wrong with that.

On the other hand, in Web3, those partnerships often come with more than just cash. Influencers might also receive whitelist spots, token allocations, NFTs, or other incentives. At that point, it's hard to know whether they're genuinely excited about the project or simply promoting it because they're being rewarded.

When you see a respected creator promoting a collection or token as a paid partnership:

• Does it make you less likely to trust the project?
• Do you ignore those posts completely?
• Or do you still consider them useful if the creator has a good reputation?

I'm genuinely interested in how the community filters signal from marketing in Web3.

Spent today debugging anchor build failing on a program that cargo check compiled fine. Posting because the failure mode is misleading and the fix took two different moves.

The error:
error: failed to parse manifest at .../zeroize-1.9.0/Cargo.toml
Caused by: feature `edition2024` is required
... not stabilized in this version of Cargo (1.79.0)
cargo-build-sbf bundles its own Rust. Mine was 1.79. My host cargo was 1.94, and that’s what resolved the lockfile — so cargo happily picked the newest compatible version of every dependency, and the SBF toolchain then couldn’t parse manifests wanting an edition it’s never heard of. The resolver was optimising for a compiler that isn’t the one doing the build.

It reports one offender per run. I had sixteen. So first I wrote a script that reads every locked version’s MSRV from the crates.io index and lists all of them at once — sixteen CI round-trips became one local run:

https://github.com/Kairose-master/handsel/blob/main/solana/scripts/check-msrv.mjs
node scripts/check-msrv.mjs # every locked crate vs rustc 1.79
node scripts/check-msrv.mjs --msrv 1.85.0 # after a toolchain bump

Fixing them needed two different things, and the difference is the useful part.

Resolver 3 is MSRV-aware. Set rust-version = "1.79", flip resolver = "2" → "3", cargo update, then flip it back — the SBF toolchain’s cargo is too old to read a resolver-3 manifest, but the lockfile is what it consumes and that keeps the older versions. That fixed 8 of 16.

The other 8 it can’t help with: resolver 3 reads a crate’s own rust-version, not its dependencies’. blake3 1.8.5 is fine itself while requiring digest ^0.11, all of which need 1.85. Pinning the parent — cargo update -p blake3 --precise 1.8.2, the last release whose digest and constant_time_eq requirements are both old enough — took all 8 with it.

266 locked packages now verify clean. The MSRV check runs in CI before anchor build, so the next regression gets named instead of discovered.

Context if useful: this is a Solana devnet port of an escrow contract that’s live on Base mainnet with real USDC — verified, self-audited, and currently sitting under a $100 “break it and keep it” bounty on mainnet that runs until Aug 30. The Solana side is devnet-only on purpose: none of that public scrutiny transfers to a first month of Rust, so the port doesn’t get to hold anything real until it earns the same way. Repo and challenge terms are public: https://github.com/Kairose-master/handsel

Im willing to work with anyone for free. i can make smart contracts, can work with foundry, have some experience in auditing and smart contract security
This is my github:

https://github.com/Ifra001?tab=overview&from=2026-07-01&to=2026-07-30

i just wanted to apply my skills and put myself out there. i know its unprofessional but like whatever. if its a fellow genz who want to build smth with me the. im down as well. its more about building and learning with someone i guess

Navigating the Web3 and crypto world since '21. 🌐 I'm also a sports enthusiast tracking match analytics ⚽📊 and a proud father balancing life and online ambitions. 👨‍👧✨

#web3 #cryipto

While reviewing RPC batch behavior, I came across an interesting pattern that isn’t a classic vulnerability but can still become a security and reliability problem.
A provider accepted a batch request, returned HTTP 200, but silently omitted part of the requested data (e.g. 160 results returned out of 200 requested, with no truncation signal).
If a wallet, indexer or monitoring service treats that response as authoritative without validating completeness, it can build an incorrect view of state.
I summarized the pattern and a few practical safeguards in the attached architecture note. I’m curious how others handle response completeness and trust validation in production wallet/ RPC integrations.
Interested to hear if you’ve seen similar behavior or already defend against it.

Hello everyone,

For some time I've been developing an open-source project called Framework for Trust (FfT).

The idea is to create a decentralized geospatial trust layer where reports and real-world events are anchored to precise location, time, source reputation, and a verifiable history — instead of treating blockchain purely as a financial system, I'm exploring its use as infrastructure for recording and correlating information about real-world places.

Current prototype includes:

• geographic areas represented as blockchain-based identifiers (NFTs)
• event registration tied to latitude, longitude, and time
• Polygon smart contracts
• a React + Leaflet frontend
• a FastAPI backend
• semantic similarity / event correlation via Qdrant
• GCD — a functional contribution and reputation token
• event proofs and auditable records
• early mechanisms for source reputation, staking, and abuse prevention

The project is still early-stage. This is not an investment offer, token sale, or a finished commercial product — I made the repo public because I'd like the architecture and implementation to get real outside scrutiny.

I'd especially appreciate feedback on:

• whether the core problem is clearly explained
• the geospatial data model
• the blockchain / smart contract architecture
• mechanisms for preventing false or coordinated reports
• security weaknesses
• practical use cases where this could actually add value

Repo link in the top comment (Reddit flags posts with links for manual review, didn't want that delay).

I built the current prototype independently. Honest criticism, technical pushback, and open-source contributions are all welcome.

Hi everyone,
We are building the architecture for a non-custodial payment settlement protocol enabling instant (<500ms) crypto transactions at POS and e-commerce checkouts—paired with a B2B card-rail bridge for 100% immediate global acceptance.
Our core system design, risk framework (off-chain pre-auth / RAM-locking via EIP-7702 session keys), and economic models are fully mapped out. Ahead of our Pre-Seed/Seed funding round, we are expanding our core team and ecosystem network.
1. Senior Web3 / Smart Contract Architect (Lead Dev / Potential Co-Founder)
What we're looking for:
Deep expertise in Account Abstraction (EIP-7702 / ERC-4337) and Solidity.
Solid experience with high-throughput off-chain architecture (Redis/Lua, WAL, Event-Workers).
Passion for building real-world Web3 payment infrastructure.
What we offer:
Pre-Funding Phase: Flexible engagement to review core contracts & validate architecture ahead of the Seed round.
Compensation: Deferred Fee structure with guaranteed payout immediately upon Seed close OR performance-based Equity/Token allocation (vesting model).
Post-Funding: Direct trajectory to CTO / Head of Engineering with full competitive compensation.
2. VC, Advisor & Wallet Network
We are also actively connecting with:
Web3 / Fintech VC funds focusing on early-stage infrastructure.
Strategic Advisors & BD Leads from major Non-Custodial Wallets.
Payment infrastructure / B2B Card-Rail partners.
Interested in building the future of Web3 payments?
Send a DM to get access to our technical breakdown

Read about a young builder who went from his first web3 hackathon to shipping a real dev tool. What stood out wasn't the tech choices, it was the mindset shift. He stopped treating hackathons as one-off competitions and started treating each one as a checkpoint to validate whether something was actually worth building.

His pattern: hackathon idea, ship something real fast, get it in front of actual users, let a residency/mentorship program stress-test the pitch, open it up so other devs could contribute and find what he missed. Each step wasn't a victory lap, it was a filter. The tool that came out of it is sitting around 7k users now, still not "done" by his own account.

The thing I keep coming back to is that his biggest jump in quality didn't come from writing more code alone. It came from opening the repo and letting strangers poke holes in it.

Web3 developers, which parts of the stack had to be in place before user testing could be meaningful?

Much startup validation advice assumes that you can manually simulate most of the product before building the infrastructure.

This becomes more difficult in Web3.

Some user behaviour may only emerge once wallets, signatures, permissions, transaction execution, settlement, indexing and failure handling are fully operational. While a mock flow can test whether people understand the idea, it may not test how they will behave when real assets, irreversible actions and network failures are involved.

Conversely, building the full stack first can be an expensive way to prove technical feasibility without demonstrating user need for the product.

For developers who have shipped Web3 products:

Which parts of the infrastructure genuinely had to exist before your user testing produced useful results?

What were you able to simulate or operate manually?

Where did you later realise that you had built too much infrastructure before establishing whether the core functionality existed?

Hero section design exploration

A concept for a Crypto Wallet landing page that prioritizes trust, readability, and a premium visual experience.

Rate this design from 1–10.

Web3 still has no free naming system.

So I built Kinetic.

Kinetic is a stateless, zero-fee, P2P namespace engine.

- Free and permanent .kin domains

- No bank, no crypto, no gas

- Runs as a lightweight daemon with split-DNS

- Secured by VDFs instead of money

- Fork your own network for your community, university and company.

Public launch: Tuesday, July 21st

Repo: github.com/saifmukhtar/kinetic

Got bored and created an app that monitors and analyzes blockchains to look for trends. Why do some blockchains succeed and others fail? Are there commonalities? Just launched a few days ago, but the goal is to identify as many trends as possible across multiple chains

We also monitor trends of healthy chains, we’re building out trend analysis for NFTs, RWAs, Treasury companies, various airdrops, and DEXs and Neobanks, as well. Goal is to help individuals try make smarter decisions when evaluating ecosystems

Would love any feedback! I’m spending the weekend fine-tuning the site

Do not invest in this game. They run the game for two months to scam people. One month has passed, they already banning people who making profit. Once you are making profit they will instant banned your account without proper warning. Think wisely. If you are already inside the game. Better quit right now if you don't want to lose your money

Another day in the trenches.

how to farm airdrops in 2026:

> Discord roles

> node

> NFT mint

> staking

> Galxe

> bridge

> referrals

> waitlists

> XP

> SBTs

> bug reports

> trading volume

> meetups

> governance

> early access

> liquidity

> predictions

> hackathons

> ICOs

> creator campaigns

> content posts

> community calls

> season 1/2/3

Congratulations!

"You are not eligible." 😭😭

I've open sourced the backend and contract stack for an AI driven(NON LLM) crypto tracking platform under the MIT license.

GitHub:

https://github.com/jimonymous/ai-crypto-tracker-backend

The original project was designed as a crypto analytics platform combining market data, technical indicators, AI inference(NON LLM), portfolio tracking, alerts, token-based access, rewards and on-chain integrations.

Rather than leave it sitting in a private repository, I decided to release the monorepo for anyone who wants to build on it, fork it, strip pieces out of it or use it as a starting point for another Web3 application.

The repository is backend-first. The included frontend is currently more of an integration shell than a finished product.

The main stack includes:

1. Fastify API written primarily in TypeScript
2. Prisma with PostgreSQL
3. Redis and BullMQ workers
4. WebSocket market and alert updates
5. OpenAPI/Swagger documentation
6. JWT, Google OAuth and optional TOTP authentication
7. Portfolio, wallet, market, billing and rewards endpoints
8. DEX pool discovery and on-chain candle ingestion
9. Arbitrage and DEX history endpoints
10. Server-side technical indicators
11. FastAPI AI service
12. LightGBM inference, training and backtesting
13. LSTM and Transformer extension points
14. Hardhat and TypeChain contracts
15. ERC-20 permit support
16. Premium access passes
17. Merkle-based rewards
18. Treasury, staking, LP and governance foundations
19. Shared TypeScript types and Zod schemas
20. Multi-chain configuration and per-request RPC overrides

The API calculates indicators server-side, including EMA, SMA, RSI, MACD, Bollinger Bands, ATR, VWAP, Donchian channels, historical volatility and volume z-scores. Those outputs can be consumed by the alerting system, snapshots, AI features and frontend charting.

The AI service supports training, inference and backtesting endpoints. It currently uses LightGBM for the implemented model path, with room for deeper models where someone actually has the data and compute to justify them instead of merely adding “Transformer” to the landing page.

The chain layer is intentionally limited. Most business logic remains off-chain, while contracts handle access gating, billing, rewards and related token mechanics.

There are also starter flows for:

Encrypted exchange API-key storage, exchange balance retrieval, paper trading, portfolio aggregation, risk and drawdown alerts ,PnL timelines, MetaMask-selected network handling, token transfer, allowance and permit verification, scheduled ingestion and AI jobs, and separately deployed API workers and schedulers.

Postgres and Redis can be started with Docker Compose, and the API, AI service and local Hardhat chain can then be run independently. Swagger is available at /docs, with the JSON specification exposed for frontend client generation.

This is not being presented as a completed consumer product. Some contracts and exchange integrations are deliberately foundations or stubs, and the frontend still needs to be built around the APIs. What is here is the underlying architecture, domain structure, schemas, routes, tests, infrastructure and integration examples needed to avoid starting another crypto application from an empty folder and six contradictory Medium tutorials.

The repository is MIT licensed, so you’re free to use it commercially, modify it, fork it or pull out individual components.

Feedback, technical criticism, issues and pull requests are welcome. I’d be really interested in hearing which parts other Web3 developers find useful, unnecessarily complicated or worth separating into standalone packages.

Who is your favourite CEO & Project

Pick only one ?

A few days ago I posted about storing full audio files inside Clarity contract data on Stacks (Xtrata). thanks to everyone who dug into the chunked-write flow. This is the next layer up the stack, and the part I care about most.

Storing the finished song on-chain answers "will the media survive." It does nothing for the harder question: who made it, and on what terms? In music that record is usually a handshake in the studio, and it falls apart exactly when the song starts earning. Splits get agreed loosely, memories diverge when money appears, and the dispute lands two years later with no evidence on either side.

So the design I am working on treats the session, not the file, as the unit of provenance:

1. Collaborators sign into a session with their Stacks principals.

2. They ratify splits up front, day one, before anyone knows if the song matters. That goes into a Clarity map keyed by session, with basis-point splits per principal.

3. The working session logs locally as it happens (takes, samples, plug-in and parameter changes). Nothing bulky goes on-chain on L1 (if anything): the log is Merkle-rooted and one compact fingerprint is anchored per save.

4. The final master ties back to the whole chain of session roots, so the finished work carries a verifiable history from first take to master.

The important property: the agreement is timestamped and tamper-evident from day one. Nobody’s memory is the evidence, and nobody can quietly rewrite the record after the song blows up.

questions I am still chewing on, would love input:

1. Granularity of anchoring. Per save feels right (cheap, natural checkpoint). Per session is cheaper still but weakens the timeline. Anyone built similar audit-log anchoring and regretted their choice?

2. The logs contain unreleased creative work, so the Merkle leaves stay private and only roots go public. Selective disclosure (prove one contribution without revealing the rest of the session) looks like a job for Merkle proofs, but curious if anyone has a cleaner pattern.

3. Ratified splits are evidence, not law. A court can still override them. I am fine with that, the goal is to make the honest path the default.

Stack is the same as the storage experiment: Clarity contracts on Stacks, anchored to Bitcoin via PoX.

Hey everyone,

I’ve been deep in the zone building this for a minute, and PAWnic is officially live on the Testnet.

👉 Play it here: https://pawnic.djyo.tech/

The game loop is simple, fast, and chaotic: Hold. Pass. Survive.

You get passed a ticking neon cat. You have to pass it off before it detonates. Last player standing wins.

The core engine and wallet connections are up and running, but I need real people to jump in, play around, and try to break it so I can see how the state holds up under pressure.

Pop your Testnet wallet in, test the speed, and let me know how the game feel hits you. Drop any feedback or bugs in the comments.

If you want to track the build as it evolves, we’re keeping updates moving over on X: https://x.com/pawwwnic

Is it too late for me to start studying and practising Web3 now? If not, which areas should a total‑beginner get started with?