Future: Ribhav

I Started This Not Knowing What a Wallet Was. Here's Where I'm Going Next

Ribhav — Fri, 10 Apr 2026 05:00:08 +0000

Sixty days ago, I didn’t know the difference between a hot wallet and a cold wallet.

Now, somewhere around Day 60 of writing every single day, that feels like a completely different starting point.

I knew Bitcoin existed. I knew NFTs had created some kind of cultural moment. I had a vague sense that “blockchain” meant something important.

That was it.

If you want to keep up with this journey as I continue building and learning in Web3, you can follow me on X, on Medium, on Future, and join the Web3ForHumans Telegram community.

What 60 days actually is

Sixty days is not enough to become an expert.

I can explain how zero-knowledge proofs work conceptually, but I cannot implement one. I understand why EigenLayer matters for the security economy, but I wouldn’t audit an AVS. I know how gas optimization works in theory, but I wouldn’t deploy a high-stakes contract without a review.

That’s important to say clearly.

Because what 60 days actually gives you is something else.

It removes the fear of terminology. It makes whitepapers readable. It lets you follow conversations without feeling lost. It gives you enough context to form opinions.

That shift from not knowing what you don’t know to knowing exactly where the gaps are is bigger than it sounds.

The articles that surprised me

The article I thought would perform best was the DeFi one. It had a clear topic, obvious demand, and simple framing. It got 69 views.

The one that actually worked was the storage piece, Where Blockchain Data Actually Lives, which I wrote quickly because I was behind schedule and framed as a “war” without thinking too much about it. It ended up at 306 views.

Over 59 days, I learned Web3. At the same time, I learned that I’m not great at predicting what people want to read, and that consistency matters more than trying to get one article right.

The community

Web3ForHumans started as a Telegram group I created so I could share updates without spamming people I knew.

It now has 45+ members.

People share articles, ask questions, and occasionally point out where I’m wrong. I didn’t grow it intentionally. I didn’t run any campaigns. I just wrote every day, mentioned it, and let it grow slowly.

That’s probably the most honest signal I have. People don’t join a Telegram group about Web3 unless something is working.

What I’m carrying forward

The work I did with Bitquery showed me something this series didn’t.

Writing for developers and writing for beginners are completely different skills. The structure, the depth, and the expectations all change. Being able to do both is something I didn’t expect to gain from this.

The series itself taught me something simpler.

Consistency compounds.

The views on Day 5 didn’t matter. The views on Day 35 didn’t come from one article. They came from showing up repeatedly.

A single article doesn’t build anything. A body of work does.

What comes next

The series ends here.

The writing doesn’t.

I’ll keep posting on Medium and Forem. Same tone, same style, just going deeper. Some pieces will be technical, some will be about data, and some will be about things I’m building or trying to understand.

Substack is something I’m taking more seriously now. One piece a week, more reflective, more long-form, and less structured around explaining a single concept.

The Web3ForHumans Telegram stays open. That’s where the conversations are happening.

And the dashboard project I mentioned earlier in the series is still being built. Slowly, publicly, and not in a straight line.

If you’re about to start Day 1

The hardest part isn’t the terminology. It’s the first couple of weeks where everything feels connected and nothing makes sense yet.

Push through that.

By Day 10, things start to form. By Day 30, you start having opinions.

After that, it becomes less about learning everything and more about choosing what you want to go deeper into.

Follow your curiosity instead of trying to go in order. And write, even if it’s not public, because writing forces you to see what you don’t understand.

I started this not knowing what a wallet was.

Now I’m writing about the major pieces of Web3 and the infrastructure behind it.

That’s not a transformation story.

It’s just a data point.

And the only reason that data point exists is because I showed up for more than 60 days.

Thank you

If you’ve read even one article from this series, thank you.

If you’ve been here since the early days, when the views were in single digits and the explanations were still rough, I appreciate it even more.

And if you’ve ever messaged, commented, or pointed out something I got wrong, that probably helped more than you think.

If you want to keep following what comes next, you can follow me on X, on Medium, on Future, and join the Web3ForHumans Telegram community.

58 Articles, 3K Views, $0 Earned: What the Data Actually Taught Me

Ribhav — Tue, 07 Apr 2026 07:41:47 +0000

I wrote 58 articles about Web3 in 60 days, and somewhere around Day 59, the number people usually ask about first is the one that looks the worst.

I made exactly $0.

No hidden monetization, no affiliate links, no “this will convert later” angle. Just around 3,000 views on Medium, 4,600 on Forem, and somewhere above 7,500 total across everything.

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

That’s the outcome.

And honestly, it’s not the part that bothers me.

The actual stats

On Medium, the numbers are fairly straightforward. Around 3,000 total views, 628 reads, and 49 followers gained. Earnings stayed at zero the entire time. March was the strongest month, with about 8,500 presentations and 583 views.

The best-performing article was Where Blockchain Data Actually Lives from Day 33 with 306 views. The weakest one dropped to 7.

On Future (Forem), the numbers look different. 4,630 total views, 39 reactions, and 24 comments. Not huge numbers, but noticeably more interaction.

Across both platforms, the combined views cross roughly 7,500. The Telegram group reached around 40 members. LinkedIn impressions exist somewhere in the background, but I didn’t track them properly, which I only realized later.

What the data actually shows

If I’m being honest, I was wrong about what would work.

Day 33, the IPFS storage article, ended up doing almost three times better than everything else. I didn’t plan it that way, and I didn’t treat it differently while writing. The framing just worked.

At the same time, some of the articles I spent the most time on barely moved. Day 41 had around 1,000 presentations and only 19 views. Day 42 had 1,400 presentations and just 7.

That gap between impressions and actual clicks is where most of the learning sits. It forces you to realize that writing quality alone doesn’t determine performance. If people don’t click, the article effectively doesn’t exist.

The only metric that really captures that is the ratio between presentations and views. High reach with low clicks almost always points to a title problem.

Another pattern becomes obvious when you look across the series instead of individual articles.

Most of what I wrote was framed for discovery. Personal tone, beginner-friendly explanations, and titles that made sense if someone was already following along.

That works when you have an audience.

It doesn’t work for search.

The articles that performed better happened to match what people were already looking for. IPFS storage. ZK proofs. Specific topics with clear intent.

I didn’t approach this deliberately at the start, and it shows.

The platform difference was also more noticeable than I expected.

Medium felt like publishing into a feed. You post, and then it sits there.

Forem felt more like a conversation. The engagement per article was higher, and the comments were actually useful. People pointed out gaps, asked follow-up questions, and occasionally pushed back in a way that made the explanation better.

That feedback loop ended up being more valuable than the view count.

The structure of the series itself mattered more than I thought it would.

There were multiple days where the numbers were low enough to question whether continuing made sense. Single-digit views, almost no interaction, nothing that suggested anything was working yet.

If this wasn’t a fixed 60-day series, I probably would have stopped somewhere around there.

The format removed that decision completely. It forced consistency, and that ended up being the only reason this body of work exists.

The $0 number is technically true, but it’s also incomplete.

Because the actual return didn’t come from Medium. It came from the work being visible.

This series led to a Bitquery freelance writing role, an Outreach internship with BeetleX, and a portfolio that proves I can show up consistently and write about technical topics.

Day 51 touched on some of this, but seeing it alongside the numbers makes it clearer.

The ROI isn’t in the platform. It’s in the proof of work.

What I got wrong

The most obvious mistake was ignoring Substack.

After Day 3, I stopped posting there completely. Which means more than 50 articles never contributed to building an email list. In hindsight, that’s time that didn’t compound.

I also treated every article the same.

The time and effort were almost identical across all pieces, regardless of the idea. Some topics clearly deserved more attention, especially the ones with higher search potential or stronger angles.

Giving everything equal weight diluted the impact of the best ideas.

Titles were another gap that only became obvious later.

I wrote titles that felt natural, not titles designed to get clicked. The difference is subtle while writing, but obvious in performance. The articles that worked had sharper hooks or more specific promises. The rest were easy to ignore.

And I didn’t track things properly.

I know the overall numbers for Forem, but I don’t know which articles drove them. That makes it harder to learn from what worked. Going forward, that kind of visibility is non-negotiable.

What surprised me

The most useful feedback didn’t come from the numbers.

It came from people.

Comments on Forem pushed back on explanations, pointed out small inaccuracies, and highlighted where things were unclear. That feedback improved the writing in a way that metrics couldn’t.

The Telegram group growing to around 40 members without any real effort was another signal I didn’t expect.

There was no strategy behind it. Just consistent writing and a link at the end of each article. The growth is small, but steady, and it suggests that something is working beneath the surface.

And the writing itself improved.

Not dramatically, but enough to notice. The structure is cleaner, the explanations are tighter, and it’s easier to see what should be removed.

That didn’t come from studying writing separately. It came from doing it every day.

One thing I’d say if you’re starting

The first few weeks won’t tell you much.

The numbers are too small, and the signal isn’t clear yet. Trying to optimize too early usually leads to the wrong conclusions.

What matters in that phase is just continuing.

After that, patterns start to appear. And when they do, the most useful metric is still the simplest one.

How many people saw the article, and how many chose to click.

That ratio tells you more than anything else.

One more tomorrow.

And that one feels less like an ending and more like a direction I’m still figuring out.

If you want to keep following this journey, you can follow me on X, on Medium, on Future, and join the Web3ForHumans Telegram community.

Restaking and the Security Economy: How EigenLayer Changed Everything

Ribhav — Mon, 06 Apr 2026 12:59:17 +0000

Here's a thought experiment.

Ethereum has spent years accumulating billions of dollars in staked ETH, with validators putting up collateral to secure the network. That security is expensive to build. It took years. And once a validator's ETH is staked to secure Ethereum, it just sits there, doing one job.

What if it could do two?

That's the question EigenLayer answered. And the answer is reshaping how crypto networks get built. But to understand why it matters, we need to start with how Ethereum security actually works.

Welcome to Day 58 of 60-Days in Web3 series. 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 series on X, on Medium, on Future, and you can join the Web3ForHumans Telegram community to discuss these topics in plain language.

How Ethereum security works

When you stake ETH on Ethereum, you're putting up collateral and running a validator node. Your job is to honestly process and confirm transactions. If you behave honestly, you earn rewards. If you try to cheat, your stake gets slashed, meaning you lose a portion of it as punishment.

This slashing mechanism is what makes the network trustworthy. Attackers would need to control 33% of staked ETH to meaningfully disrupt the network. At current staking levels, that's tens of billions of dollars of exposure. It's not worth it.

That security is Ethereum's moat. Building it took years of validator participation and accumulated trust.

Now what if a new protocol, a data availability layer, an oracle network, a bridge, wanted that same level of security?

Normally, they'd have to build it from scratch. Attract stakers. Issue their own token. Build their own slashing conditions. Hope validators show up.

EigenLayer said: what if they didn't have to?

What EigenLayer actually is

EigenLayer is a protocol that lets Ethereum validators opt in to securing additional services, called Actively Validated Services (AVSes), using their already-staked ETH.

The staker still secures Ethereum. But they also, voluntarily, extend their security to another network or service. In exchange, they earn additional yield from that AVS.

The AVS gets Ethereum-grade security without having to bootstrap its own validator set. The staker earns more. The broader ecosystem gets more secure infrastructure, faster.

This concept is called restaking. And it comes in two forms.

The mechanics

Native restaking. If you're running a full Ethereum validator, you can point your withdrawal credentials to EigenLayer's contracts. Your staked ETH now simultaneously secures Ethereum and any AVSes you've opted into.

Liquid restaking. If you hold staked ETH derivatives like stETH from Lido or rETH from Rocket Pool, you can deposit those into EigenLayer directly. You don't need to run your own validator.

Both approaches let validators and token holders extend their security work to additional services and get paid for it.

The services on the receiving end of that security are what EigenLayer calls AVSes, and that's where it gets interesting.

What AVSes are and why they need this

An AVS is any service that needs decentralized validation. Things like:

Data availability layers, services that ensure transaction data is accessible and verifiable, essential for rollups. Building trust for these from scratch is slow and expensive.
Decentralized oracles, networks that need honest nodes reporting real-world data to blockchains. The more economic weight behind a node, the more trustworthy the data.
Cross-chain bridges, which have historically been among the most exploited pieces of Web3 infrastructure. Restaked security adds a meaningful economic deterrent.
Sequencer networks, since L2s often rely on a single centralized sequencer to order transactions. Decentralized sequencer networks need validators, and restaking gives them a path to get them.

EigenLayer's first major AVS is EigenDA, a data availability layer that already serves several major rollups.

Once restaking started gaining traction, a new category of protocols emerged to sit on top of it.

Liquid restaking tokens (LRTs), the next layer

As restaking grew, a new category emerged: liquid restaking protocols.

The idea is straightforward. You restake your ETH through EigenLayer, but your capital is locked and illiquid. Liquid restaking protocols like Ether.fi, Renzo, Kelp DAO, and Puffer Finance take your ETH, restake it on your behalf across AVSes, and give you a liquid token, an LRT, in return.

That LRT can then be used in DeFi. Lend it, provide liquidity with it, use it as collateral.

Your ETH is earning Ethereum staking rewards, EigenLayer restaking rewards, and potentially DeFi yield, all simultaneously. The composability is powerful.

It's also where the risk starts to build up.

The risks, and they're real

Slashing cascades. If a validator behaves maliciously on an AVS, or if an AVS has a bug in its slashing conditions, the validator's restaked ETH could be slashed across multiple services simultaneously. The exposure is compounded, not isolated.

AVS quality variance. Not all AVSes are equal. Opting into a poorly audited AVS is opting into risk. Stakers have to evaluate each service individually, which most retail participants are not equipped to do.

Correlated risk concentration. If a large liquid restaking protocol controls a huge share of restaked ETH and encounters a problem, it affects every AVS that protocol's validators were securing. The interconnection creates systemic risk.

Points farming distortion. During EigenLayer's launch period, protocols offered points, pre-token incentives, to attract restakers. This created massive capital flows chasing points rather than evaluating risk. Misaligned incentives.

The social consensus problem. Vitalik Buterin himself wrote about this: the concern that EigenLayer could become so large that social pressure would emerge to bail out AVSes that fail, effectively turning Ethereum's social consensus into collateral for third-party services. The community is watching this closely.

What's happened since launch

EigenLayer opened restaking to the public in 2024. By early 2025, it had accumulated tens of billions in restaked ETH, making it one of the largest protocols in DeFi by TVL in a remarkably short period.

The liquid restaking token market exploded alongside it. Ether.fi became one of the fastest-growing DeFi protocols ever. Most major L2s announced or completed integration with EigenDA.

EIGEN, EigenLayer's native token, launched with a novel design: it's meant specifically for intersubjective tasks, slashing conditions that can't be programmatically verified on-chain but require human judgment to resolve. That's another piece of the emerging security economy worth watching.

The bigger picture

Restaking represents a shift from seeing Ethereum as a single, isolated network to seeing it as a security marketplace, one where economic weight can be directed at different services, composable and programmable.

That's a genuinely different idea of what a blockchain is. Not a standalone ledger, but the foundation layer of a security economy.

Every new protocol that opts into EigenLayer instead of bootstrapping its own validator set is a vote for this model. And given how fast the TVL and AVS count grew, a lot of protocols are casting that vote.

Whether the risk compounds faster than the ecosystem can manage it is the open question. The answer will play out over the next few years in real time, in the most adversarial financial environment in the world.

Tomorrow, we'll look at something different: the meta-story of what actually happened across 58 days of writing about Web3, the patterns, the surprises, and what the data says about this space.

Resources to go deeper

The EigenLayer whitepaper is the primary reference for how restaking and AVSes work at a protocol level.

The EigenLayer docs cover native restaking, liquid restaking, and the AVS operator framework in practical detail.

For a critical perspective, Vitalik Buterin's post Don't overload Ethereum's consensus lays out the social consensus risk clearly and is essential reading alongside the bullish case.

EigenDA's documentation explains how the first major AVS works and which rollups are already using it.

For the liquid restaking layer, Ether.fi, Renzo, and Kelp DAO each have docs that explain how LRTs work in practice, and comparing them is a useful exercise.

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 series on X, on Medium, on Future, and you can join the Web3ForHumans Telegram community to discuss these topics in plain language.

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