DEV Community: Ribhav

Account Abstraction: The End of Seed Phrases

Ribhav — Fri, 03 Apr 2026 07:43:16 +0000

You’ve probably been told to write down your seed phrase, store it offline, never share it, and treat it like the key to a vault that can never be replaced.

That advice isn’t wrong, but it’s also a symptom of a deeper problem: we’ve been building Web3 on top of broken UX for years and only now are we really fixing it.

Account abstraction is that fix. Today on Day 57, we talk about what it actually changes for wallets, why it matters for real users, and what’s already live in production wallets right now.

But first, we need to look at why the old model was so fragile.

The problem with how wallets have always worked

Every wallet you’ve used, MetaMask, Phantom, Rainbow, is built on the same basic model: one private key, total control, no recovery. If you lose your seed phrase, everything in that wallet is gone forever. Not “frozen pending support ticket” gone. Gone gone.

This worked for early crypto users who understood the stakes. It does not work for almost everyone else.

Think about what we ask people to do when they onboard into Web3:

Write down 12 random words
Store them somewhere safe but offline
Never screenshot them, never save them in a notes app, never email them to yourself
Sign every transaction manually
Pay gas fees even for simple actions
Switch networks by hand when a dApp needs a different chain

This is not a user experience. It’s a hazing ritual.

Account abstraction changes the model entirely.

What account abstraction actually means

In Ethereum, there are two types of accounts: Externally Owned Accounts (EOAs) and smart contract accounts.

Your MetaMask wallet is an EOA, it’s controlled by a private key, it can send transactions, but it has no programmable logic. It just holds assets and signs things.

A smart contract account is different. It has code. It can enforce rules.

Account abstraction, specifically ERC‑4337, means turning your wallet itself into a smart contract. Instead of your private key being the only thing that authorizes transactions, you now have a programmable account that can define its own rules for what counts as authorization.

That one shift unlocks a lot, and most users will never see the complexity under the hood.

What it actually enables

Social recovery. Forget the seed phrase model. With a smart wallet, you can designate trusted “guardians”, friends, family, a hardware device, who can collectively authorize a wallet recovery if you lose access. They don’t need to know what a private key is; they just approve or reject a recovery request.

Passkeys instead of seed phrases. Modern devices support passkeys, biometric authentication (face ID, fingerprint) that never leaves your device. Smart wallets can use passkeys as the authorization mechanism. No seed phrase. No browser extension. Just Face ID.

Gas sponsorship. With ERC‑4337, a third party (a dApp, a protocol, a company) can pay for a user’s gas fees using a Paymaster contract. A game could let new players sign transactions for free, and an exchange could onboard users without them ever needing ETH to pay gas, turning “please go buy ETH first” into “just tap here.”

Batch transactions. Instead of approving a token and then making a swap in two separate transactions, two gas fees and two confirmations, a smart wallet can bundle them into one. One click, one fee.

Session keys. Imagine approving a game to perform in-game transactions on your behalf for the next hour, up to a spending limit, without signing every individual action. Session keys make this possible, turning “approve 47 individual transactions” into “start session.”

Spend limits and rules. You can program rules directly into the wallet such as “never allow a single transaction over 1 ETH”, “require 2-of-3 approvals for transfers above 10,000 dollars”, or “auto-decline any interaction with contracts deployed less than 30 days ago.”

Underneath all of this, there’s a new transaction flow that makes it work.

How ERC‑4337 works (without the headache)

The standard introduces a new flow for transactions:

Your smart wallet creates a UserOperation, basically a signed intent, “I want to do X.”
This UserOperation goes to a network of Bundlers, nodes that collect UserOperations and package them into actual transactions.
The Bundler submits the package to an EntryPoint contract, which verifies and executes each UserOperation.
A Paymaster contract, optional, can step in and pay gas on behalf of the user.

The clever bit: this doesn’t require any changes to Ethereum’s base layer. ERC‑4337 runs entirely on top of the existing network using smart contracts, so no hard fork is needed and EOAs keep working as they are.

Once that plumbing exists, the question becomes: who’s actually using it?

Who’s already using this

You’ve probably already touched account abstraction without realizing it.

Coinbase Wallet has been rolling out smart wallet features for mainstream users, and Base treats smart accounts as a first-class concept in its ecosystem.

Safe, formerly Gnosis Safe, has been a multi-signature smart wallet for teams and DAOs for years and is now evolving into a general smart account platform.

Argent pioneered mobile-first smart wallets with social recovery built in.

Worldcoin’s World App uses smart accounts under the hood for all user wallets.

Infra providers like Pimlico, Biconomy, and Alchemy’s account abstraction stack give developers ready-made Bundlers, Paymasters, and SDKs instead of forcing them to build everything from scratch.

The pattern is consistent: new consumer-facing chains and dApps are designing around smart accounts and account abstraction rather than the legacy EOA-only model.

So what does that mean if you’re the one building the dApp?

Why this matters for developers specifically

If you’re building anything in Web3 that regular people are supposed to use, EOA wallets are a liability. Every time a user has to sign a transaction, confirm gas, or switch networks, you’re losing them.

Smart wallets let you build onboarding flows that feel much closer to Web2 apps.

A user can sign up with email or Google, with a key generated behind the scenes and stored in the device’s secure enclave. Their first interactions can be gasless because your protocol sponsors the gas, and complex multi-step operations can be compressed into a single click.

The libraries are already there: Permissionless.js, Viem’s account abstraction modules, the ZeroDev SDK, and the smart account tooling from infra teams above are live on Ethereum mainnet and most major L2s.

But like everything in Web3, there are tradeoffs and new risks that come with the better UX.

The catch

Smart wallets are slightly more expensive to deploy and use than EOAs because they run more code per transaction, and there is a fragmentation problem where different smart account implementations often behave differently across chains.

ERC‑7579, a newer standard, tries to solve the fragmentation problem by defining a minimal modular interface for smart account “plugins” and extensions.

There is also a subtle trust issue: the more logic you add to a wallet, the larger the attack surface, so a poorly audited smart account module can be exploited even if the base protocol is safe.

So the question becomes: will the UX benefits outweigh the added complexity in the long run?

The bigger picture

We spent years telling people to be their own bank, but in the legacy Web3 model, being your own bank effectively means being your own IT department, your own vault manager, and your own security team.

Account abstraction is Web3 finally admitting that usability is not a nice-to-have; it’s the only path to real adoption.

The seed phrase isn’t going away overnight, but the best wallets being built today treat it as a fallback of last resort rather than the primary interface.

That’s the shift, and it’s already happening, with the next few years likely to become a live A/B test between “pure self-custody with no UX” and “programmable self-custody with training wheels.”

In tomorrow’s piece, we’ll look at what this actually feels like from a user’s perspective by walking through creating a smart wallet, setting up social recovery, and doing gasless transactions step by step.

Resources to go deeper

If you want to explore account abstraction and smart wallets beyond this article, here are some starting points:

The ERC‑4337 EIP and the official ERC‑4337 docs are the canonical references for how the standard works.

For modular smart accounts, the ERC‑7579 EIP and ecosystem guides such as this overview of how ERC‑7579 works are a good starting point.

Safe has clear explainers in its smart account overview and smart account concepts if you want to see how a battle-tested implementation thinks about accounts, modules, and guards.

If you want to try a live social-recovery wallet as a user, Argent is a solid entry point, and if you are a developer, the guides from Pimlico and Stackup’s “Understanding ERC‑4337” walk through practical integration details.

If you want to follow along as I keep learning, building, and occasionally changing my mind about Web3, you can find the rest of this 60-day journey on X, on Medium, on Future, and you can join the Web3ForHumans Telegram community to discuss these topics in plain language.

What Web3 Looks Like in 2026 and Where It Is Headed by 2030

Ribhav — Tue, 24 Mar 2026 06:51:31 +0000

I started this series in late 2025 with zero professional Web3 experience. Fifty-five days later I have 2 freelancing works, a live Telegram community, and a clearer picture of where this space is actually going than most people who have been in it for years. Not because I am special but because spending 55 days reading, building, writing, and talking to people in this space gives you a ground-level view that no single article or report can replicate. Today I want to share what that view looks like and where I think the next four years go.

If you want to keep up with this 60-day Web3 journey, you can follow me on X, on Medium, on Future, and you can join the Web3ForHumans Telegram community.

This is not a "top 10 predictions" post. It is an honest look at six trends that I think are real, backed by data that exists right now in March 2026, filtered through 55 days of building in this space from scratch.

Trend 1: RWAs Are No Longer Experimental

Real World Asset tokenization was a talking point in 2024. In 2026 it is a balance sheet line item. Tokenized RWAs grew to over $24 billion in total value by February 2026, representing 266 percent growth through 2025. Goldman Sachs and Fidelity are no longer experimenting with tokenized assets. They are integrating them into regular operations.

What this means practically is that the infrastructure layer for bringing real assets on-chain (government bonds, real estate, private credit, commodities) is being built right now by teams that will need technical writers, DevRel engineers, and community builders who understand both the financial layer and the Web3 layer. The wealth management and investment platform I am in conversations with right now is a direct example of this convergence happening at ground level.

By 2030 analysts are projecting the RWA tokenization market anywhere from $10 trillion to $16 trillion. Even the conservative end of that range represents a complete restructuring of how financial assets are held and traded globally.

Trend 2: DePIN Is Moving From Hype to Infrastructure

DePIN covered this series as early as Day 28 and the numbers since then have only reinforced the thesis. As of March 2026 there are 650 plus active DePIN projects with a combined market cap exceeding $16 billion. The World Economic Forum projects the DePIN market could reach $3.5 trillion by 2028 in an accelerated adoption scenario.

The energy sector currently accounts for 38 percent of global DePIN deployments, with AI compute (Render) and decentralized 5G (Helium) driving the fastest demand growth. These are not speculative use cases. Aethir closed a $344 million compute reserve deal in early 2026, which is enterprise-scale infrastructure spending, not crypto-native speculation.

The DePIN story by 2030 is simple: every major infrastructure vertical (wireless, compute, storage, energy, sensors) will have a decentralized alternative operating at meaningful scale. The question is not whether DePIN becomes foundational but which projects survive the consolidation.

Trend 3: AI and Web3 Are Converging Whether You Like It Or Not

The convergence of AI and Web3 is the trend most people either overstate or dismiss entirely. The reality is quieter and more structural. AI agents need verifiable identity, tamper-proof data, and permissionless payment rails to operate autonomously across different platforms and services. Web3 provides all three.

In 2026 this convergence is showing up in specific places: AI-generated content with on-chain provenance, autonomous agents settling micropayments via stablecoins, and decentralized compute networks (Render, Akash) providing the GPU infrastructure that AI training requires without the AWS monopoly.

By 2030 the most interesting Web3 infrastructure will be the layer that AI agents use to coordinate, pay each other, and verify their outputs. That layer is being built right now and it is largely invisible to the mainstream conversation which is still focused on token prices.

Trend 4: Stablecoins Are Becoming the Default Payment Rail

This showed up in the series during the stablecoin deep dives and it is only becoming more true. In 2026 stablecoins are not just a DeFi primitive. They are the settlement layer for impact finance, cross-border payments, and increasingly for payroll in remote-first Web3 teams.

My own P2P.me experience using stablecoin rails for real UPI transactions in Ludhiana is a micro version of a macro trend. The infrastructure for stablecoin-based payments in everyday contexts is being laid right now across India, Southeast Asia, Latin America, and Africa, specifically in markets where traditional banking infrastructure is either slow, expensive, or unavailable.

By 2030 a significant portion of cross-border remittances and B2B international payments will settle on stablecoin rails. The regulatory clarity that several countries are starting to provide is what unlocks this at scale.

Trend 5: UX and Onboarding Are Finally Being Taken Seriously

Account abstraction is the most underrated technical development in Web3 right now. The idea is simple: make blockchain interactions feel like Web2 logins instead of requiring users to manage seed phrases, gas fees, and wallet addresses manually.

For the past three years the biggest barrier to Web3 adoption was not technical capability but user experience. The protocols that win the next four years will not necessarily be the most technically sophisticated. They will be the ones that make the first five minutes feel easy. Progressive disclosure (showing complexity only when users are ready for it) and social recovery wallets are both gaining traction in 2026 as real UX solutions rather than research topics.

This trend matters for community builders and DevRel specifically. As onboarding gets easier, the bottleneck shifts from "can they set up a wallet" to "do they understand what they are doing and why". That is an education and communication problem, which is exactly the space that Web3ForHumans and this series are built around.

Trend 6: Web3 Careers Are Becoming Real Careers

The Web3 hiring market shifted significantly in January 2026. Roles in DevRel, technical writing, community management, and on-chain analytics are being posted by companies that have real revenue and multi-year runways, not just token treasuries.

The skills that are genuinely valuable in this market right now are: the ability to explain complex technical concepts in plain language, experience building and activating communities rather than just growing them, hands-on familiarity with at least one major protocol ecosystem, and a public track record of shipping things, whether articles, code, docs, or community programs.

All four of those are things this 60-day series has been building toward. Not accidentally. The series was designed from Day 1 as a career-building exercise disguised as a learning journal.

What I Think 2030 Looks Like

By 2030 Web3 infrastructure will be largely invisible to end users in the same way TCP/IP is invisible today. People will use stablecoin payment apps, earn from DePIN participation, hold tokenized assets in digital wallets, and interact with AI agents that settle on-chain without ever knowing or caring that they are "doing Web3".

The opportunity right now in 2026 is to build the bridges between what Web3 can do and what people actually need. That is the DevRel opportunity, the community opportunity, and the technical writing opportunity that the final days of this series have been mapping out.

Tomorrow: Web3 Career Paths in Detail

Day 57 goes deep on the three career paths that this series has been building toward: DevRel, community management, and technical writing in Web3. What each role actually pays, what hiring teams look for, and how to position yourself for each one with the work you have already done.

Resources

Day 55 - Open source and networking in Web3
Day 28 DePIN deep dive - Foundation for the DePIN trend
RWA.xyz - Live RWA tokenization data
DePIN 650 projects report March 2026 - Current DePIN market overview
Holepunch - P2P infrastructure that ties into AI x Web3 convergence
Web3ForHumans Telegram - Community built for the humans navigating all of this
Full 60-day series on Future - Complete archive of the journey

Open Source Contributions and How Networking Actually Works in Web3

Ribhav — Mon, 23 Mar 2026 12:26:58 +0000

There is no single moment where I decided to "network in Web3". Every connection that turned into real work happened through a chain of small honest actions, a tweet reply here, a cold text on Wellfound there, a friend's referral, a comment on an article. Looking back at Day 55 of this series, the pattern is clear: in Web3, networking and open source contribution are the same activity wearing different clothes.

If you want to keep up with this 60-day Web3 journey, you can follow me on X, on Medium, on Future, and you can join the Web3ForHumans Telegram community.

The connections that produced real paid work in my journey so far: Coinmonks on Medium led to Bitquery, a Wellfound cold message led to the Tether contract, a Twitter follow through a mutual friend led to Tim K's Think Tank, and a friend invited to Fensory. None of these started with a LinkedIn connection request. None came from a job board. All of them started with something small and public.

What Open Source Actually Means in Web3

Most people hear "open source contribution" and immediately think senior developer merging PRs into a major protocol. That picture is accurate but it is only about 10 percent of what open source actually needs. The other 90 percent is documentation, testing, issue reporting, translation, community moderation, tutorial writing, and proof-checking. All of that is contribution. All of it counts.

My first real open source adjacent work was contributing to the Keet documentation for Holepunch, which is part of Tether's infrastructure. I was not the sole author. I was part of a small team of contributors and proof-checkers working on documentation for an app with 10,000 plus downloads on the Play Store. The work was real, the repository was real, and the contribution was real even though I did not write a single line of Solidity.

The Peardoc project went one step further. A decentralized document editor built on Holepunch's P2P networking, with real-time collaboration and secure peer invitations via unique keys. No central server. That came directly from getting deep enough into the Holepunch ecosystem through documentation work to understand what was possible and what was missing.

Where to Start With Open Source if You Have No GitHub

Not having a GitHub profile is more common than the Web3 Twitter timeline suggests. Most early contributors start exactly where I did: with writing and documentation rather than code.

The fastest entry point is finding a protocol you already use or have written about and looking at three things. First, their official documentation for gaps, outdated pages, or confusing explanations. Second, their GitHub issues tab filtered by "good first issue" or "documentation". Third, their Discord or Telegram for questions that get asked repeatedly without a good answer anywhere in the docs.

Any one of those three is a contribution waiting to happen. Write the missing explanation, open an issue describing the documentation gap, or answer the repeated question in the community and then suggest it gets added to the docs. That is how most non-developer open source contributors get started and it is exactly how documentation-focused DevRel careers are built.

The Coinmonks to Bitquery Chain: How One Connection Built On Another

I started writing for Coinmonks on Medium because it was one of the most active Web3 publications accepting contributor pitches. Wrote consistently, built a small track record there, and then texted the admin directly. Not a formal application. Just a direct message explaining what I had written and what I could offer. That relationship led directly to the Bitquery freelance role, which produced two published pieces on prediction market APIs and DEX router slippage.

The chain looks like this: consistent public writing led to a publication relationship, that relationship created a credibility signal, that signal made a warm introduction to a technical platform possible. None of it would have worked without the writing being genuinely useful first. The networking was the easy part. The writing was the work.

This is the most important thing to understand about Web3 networking: the connection is only as strong as the work behind it. A cold DM from someone with nothing to show gets ignored. A cold DM from someone whose writing you have already read gets a reply.

The Wellfound Cold Text That Led to Tether

The Tether connection started with finding a technical lead from Tether who was forming a small team of his own in Bangalore. Found him on Wellfound, sent a direct message, connected, and got the role after passing a build test. No referral, no warm introduction, just a clear message to the right person at the right time backed by enough existing work to make the conversation worth having.

The lesson here is that cold outreach in Web3 works when it is specific and when you have something to point to. The message was not "I am looking for opportunities". It was closer to "I see what you are building, here is what I have done that is relevant, I would like to be part of this".

Wellfound (formerly AngelList Talent) is genuinely underused in Web3 hiring. Most early-stage Web3 teams list there before they list anywhere else. If you are targeting a role at a small protocol or Web3 startup, checking Wellfound and sending direct messages to technical leads and founders is a higher signal activity than applying through a job board.

Tim K's Think Tank: How Twitter Follows Turn Into Real Opportunities

Tim K was working with a mutual friend. I added him on Twitter, followed his work, and came across the Think Tank experiment when he announced it. An oversubscribed competitive MVP-building program with a waitlist. I was one of 14 participants and one of the 3 who actually submitted an attempt.

That opportunity came entirely from a Twitter follow that led to genuine engagement with someone's work over time. Not a cold pitch, not a formal application. Just being in the right digital room because of a real connection through someone both parties trusted.

This is how most good Web3 opportunities actually surface. Someone you know mentions someone worth following. You follow them and engage genuinely with their work. Over weeks or months a relationship forms that would never have happened through a job board. The Fensory platform conversations work the same way: a real friendship that extended naturally into professional collaboration because the work aligned.

What Networking in Web3 Actually Looks Like in 2026

The playbook is different from every other industry and it is worth being specific about what works and what does not.

Twitter and X replies are the highest value networking activity available to someone without a large following. A thoughtful reply to a founder, protocol lead, or active builder is seen by everyone who follows that person. It is a public demonstration of how you think. Do it consistently in one vertical and the right people notice over weeks not days.

Discord and Telegram are where the actual work conversations happen. Being a genuinely helpful presence in a protocol's Discord, answering questions, flagging bugs, contributing to discussions, puts you in direct contact with core team members in a context where they are actively paying attention. Most developer hiring at early-stage Web3 projects happens this way before a job is ever formally posted.

Cold DMs work when they are short, specific, and backed by existing work. Three sentences maximum: what you noticed about their work, one specific thing you have done that is relevant, and one clear ask. No attachments, no long introductions, no "I hope this message finds you well".

The Mistake Most People Make

Networking without contributing first is the most common mistake in Web3. People join Discord servers, add founders on Twitter, and send cold DMs before they have anything to show. The signal that lands is "I want something from you". The signal that works is "I have already been useful in this space and I want to be useful here too".

The 60-day series, the Telegram community, the published articles, the Keet contribution, and the Bitquery pieces all exist before any of the good opportunities arrived. The portfolio came first. The network followed the portfolio, not the other way around.

Tomorrow: Future Trends in Web3 (2026-2030)

Day 56 covers what the next four years look like in Web3: where the real adoption is coming from, which infrastructure is quietly becoming foundational, and what skills will be worth having by 2030. If you want a forward-looking view of where this space is going, that one is worth reading.

Resources

Day 54 - Building a public portfolio and ghostwriting for founders
Day 53 - Feedback loops and Web3 interview prep
Keet by Holepunch - Open source adjacent documentation contribution
Bitquery - Freelance role that came from the Coinmonks chain
Wellfound - Where the Tether cold outreach happened
My Portfolio - Full work history including all contributions
Web3ForHumans Telegram - The community that is itself a networking node

Building a Public Portfolio and Ghostwriting for Founders

Ribhav — Tue, 17 Mar 2026 11:36:43 +0000

A quick honest note before today's article. Days 53 to 54 had a longer gap than planned. A close friend got married, life happened, and then a wrist injury made typing genuinely difficult for almost two weeks. During that same period I landed a paid writing gig, a research and testing opportunity, and got into conversations with a wealth management and investment platform about managing their content infrastructure. Sometimes stepping away from the keyboard produces more results than staying at it. That is its own kind of feedback loop.

If you want to keep up with this 60-day Web3 journey, you can follow me on X, on Medium, on Future, and you can join the Web3ForHumans Telegram community.

What a Public Portfolio Actually Is

Most people think a portfolio is a PDF with links. In Web3 it is not. A public portfolio is everything you have shipped, written, built, or contributed to that someone else can verify without asking you. It is your GitHub commits, your published articles, your Telegram community, your Twitter replies, and your documented projects. The Notion page, the Medium series, the Bitquery bylines, and the Tether FAQ are all portfolio. None of them started as portfolio. They started as work.

Looking at my own journey the portfolio built itself in layers. The Huawei Dev Community work came first: testing APIs, writing integration guides, and supporting campus hackathon registrations. Those articles got picked up by Dev Genius and Towards Dev on Medium, which was the first external validation that the writing was clear and useful. That signal led to the Tether contract, which led to the Bitquery freelance pieces, which led to inbound offers in comments on this series. Each layer made the next one easier to land.

The Portfolio Nobody Tells You to Build

There is a portfolio most people ignore completely: the thinking portfolio. Not just what you built but how you thought about it publicly. The 60-day series is a thinking portfolio. Every article shows how I approached a concept, what confused me, what clicked, and what I want to build next. A hiring team reading Day 1 to Day 54 knows more about how I think than any resume could communicate.

The Peardoc project from the Holepunch's tech stack is a good example. A decentralized document editor built on Holepunch's P2P networking with real-time collaboration, secure peer invitations via unique keys, and no central server. That one project shows technical curiosity, execution under a brief, and comfort with cutting-edge Web3 infrastructure. It is more interesting than a list of skills on a resume.

The Stoa fellowship, the Toastmasters work, the event organization experience from college: all of these are portfolio. They show range. Web3 roles, especially DevRel and community, value range. A person who can write technical docs, run a college event with 7,000 footfall, facilitate a room, and build a P2P app is a very different hire from someone who only codes.

How to Build Your Portfolio From Zero Right Now

The fastest way to build a Web3 portfolio from zero is to pick one protocol you find genuinely interesting, spend one weekend building or writing something with it, and publish that work publicly with honest documentation of what worked and what did not.

The documentation is the differentiator. Most builders ship and move on. The ones who document what broke, what they tried, and what they learned create a paper trail of thinking that hiring teams and collaborators can actually evaluate. My Tether interview brief was essentially this: use Holepunch technology, build something real, show your thinking. The output was Peardoc.

For writers the equivalent is: pick one underexplained topic in your target vertical, write the clearest explanation of it you can find, and publish it somewhere with a byline. Then do it again. Ten focused articles on one vertical over two months will outperform a hundred generic posts every single time.

Ghostwriting for Web3 Founders: What It Actually Looks Like

Ghostwriting in Web3 is one of the most underrated income streams for technical writers and community builders. Founders at early-stage protocols are building full time and have no bandwidth to write the threads, blog posts, and documentation their community needs. They know what they want to say but cannot find the time or the words to say it clearly.

The ghostwriter's job is to capture the founder's voice, translate their technical thinking into accessible language, and produce content consistently enough that the founder's presence feels real even when they are heads down building. Good Web3 ghostwriting pays well because it requires a rare combination: technical understanding, writing skill, and the ability to sound like someone else.

Getting started is simpler than most people think. If you have been writing publicly in a specific vertical (DeFi, DePIN, identity, tooling) for a few months you already have a sample set that shows your voice and your range. The pitch to a founder is straightforward: "I follow your project, I understand what you are building, here are two sample posts I wrote in your voice, would you want to try one month of working together?"

The Portfolio Checklist for Web3 Roles

If you are targeting a DevRel, community, or technical writing role in Web3 right now, here is the honest minimum that gets you taken seriously:

Two to three published technical articles with a byline on a real publication (Medium, Dev.to, a protocol blog). One live project you can demo even if it is small. One community you contribute to actively whether as a member, moderator, or creator. One example of explaining something complex in plain language to a non-technical audience. And a public profile (Twitter, LinkedIn, or a portfolio page) that connects all of the above so a hiring manager can see the full picture in under two minutes.

Everything on that list can be built in 60 days. This series is proof of that.

Tomorrow: Open Source Contributions and Networking in Web3

Day 55 covers how to contribute to open source Web3 projects without being a senior developer, and how networking in Web3 actually works in 2026, which is very different from sending LinkedIn connection requests.

Resources

My Portfolio - Full work history including Tether, Huawei, Peardoc and more
Day 53 - Feedback loops and Web3 interview prep
Bitquery freelance pieces - Real bylines from this series
Keet FAQ by Tether - Contract technical writing output
Web3ForHumans Telegram - Community that doubled as portfolio signal
Full 60-day series on Future - The thinking portfolio in full

Web3 Jobs Decoded: Feedback Loops, Interview Prep, and Hiring Criteria

Ribhav — Sat, 07 Mar 2026 05:53:13 +0000

I have been getting comments on my articles asking me to write for them. Not from a cold outreach I sent, not from a resume I submitted, just from people reading the series and reaching out. That is a feedback loop working exactly the way it should. Today I want to break down why feedback loops matter more than most people think, and what Web3 interviews actually look like when you finally get in the room.

If you want to keep up with this 60-day Web3 journey, you can follow me on X, on Medium, on Future, and you can join the Web3ForHumans Telegram community.

This series started as a personal learning challenge on Day 1 and by Day 53 it has turned into a writing portfolio that landed me a freelance role at Bitquery, a contract technical writing role at Tether, and multiple inbound writing offers. None of that came from applying. All of it came from feedback loops compounding over time.

What a Feedback Loop Actually Is

A feedback loop is any system where output becomes input. You publish something, someone reacts, that reaction changes what you publish next, and the cycle tightens over time. In community building and content creation, feedback loops are the difference between growing in the dark and growing with direction.

Most creators treat feedback as validation. "Did people like it?" That is the wrong question. The right question is "what did people do after reading it?" A comment asking "can you write for us?" is stronger feedback than 100 likes. A DM saying "I tried this and it did not work" teaches you more than 50 bookmarks.

The three feedback signals that actually matter in Web3 content are replies with follow-up questions (people want more depth), inbound writing or collaboration offers (people trust your knowledge), and topic requests (people want you to cover something specific). All three have shown up in this series across Medium, Future, and X. That is the feedback loop doing its job.

How to Build a Feedback Loop Into Your Content

Most people publish and wait. A feedback loop requires one more step: you have to make it easy for people to respond with something useful.

At the end of every article in this series there is a question or a forward-looking statement like "tomorrow we cover X". That is not just a CTA. It is a feedback collector. People who engage with that line are telling you exactly what they want next. The Web3ForHumans Telegram community functions as a live feedback channel where every article generates discussion that directly shapes the next one.

For community builders the same principle applies offline. The Ludhiana Baithak format from Day 52 ends with "what do you want next time" as a formal part of the agenda. That single question closes the loop between what you planned and what the room actually needed.

The Think Tank and What It Taught Me About Real Feedback

In January 2026 I was part of Tim K's Think Tank experiment, a competitive MVP-building program that was oversubscribed even with minimal promotion. Of 14 participants only 4 submitted attempts and 2 showed the required time commitment. I was one of them.

The experiment was designed to build something real in a compressed timeframe with peer accountability as the feedback mechanism. What it taught me is that most people confuse "I understand this" with "I can build this". The gap between comprehension and execution is where real feedback lives. Shipping something half-broken teaches you more than reading ten articles about the topic.

That same principle showed up in my Tether's contract writer interview. They did not ask me theory questions. They asked me to build a functioning MVP using Holepunch technology and Hypertele. The interview was the feedback loop: your ability to execute under ambiguity is the signal they were reading.

What Web3 Interviews Actually Look Like

Web3 hiring is different from traditional tech hiring in three specific ways. First, your public work is your CV. Before any interview, the hiring team has already read your GitHub, your articles, your tweets, and your community presence. By the time I got to the Tether interview my writing was already doing the talking.

Second, Web3 interviews test execution not just knowledge. The Tether interview was a build challenge. The Bitquery freelance engagement started with a real brief on a real topic, not a test. Both required me to produce something working, not just explain how it works.

Third, the interview is often a conversation between builders. Web3 teams are small and cross-functional. They want to know if you can think out loud, admit what you do not know, and figure things out in real time. The worst thing you can do in a Web3 interview is pretend to know something you do not. The best thing you can do is show exactly how you would find out.

What Gets You the Interview in the First Place

The writing offers I have received as comments on this series are a direct result of one thing: specificity. Articles that cover one topic deeply and honestly attract people who need exactly that expertise. The Bitquery freelance pieces on prediction market APIs and DEX router slippage landed because the series showed I could explain complex on-chain concepts in plain language. That is not luck. That is a feedback loop that ran for 50+ days and produced a legible signal.

The practical steps if you are targeting a Web3 role right now are straightforward. Pick one vertical (DevRel, technical writing, smart contract development, community) and publish 10 articles in that vertical. Reply to every comment. DM three people per week whose work you genuinely find interesting. Build one thing publicly even if it is small. By the time you apply anywhere, your work will have already introduced you.

How to Prepare for a Web3 Interview Specifically

For DevRel and community roles the most common questions are about your approach to onboarding new developers, how you handle negative community feedback publicly, what metrics you use to measure community health, and how you would explain a complex protocol concept to a complete beginner. Every one of those questions is answered by the work you do publicly before the interview.

For technical writing roles like the ones I have landed, the ask is almost always a live brief. Have 2 to 3 published samples that show range: one conceptual explainer, one tutorial with code, and one opinion piece. Those three formats cover everything a Web3 technical writing team needs to evaluate.

For developer roles, the Tether approach is becoming more common: build something real using the protocol's own stack. The best preparation is to spend a weekend building with the technology of the company you are applying to and documenting what you built, what broke, and what you learned.

Tomorrow: Building a Public Portfolio and Ghostwriting for Founders

Day 54 covers how to turn everything you have built publicly into a portfolio that gets you hired, and what ghostwriting for Web3 founders looks like as a freelance opportunity. If you are considering writing as a Web3 income stream, that one is directly relevant.

Resources

Day 51 - DevRel and community building foundations
Day 52 - Hackathons, events, and Ludhiana Baithak announcement
Bitquery - Where freelance writing led from this series
Tim K on X - Think Tank experiment and MVP building
Holepunch - P2P technology used in Tether interview build
Web3ForHumans Telegram - Live feedback channel for this series
Full 60-day series on Future - Complete archive

Hackathons Without Attending One: My Web3 Event Strategy Blueprint

Ribhav — Tue, 03 Mar 2026 06:54:04 +0000

I have never been to a Web3 hackathon. I have never attended a Web3 meetup. But I have organized college festival events with artists where the footfall crossed 7,000 people, and I spent a week embedded inside Tether's team working on documentation for Keet. So when it comes to hackathons and events, I am not starting from zero. I am starting from a different angle, and today I want to share what that looks like.

If you want to keep up with this 60-day Web3 journey, you can follow me on X, on Medium, on Future, and you can join the Web3ForHumans Telegram community.

What Hackathons Actually Are (And Why Most People Miss the Point)

A Web3 hackathon is not just a coding competition. It is a coordination event. Teams form around problems, build fast, get feedback, and ship something in 24 to 72 hours. The best hackathons (ETHIndia, Chainlink hackathons, Solana Grizzlython) are where developers meet protocols, protocols find early builders, and communities get formed around shared problems.

Most people go to win prizes. The ones who actually grow go to learn in public. A weekend at a hackathon gives you compressed experience that would take months of solo building to get. You see how other builders think, how protocols explain their tech, and how judges evaluate real work versus polished presentations.

The entry strategy for beginners is simple. Pick a track you already know (DeFi, DePIN, identity, tooling), find a team of 2 to 3 people, and commit to shipping something tiny but working. Judges at every hackathon will tell you the same thing: a live demo beats a perfect pitch deck every single time.

What I Learned Working Inside Tether's Team

In 2024 I spent nearly a week in person working as a contract technical writer with Tether otherwise it was remote, specifically on Keet, their peer-to-peer communication app. The team had about 15 people working on different projects: coders handling miner systems, an AI team, a Linux team, and various developers. I was the only non-coder in the room most of the time.

What that week taught me about Web3 events and community is something no hackathon guide covers. Real Web3 teams do not work the way the Twitter timeline suggests. They are quiet, focused, and deeply technical. The communication gap between what they build and what the outside world understands is enormous. That gap is exactly where DevRel and community work lives. Every meetup, every hackathon recap, every beginner guide is a bridge across that gap.

That experience directly shaped why I want to build an offline Web3 community in Ludhiana, not just an online one.

Why Ludhiana Needs Its Own Web3 Community

Ludhiana is a business city. Most families here are business-driven and the few people who are in Web3 are mostly trading. There are very few builders and even fewer people who understand the difference between "buying crypto" and "using Web3". That gap is the opportunity.

The plan is to build under the Web3ForHumans brand with local chapters called Baithaks. Starting with "Web3 for Humans – Ludhiana Baithak", then expanding to Chandigarh, Delhi, and across North India. The goal is not a location-specific community. It is a brand that expands city by city with the same format and values.

The format for each Baithak will be 2 hours structured around four things. First, a trader story circle where 2 to 3 people share a real experience (win, loss, or scam) and we break it down in plain language. Second, a learn-by-doing block where everyone does one live on-chain action together. Third, a build corner where small groups brainstorm a micro-project. And fourth, a vote on which idea becomes the "project of the month" carried forward in the Telegram group.

No shilling, no pitch decks, no English-only pressure. Punjabi, informal, and outcome-driven.

How Event Management Skills Transfer from Offline to Web3

Organizing a college festival with 7,000 plus footfall taught me things that directly apply to Web3 events. The logistics are different but the human dynamics are identical. People show up for energy, not agendas. The first 15 minutes set the entire tone. Every dead moment loses 20 percent of the room. And the post-event content (photos, recap, quotes) does more for the next event than any pre-event promotion.

For Web3 events specifically, three things make the difference between a meetup people remember and one they forget by Tuesday. First, a clear villain or shared problem (scams, confusing UX, bad onboarding). Second, one live demo that makes something abstract feel real. Third, a way for every person to contribute something before they leave, even if it is just one question or one story.

The P2P.me experience is a good example of this principle in practice. I used it for real UPI transactions in Ludhiana. That one real-world action taught me more about peer-to-peer Web3 value transfer than ten articles. That is exactly the kind of live demo that makes a Baithak memorable.

Hackathon Strategy for Beginners (What I Would Do)

Since I have not attended one yet but am planning to, here is the honest strategy I am building for myself. Start as a non-technical contributor at your first hackathon. Every team needs someone who can write the pitch, document the build, and present clearly. That is a legitimate and valued role. You see the full build process without needing to write Solidity on day one.

Pick ETHIndia or a Chainlink hackathon as your first because the community is large, the beginner tracks are real, and the documentation/DevRel resources are excellent. Come with one clear skill to offer (writing, design, research, testing) and be honest about what you bring. Teams that lose hackathons usually lose because of communication and presentation, not code.

After one hackathon as a contributor, you know enough to lead the non-technical side of a team. After two or three you know enough to scope what is actually buildable in 48 hours, which is a skill most developers take years to develop.

Resources

Day 51 - DevRel and community building foundations
Keet by Tether - The project I worked on as a technical writer
P2P.me - Real-world Web3 UPI transactions
Web3ForHumans Telegram - The online community that becomes the Baithak funnel
ETHIndia - Best first hackathon for India-based Web3 builders
Chainlink Hackathons - Strong beginner tracks and solid DevRel support

I Wrote 51 Articles in Web3. Here Is What Actually Happened

Ribhav — Mon, 02 Mar 2026 07:17:47 +0000

Quick note before we dive in: the dashboard project from Days 46-50 continues on the backend. I will share a live update on Day 56 and a final build recap on Day 59. Today we shift to Phase 5 of this series: Career and Leadership in Web3.

If you want to keep up with this 60-day Web3 journey, you can follow me on X, on Medium, on Future, and you can join the Web3ForHumans Telegram community.

I used to write every night. Pour my thoughts into words. Hit publish. And wait. Then nothing. No clicks. No noise. Just silence. I thought maybe people did not like my voice. Or worse, maybe I did not have one. But I was wrong. People did not skip my content because it was bad. They skipped because I gave them no reason to stop scrolling. That was the first lesson I learned about DevRel without even knowing it had a name.

But here is what 51 days of showing up actually looks like in numbers:

Medium Stats (Dec-Feb):

December: 3.5K presentations, 428 views, 93 reads, +13 followers
January: 1.8K presentations, 548 views, 62 reads, +7 followers
February: 5K presentations, 689 views, 105 reads, +8 followers

Community:

Web3ForHumans Telegram: 40 members and growing
Medium followers: 47
Twitter/X followers: 19

Freelance Writing:

2 articles published by Bitquery and CoinCodeCap:
- Top Prediction Market APIs
- DEX Router Slippage for Algo Traders

None of these numbers are viral. But every single one moved. That is what consistency does. And that is what DevRel is built on.

What DevRel Actually Is (And What It Is Not)

Developer Relations is one of those roles that sounds corporate until you realize it is just "be genuinely helpful to builders in public". A DevRel engineer sits at the intersection of product, engineering, and community. They write docs, run workshops, answer Discord questions at midnight, speak at hackathons, and tweet code snippets that save someone three hours of debugging.

What it is not: a marketing job with a GitHub account. The best DevRels are builders first. They feel the pain of a bad API or a confusing onboarding flow because they have been there themselves. In Web3 specifically, DevRel means being the bridge between a protocol's technical team and the developers trying to build on top of it.

The role exists because most protocols are built by brilliant engineers who do not have time to explain their work to the outside world. DevRel does that translation. They make the complex feel approachable without dumbing it down. My two freelance pieces for Bitquery (prediction market APIs and DEX router slippage) came directly from doing exactly this: taking complex on-chain concepts and making them readable for developers who needed them.

The Open Loop and Why It Matters for DevRel

Here is something I learned about writing that applies directly to community building and DevRel content. I used to think writing was about expression. Turns out it is about tension. Your first line decides if your story lives or dies. If your first sentence does not make someone wonder, they will never reach your second.

I started using what I now call the Open Loop. You start your story but you do not finish your first thought. You leave a question hanging. You open a curiosity gap. Instead of writing "I learned to write better by practicing daily", you write "It took me six months to realize I was practicing the wrong way". Same idea. Completely different pull. You do not tell them. You make them chase it.

The first time I tried it I posted with the line: "I used to think no one cared about my writing, until one comment changed everything." Twenty four hours later it had ten times more clicks than any of my old posts. People stopped scrolling because they needed to know what that comment was. That is the power of an open loop. It does not shout. It pulls.

This is exactly what great DevRel content does. It does not start with "here is our documentation". It starts with "here is the problem you have been ignoring and here is why it matters right now". The formula in one line: do not start with the truth, start with the mystery that leads to it. Writing is not about information. It is about invitation. Invite them to lean in, to wonder, to need to know.

Community Building Strategy in Web3

Building a Web3 community is not about follower counts. It is about creating a space where people feel smarter after showing up. Web3ForHumans grew to 40 members without a single paid promotion, just daily content and genuine conversation. Small but activated. The communities that win in Web3 share three things consistently.

They have a clear villain. Every strong community knows what it is fighting against, whether that is centralization, bad UX, or information gatekeeping. Web3ForHumans exists because Web3 feels unnecessarily complicated. That shared frustration is the glue that holds early members together.

They reward contribution over consumption. Discord servers with ten thousand members and zero active threads are graveyards. The best communities make it easy to contribute something small, answer a question, share a resource, test a new protocol, and recognize that contribution publicly. Every reply I got on Medium or Future came from someone who felt seen by the content, not sold to.

They build in public. This entire 60-day series is a community building exercise disguised as a learning journal. Every article is an invitation to follow along, disagree, or build on top of. That transparency creates trust faster than any marketing campaign. February's 5K presentations on Medium with 689 views happened not because the content was perfect but because it was honest and consistent.

What Community Building Looks Like Day to Day

The romantic version of community management is hosting Twitter Spaces and giving keynotes. The real version is replying to every comment, writing the weekly recap nobody asked for, DMing the new member who joined but never spoke, and staying consistent when engagement drops. In Web3 the tools are Telegram, Discord, Farcaster, and Lens, but the work is the same as any community: show up, add value, repeat.

The metric that matters is not size but activation rate. If your community has 500 members and 50 engage weekly, that is a 10 percent activation rate, which is genuinely strong for Web3. Most large communities hover at 1 to 2 percent. Quality over quantity is not a cliche here, it is the strategy. Web3ForHumans at 40 members with daily conversation beats a 4000-member ghost town every time.

How DevRel and Community Connect

DevRel without community is just documentation. Community without DevRel is just vibes. The best Web3 projects treat them as one function. The DevRel team creates content that attracts builders. The community gives those builders a place to land, stay, and grow. The feedback from community flows back into the product via DevRel. It is a loop, and when it works it compounds fast.

The freelance writing that came from this series happened because the content proved I understood the space. Portfolio before resume. If you are targeting a DevRel or community role in Web3, the single most valuable thing you can do is build your own small community around something you genuinely care about. Web3ForHumans started as a Telegram group. This 60-day series is its content engine. That combination, community plus content plus consistency, is the portfolio that gets you hired.

Twitter/X at 19 followers is not a big number. But every follower there came from Web3 content, which means every one of them is a potential collaborator, reader, or future community member. That is a more valuable 19 than 1000 random follows.

Resources

Day 46 - Dashboard origin and Phase 5 pivot
Day 49 - Community coordination mechanics from games
Day 50 - v0 scope for the dashboard
Web3ForHumans Telegram - The community this series is building
Top Prediction Market APIs - Bitquery freelance piece 1
DEX Router Slippage for Algo Traders - Bitquery freelance piece 2
Developer DAO - Largest Web3 developer community to study and join

Defining v0 For The Dashboard Project

Ribhav — Wed, 25 Feb 2026 11:13:18 +0000

Yesterday in Day 49 we locked in three game mechanics (quests, seasons, leaderboards) for the dashboard. Today we define exactly what v0 must ship: the absolute minimum that proves people want to track their DeFi positions, stablecoin impact, and DePIN coverage in one place. No nice-to-haves, no scope creep, just "does this core idea work".

If you want to keep up with this 60-day Web3 journey, you can follow me on X, on Medium, on Future, and you can join the Web3ForHumans Telegram community.

The dashboard traces back to Day 46 when I realized 45+ days of learning gave me enough pieces (DeFi from earlier days, stablecoins, DePIN, identity) to stop reading and start building something concrete. Days 47-49 added the retention hooks. v0 answers "can I actually make this and will anyone care".

v0 Must Solve These Three Problems

Most Web3 dashboards fail because they show too much or too little. v0 picks exactly three user problems from the series roadmap.

Problem 1: "I don't know what I'm actually doing on-chain."

Users connect MetaMask but see 50 protocols across 10 chains. v0 shows top 3 chains + top 3 protocols by value. Simple pie charts. No token names, just "47% Ethereum DeFi, 32% Polygon stablecoins, 21% Base infra".

Problem 2: "Is my yield risky or sustainable?"

From stablecoin days, we know APY hides counterparty risk. v0 pulls DeFi positions and flags: "Aave (low risk, 4% APR)", "Unknown LP (high risk, 23% APR)". Color-coded, no jargon.

Problem 3: "What's my real-world footprint?"

DePIN taught that Helium hotspots or Hivemapper miles cover actual geography. v0 maps your holdings: "Your $100 Helium = coverage over 3km² in Ludhiana". Ties abstract tokens to reality.

What v0 Must Do (The Minimum)

v0 ships when these five things work end-to-end. Nothing else.

Wallet connect: MetaMask + 1-click (no social login).
Three data views: DeFi positions, stablecoin breakdown, DePIN coverage.
Three quests (from Day 49): Connect wallet, log DeFi, find DePIN. Checkboxes unlock views.
Export button: PNG summary ("My Web3 Month") for Twitter/Telegram.
Mobile readable: Single column, no hover states, works on phone.

Tech constraints for v0:

One chain first (Ethereum mainnet, expand later).
Free/public APIs only (no paid Dune queries).
Static site (Vercel/Netlify), no database.
No user accounts beyond wallet connect.

What v0 Deliberately Excludes

Scope discipline matters more than features. v0 says no to:

Multi-chain (Ethereum first, Polygon/Base later).
Advanced analytics (APY risk scores in v1).
Social/leaderboards (Day 49 mechanics come post-MVP).
Seasons (single month baseline).
Custom themes/export customization (v1 stretch).

This forces focus: if v0 cannot prove the core value prop ("show me my Web3 impact") with just these pieces, nothing will.

Success Looks Like This

v0 succeeds if after one week:

I connect my own wallets and see "47% DeFi, 32% stables, 21% DePIN" breakdown.
Quest 3 shows my Helium stake covers actual Ludhiana map area.
I tweet the PNG summary and get 3-5 "wait, what's this?" replies from Web3ForHumans.
Build takes <20 hours total (track time publicly).

Failure = cannot pull live DeFi/DePIN data, quests feel pointless, or nobody cares about the summary.

Tomorrow: Architecture Sketch

v0 scope locked. Tomorrow we sketch the simplest stack: frontend, APIs, data flow. No code yet, just "here's how these five pieces connect without breaking".

This is the pivot from "learning concepts" to "shipping something real". Days 1-49 built the mental map. Days 50-60 execute.

Resources

Day 46 - Dashboard origin story
Day 49 - Quests/seasons/leaderboards spec
DePIN foundations - Real-world infra data source
Free DeFi APIs: Zapper, DeFiLlama
Wallet connect: Web3Modal

What I'm Borrowing From Games For My Web3 Dashboard Project

Ribhav — Tue, 24 Feb 2026 12:58:52 +0000

Over the past few days, we have moved from GameFi 1.0 mistakes in Day 47 to what on‑chain games got right as coordination labs in Day 48. Today I am taking those 3 specific mechanics (quests, seasons, leaderboards) and applying them directly to the dashboard project from Day 46. No tokens, no grind, just light coordination hooks.

If you want to keep up with this 60‑day Web3 journey, you can follow me on X, on Medium, on Future, and you can join the Web3ForHumans Telegram community.

The dashboard goal stays the same: one place where I (and eventually others) can see what my DeFi positions, stablecoins, DePIN activity, and infra usage are actually doing in the real world. From earlier days on stablecoins and DePIN, we know this data exists on‑chain. The challenge is making people want to check it regularly instead of treating it like a tax report.

Games from yesterday showed the answer: people show up daily for small wins, visible progress, and light social comparison. Here is exactly what I am borrowing and how it fits.

Quests: Turn Data Into Small Wins

Games use quests not for grinding, but for guiding new players to the core loop. "Kill 5 goblins" teaches combat. "Connect 3 wallets" teaches wallet management.

For the dashboard:

Quest 1: "Connect your first wallet and see your top 3 chains".
Quest 2: "Log one DeFi position (Aave or Compound) and check APY versus risk".
Quest 3: "Find one DePIN holding (Helium or Hivemapper) and map its real‑world coverage".

Each quest unlocks one view or metric. Complete all 3 and you get a simple "Web3 Footprint" summary tying DeFi, stablecoins, and infra together. No rewards, just the dopamine of checking boxes and seeing your activity visualized.

Seasons: Fresh Starts Without Reset Fatigue

Games run in seasons, for example 30 days, so progress feels meaningful but not permanent. You cannot lose years of grinding, but you also cannot coast on old wins forever.

For the dashboard, one‑month seasons make sense:

Season 1: "Baseline" – track what you touched (chains, protocols, total impact).
Season 2: "Optimize" – compare risk and yield across positions, find DePIN overlaps.
Season 3: "Expand" – add identity layer (ENS or on‑chain reputation) plus social sharing.

At season end, you get a shareable report card: "Tracked X dollars in DeFi, Y percent in regen stables, Z hotspots on Helium". You can archive past seasons and compete against yourself.

Leaderboards: Light Social Proof (Optional and Anonymized)

Leaderboards create FOMO without needing tokens. Games rank you against others for motivation, not cash.

The dashboard version stays private‑first:

Personal leaderboard: your progress versus your own average, for example "30 percent more DePIN coverage than last season".
Global (opt‑in): anonymized wallet hashes ranked by an "impact score" made from DeFi yield, DePIN coverage, and stablecoin regen percentage, with only the top 100 visible.

There are no names and no direct competition. It is just enough social pull to make you check in and ask "am I in the top 10 percent for balanced infra and DeFi this season".

Why This Works (And What It Is Not)

These are not gamification for gamification's sake. They solve real retention problems. Quests onboard and answer "what do I do first". Seasons create rhythm for weekly or monthly check‑ins. Leaderboards add mild accountability without toxicity.

This is not GameFi 2.0. There are no emissions, no daily farm pressure, and no salary replacement promises. It is coordination psychology applied to personal Web3 tracking, the same way games coordinate without forcing addiction.

Tomorrow: v0 Scope Locked In

With these mechanics decided, tomorrow we narrow v0 and decide what must ship first, for example wallet connect, basic DeFi and DePIN views, and the first three quests. There is no architecture detail yet, just the minimum dashboard that proves the idea.

I am committing that these game primitives go in. They are what will make the difference between a forgotten tool and something people check weekly.

If you want to follow along as I keep learning, building, and occasionally changing my mind about Web3, you can find the rest of this 60‑day journey on X, on Medium, on Future, and you can join the Web3ForHumans Telegram community to discuss these topics in plain language.

Resources

Dashboard origin, the money, infra, and impact tracker: Day 46
GameFi failures that informed this: Day 47
Coordination labs and examples: Day 48
Dark Forest – wallet‑based reputation example.
DePIN foundations for dashboard data: DePIN Day

On‑Chain Games As Coordination Labs

Ribhav — Sat, 21 Feb 2026 05:30:00 +0000

Yesterday we looked at what GameFi 1.0 got wrong: unsustainable token emissions and games that were more grind than fun. Today I want to flip that and look at what games got right, specifically how on‑chain games work as coordination labs for incentives, identity, and social dynamics that matter outside of gaming. This is not about building the next Axie, it is about stealing primitives that could make my dashboard project from Day 46 more sticky for regular users.

If you want to keep up with this 60‑day Web3 journey, you can follow me on X, on Medium, on Future, and you can join the Web3ForHumans Telegram community.

In Day 47, we saw how attaching money to every click turned players into workers and made the whole system fragile. But strip away the "earn salary" hype, and you see games doing something powerful: getting thousands of strangers to coordinate around shared goals, track reputation, and build habits over time. That coordination layer is what I am interested in for a dashboard that is supposed to help people understand their own Web3 activity.

Games Test Incentives Without Real Money (At First)

The smartest on‑chain games start simple. They do not launch with tokens. They launch with mechanics that make people want to show up daily, compete lightly, and feel progress. Only later do they layer money on top, if at all. This is the opposite of GameFi 1.0, where tokens came first and ruined everything.

Take something like Dark Forest, an on‑chain strategy game that has been running for years. Players explore a galaxy, build bases, attack each other, all happening live on Ethereum. No upfront NFT buy‑in, no promised yields. You just play, and your actions create real on‑chain history that others can see and react to. It proves people will grind for status and competition alone.

Or look at modern coordination games like Parsec, where guilds or teams coordinate resources and strategy on‑chain. Here the game is not "kill monsters", it is "how do we align 50 strangers to defend territory or pool resources without a central boss". That is pure DAO mechanics disguised as gameplay.

Reputation And Identity Emerge Naturally

One thing games force you to solve is identity. In a multiplayer game, you need to know who you are playing against, who you can trust for alliances, who has a history of backstabbing. On‑chain games solve this with simple, visible reputation systems.

Your wallet address becomes your persistent identity across seasons.
Leaderboards show not just scores, but patterns (aggressive, defensive, cooperative).
Past actions are public forever, so betrayal has real cost.

This feels familiar if you read the earlier days on on‑chain identity. Games just make it concrete: your "Web3 resume" is your win/loss history, your guild contributions, your streak of daily logins. No need for fancy ENS names or SBTs if the game already tracks it.

What This Means For Non‑Game Projects

The reason I care about game coordination is because my Day 46 dashboard needs the same stickiness. People will not check "what is my DeFi/DePIN activity doing" every day unless there is light game pressure: visible progress, streaks, social proof.

From games, I want to borrow:

Quests: "Connect 3 wallets this week" or "track one DePIN position".
Seasons: Monthly resets so progress feels fresh, not endless grind.
Leaderboards: Anonymized (just wallet hashes), showing top impact trackers. No tokens, just bragging rights.

None of this needs complex tokens or yields. It is just psychology: humans love checking streaks, comparing lightly, completing small goals. Games proved this works at scale.

Tomorrow: Applying This To v0

So what happens next. Tomorrow I will take these 2-3 game primitives and sketch exactly how they fit into the dashboard v0 without turning it into a game. No farming, no emissions, just coordination hooks that make tracking your "money + infra + impact" feel rewarding.

The point of these GameFi days was never to build a game. It was to understand coordination at scale, then steal the best parts for something practical like understanding your own Web3 footprint.

Resources

Day 46 project kickoff – the impact/infra dashboard we are now adding game coordination to: Day 46
Day 47 GameFi breakdown – what broke and set up today's coordination angle: Day 47
Dark Forest – on‑chain strategy game showing persistent reputation.
Parsec – guild coordination example beyond simple P2E.
Earlier identity foundations – how games naturally build Web3 resumes: On-Chain Identity

GameFi 1.0 (And Why It Broke)

Ribhav — Fri, 20 Feb 2026 08:31:34 +0000

For the past few days, I have been living in the "money + infra + impact" part of Web3 - stablecoins, regenerative finance, DePIN, identity, and then finally asking myself what I would actually build next in Day 46. Today I want to zoom out, take a quick detour into GameFi, and explain in plain language what "play-to-earn" tried to do, why so many of those games died, and what I am taking away for my own project rather than pretending I am going to build a full Web3 game.

If you want to keep up with this 60-day Web3 journey, you can follow me on X, on Medium, on Future, and you can join the Web3ForHumans Telegram community.

In the last article (Day 46), I stopped just "learning concepts" and picked a concrete project: a small impact-focused dashboard that sits at the intersection of DeFi, DePIN, and identity instead of yet another token. Before I go deeper into building that, I want to understand one big hype cycle we all watched from the sidelines: GameFi 1.0 and its promise that you could "play games and earn a salary".

What GameFi 1.0 Was Trying To Do

If you strip away all the buzzwords, GameFi 1.0 was basically this: take a game, put some NFTs and tokens on-chain, and promise that players could earn real money by playing. In practice, that usually meant you bought an NFT character or item, used it to grind some in-game activity, and earned a token that you could sell on an exchange for stablecoins or fiat.

The idea sounded powerful on paper. Games already have virtual economies, players already grind for in-game rewards, and crypto already has tokens and marketplaces, so the pitch was "what if your in-game items and points were real assets you could trade freely". On top of that, teams layered in staking, liquidity mining, and yield farming mechanics that we had already seen in DeFi, but now with cute characters and guilds instead of LP positions.

Where The Money Actually Came From

Once you apply the same DeFi lens we used for stablecoins and yield from earlier in the series, the first uncomfortable question appears very quickly: where does the money for "play-to-earn" actually come from. In many GameFi 1.0 projects, the answer was "from new players buying in", from emissions of the game token itself, or from speculative token price spikes that could not last once growth slowed down.

New players had to buy NFTs or tokens to join, which pushed up prices for a while, and early players sold to them.
The game kept printing reward tokens to keep "yields" attractive, even if there was no real underlying demand for that token outside the game loop.
When daily active users stopped growing, there were not enough fresh inflows to keep paying everyone who wanted to cash out, and the token crashed.

If you have been following the earlier days on stablecoins and DeFi, this should feel familiar. A token with emissions but no sustainable sink or real demand behaves like an unsound yield farm, and once incentives weaken, most people leave.

Why Most GameFi 1.0 Games Collapsed

The money problem was only half of the story. The other half was the games themselves. A lot of GameFi 1.0 titles were not particularly fun on their own, and the main motivation was financial: players joined to farm tokens, not because they loved the gameplay. You can see this clearly in breakdowns of the "play-to-earn" cycle and why so many titles bled out once rewards dropped (YouTube breakdown).

That created a fragile loop.

If token rewards dropped, many players left, because the game itself was not strong enough to hold them.
As players left, the economy shrank, rewards became even less attractive, and prices fell further.
Guilds and scholarship models that were set up to scale "play-to-earn" at industrial scale suddenly became unprofitable and unwound quickly.

From the outside, it looked like a textbook case of misaligned incentives. The game needed long-term, engaged players who cared about the world, but the token design attracted short-term yield farmers who cared about ROI first. Once macro conditions turned and new inflows slowed, there was nothing left to hold the system together.

What GameFi Taught Me About Incentives

The reason I am even looking at GameFi in this series is not because I want to build a play-to-earn game, but because it is a clear lesson in how not to design incentives. When you attach money to every action, you turn players into workers, and suddenly the question is not "is this fun", it is "is this worth my time compared to other income sources".

That is useful for someone like me who just decided to build an impact and infra dashboard instead of a token. For my project, I still want some "game-like" mechanics - quests, streaks, soft rewards, maybe even social leaderboards later - but I do not want people to feel like they are grinding a job just to keep up. I want the core motivation to be: "this helps me understand what my on-chain money and infra usage is doing in the real world", not "this pays me".

What I Am Taking Forward (And Leaving Behind)

So what am I actually taking from GameFi 1.0 into the rest of this 60-day journey. I am keeping the ideas that make sense for coordination and for my own project: clear goals (quests), visible progress, seasons or chapters, and light social proof. I am leaving behind unsustainable emissions, pressure to farm every day, and the promise that you can replace a salary by clicking buttons in a low-skill game forever.
Later, when I write about how I want to design "v0" and v1 of my dashboard, I will probably borrow some of those game-inspired ideas: small challenges, visible streaks, maybe non-monetary badges for people who keep tracking their impact and infra usage. But the core of the project stays closer to what we have already discussed: DeFi rails, stablecoins, regenerative finance, DePIN, identity, and one place where a beginner can see how all of it connects.

Resources

"What I'd Build Next (And Actually Start Building)" - Day 46 article: Day 46
Earlier stablecoin foundations from this series - Day 17 and Day 42: regenerative and impact-backed stablecoins and how they fit into DeFi.
DePIN overview from this series - when blockchains start paying for physical infrastructure like networks, storage, and compute.
"What is GameFi?" explainer - basic mechanics of play-to-earn and token-based game economies: What is GameFi?
GameFi 1.0 hype and collapse - breakdowns of unsustainable token emissions and shallow gameplay loops: Understanding Web3: GameFi Edition and The Old GameFi Hype And Its Collapse

If something here feels off, incomplete, or sparks an idea, reply, quote it, or write your own version.

What I'd Build Next (And Actually Start Building)

Ribhav — Thu, 19 Feb 2026 06:15:29 +0000

For the past 45 days I have been learning Web3 concepts one per day, writing about them in public, and building a mental map of how everything fits together. I have covered blockchains, DeFi, stablecoins, zero knowledge proofs, identity, storage, DePIN, regenerative finance, and more. Around Day 46, I am starting to feel like I have enough pieces in my head to stop just learning and start actually building something. Not a full production app, not a token launch, just a small v0 project that ties together a few of the ideas I have been circling.

This is Day 46 of my 60 Days of Web3 experiment. If you are new here, you can read the full journey on Medium, checkout Ribhav on Future, and hang out with us in the Web3ForHumans Telegram at Web3ForHumans. Today's post is less "here is what I learned" and more "here is what I am going to build, and I will document it for the rest of this series."

The three big threads I keep seeing

Before I explain what I want to build, let me do a quick recap of the three main themes that have shown up over and over in this journey so far.

Money and stablecoins evolving. We started with basic stablecoins in Day 17, moved to regenerative and impact backed stablecoins in Day 42, and yesterday in Day 44 we looked at how DeFi is starting to fund real world infrastructure. The story here is that money in Web3 is not just about holding value, it is about where that value flows and what it funds while it sits idle.

Infrastructure and data becoming modular. Early on we covered things like nodes, RPCs, indexers like The Graph, and storage layers like IPFS and Arweave. Then in Day 43 we looked at DePIN, where physical infrastructure gets coordinated by tokens. The story here is that Web3 is not just one blockchain, it is a stack of composable services that you can plug together to build apps without owning all the infrastructure yourself.

Trust and identity sitting between everything. In yesterday's Day 45 piece, I argued that identity is the glue layer. It is what lets DeFi do credit and reputation, what lets DePIN filter spam, what lets regenerative projects verify impact, and what lets protocols stay open but still comply with regulations. We also covered zero knowledge proofs earlier, which let you prove things about your identity or credentials without revealing the raw data.

Those three threads keep intersecting. Money flows into infrastructure. Infrastructure produces data. Identity and reputation shape who gets access and trust. And all of it lives on blockchains that are increasingly modular, composable, and programmable.

What I want to build: a Web3 journey and impact dashboard

Here is the idea I keep coming back to. Right now, if you are active in Web3, your identity and activity are scattered everywhere. You have tokens in a wallet, you have contributed to a DAO, you have written articles or code, you have interacted with DeFi protocols, maybe you have run a DePIN node or bought impact backed assets. But there is no clean way to see all of that in one place, and there is no way to surface the story behind it.

I want to build a Web3 journey and impact dashboard that does a few simple things. You connect your wallet or ENS name, and it pulls in:

Your on chain activity. What protocols have you used, what tokens do you hold, what NFTs or credentials do you own, what DAOs or communities are you part of. This is basically a more readable, narrative version of what Etherscan or block explorers already show, but with context and storytelling instead of raw transaction logs.

Your impact footprint. If you hold regenerative stablecoins like AZUSD, if you have staked in DePIN networks, if you have contributed to carbon credit projects or other ReFi initiatives, the dashboard surfaces that and shows what your holdings are quietly funding in the real world. It answers the question from Day 42 and Day 44: "what is my balance actually funding while I sleep?"

Your builder and learning journey. If you have published articles, contributed to open source repos, earned credentials or attestations, or participated in hackathons or grants, the dashboard pulls that in too. This is the "Web3 resume" angle we talked about in Day 45. It is proof of work and proof of learning, not just proof of holdings.

The goal is not to build another portfolio tracker or another wallet UI. The goal is to build something that tells the story of your Web3 presence. Who are you, what are you building or learning, what impact are you having, and how is all of that connected?

Why this project fits the 60 day arc

There are a few reasons this project makes sense for me right now, beyond just "it sounds cool."

It forces me to integrate everything I have learned so far. To build this, I need to interact with on chain data via indexers like The Graph or RPC calls. I need to handle wallet connections, ENS resolution, and identity. I need to pull metadata from NFTs, credentials, and attestations. I need to surface DeFi positions, DePIN activity, and regenerative assets. And I need to think about privacy, since not everyone wants their full activity public. That covers most of the technical concepts from the first 45 days.

It also aligns with my own goals. I am building this 60 day journey in public partly to learn, partly to build a portfolio, and partly to show what I can do as a technical writer and builder. A dashboard that visualizes my own journey is both a useful tool for me and a proof of concept that I can ship something real, not just write about theory.

And it solves a real problem, even if the audience is small at first. A lot of people in Web3 are builders, contributors, or learners who want to show their work but do not have a clean way to do it. GitHub profiles work for code, Medium works for writing, but neither captures on chain activity, impact, or credentials in a coherent way. This dashboard could be the start of something that bridges those gaps.

What v0 will actually do (narrow scope, real timeline)

I am not trying to build a unicorn startup or a VC funded product. I am trying to ship a working v0 by the end of this 60 day series, which means I have about two weeks of focused build time after today. So the scope needs to be tight and realistic.

Here is what v0 will do. You land on a simple web page, connect your wallet via MetaMask or WalletConnect, and the app pulls in a few key data points. It shows your ENS name if you have one, or your wallet address if you do not. It lists a few protocols you have interacted with, based on transaction history from an indexer or block explorer API. It shows any NFTs or soulbound tokens you hold that represent credentials, memberships, or proof of participation. And if you hold certain tokens like AZUSD or staked DePIN tokens, it shows a small explainer of what those assets represent in terms of real world impact or infrastructure.

The output is a single page dashboard, clean and readable, with a few sections. Activity summary. Impact footprint. Credentials and contributions. And maybe a small narrative blurb at the top that you can customize, something like "I am learning Web3 in public, here is my journey so far."

That is it. No wallet for sending transactions, no live portfolio tracking with price charts, no social features or feeds. Just a static or lightly dynamic snapshot of your Web3 presence, with the option to refresh the data or update the wallet address. Simple, focused, shippable.

The tech stack I am leaning toward

I have not locked everything down yet, but here is the rough stack I am thinking about for v0. I will use a simple React or Next.js front end, since I already know enough JavaScript to get by and there are good Web3 libraries for wallet connection and on chain queries. For wallet connection, I will use something like RainbowKit or wagmi, which are clean, well documented, and handle MetaMask, WalletConnect, and other options out of the box.

For on chain data, I will start with a mix of RPC calls via ethers.js or viem for simple queries, and The Graph for more structured indexing if I need it. We covered The Graph earlier in the series, and I know it is overkill for a v0, but if I want to query things like "all DAOs this wallet has voted in" or "all protocols this wallet has interacted with," a subgraph could save me a lot of manual parsing.

For ENS resolution, I will use the ENS JavaScript library to turn wallet addresses into human readable names, and maybe pull the avatar and other metadata if it is set. For NFTs and soulbound tokens, I will query metadata via standard ERC721 or ERC1155 calls, and filter for specific contract addresses if I want to highlight certain credentials.

For the impact and DePIN layer, I will hardcode a small list of known tokens like AZUSD, Helium, Hivemapper, and a few others, and display custom descriptions or links when those tokens show up in a wallet. This is not scalable long term, but for v0 it is fine. The point is to show the pattern, not to index every single impact token in the ecosystem.

I will deploy the front end on Vercel or a similar static host, keep everything client side for now to avoid needing a backend or database, and maybe add a simple cache layer later if API rate limits become a problem. The whole thing should be lightweight, fast, and easy to iterate on.

What comes after v0 (but not in scope yet)

I already have ideas for v1 and v2 features, but I am intentionally not building them yet. Scope creep kills side projects, and I want to ship something working before I start adding bells and whistles. That said, here are a few things I would love to add later if v0 works and people actually use it.

Multi chain support. Right now I am focused on Ethereum mainnet and maybe one or two L2s like Arbitrum or Base. But a lot of people are active on Solana, Polygon, or other chains, and their activity is just as valid. Adding multi chain indexing would make the dashboard more useful, but it is also a lot more complexity.

Privacy controls and selective reveal. Some people might want to show only their credentials and contributions, not their full wallet holdings or transaction history. Zero knowledge proofs could let you prove "I have interacted with these protocols" or "I hold impact tokens worth at least X" without revealing exact amounts or addresses. That is a stretch goal, but it ties back to the ZK concepts we covered earlier.

Social and DAO integrations. If the dashboard could pull in your GitHub contributions, Medium articles, Farcaster or Lens posts, or DAO participation from platforms like Snapshot, it would give a much fuller picture of your Web3 presence. But that means dealing with multiple APIs, authentication flows, and data formats, so I am saving it for later.

Customizable narratives and templates. Right now I am thinking of one default layout, but people might want different layouts depending on whether they are applying for a grant, a job, or just showing off to friends. Templates or themes could make the dashboard more flexible, but again, that is v2 or v3 thinking.

The rest of the 60 day series will include build logs

Starting tomorrow, I am going to split my daily posts between continuing to explore new Web3 concepts and documenting progress on this project. Some days will be "here is what I learned about X," and other days will be "here is what I built, what worked, what broke, and what I am trying next."

I am treating this as a real build in public experiment, not just a thought exercise. That means I will share code snippets, design decisions, mistakes, and honest reflections on what is hard and what is easier than expected. If you are learning Web3 and want to see what building something real actually looks like, the next two weeks should be useful.

And if you want to follow along, contribute ideas, or even fork the project and build your own version, I will drop links to the repo and live demo as soon as I have something worth sharing. For now, consider this Day 46 post the kick off. The project has a name, a scope, a rough tech stack, and a timeline. Now it is time to actually build it.

If you are on a similar Web3 learning path

This note is part of my public 60 Days of Web3 journey, one concept per day, explained in human terms, with all the confusion and course corrections left in. You can read the full journey on Medium, follow Ribhav on Future, and join the community on Telegram at Web3ForHumans.

If something here feels off, incomplete, or sparks an idea, reply, quote it, or write your own version. And if you are building something similar or have ideas for what this dashboard should do, I would genuinely love to hear from you. I am learning and building in public so you do not have to do it alone.