DEV Community: Dapping

Web3 developers moving to AI: what the 2026 data shows, and why we widened Dapping

kishan 🐙 — Mon, 09 Nov 2026 16:24:47 +0000

Web3 developers are leaving crypto, and the work for those who stay is moving toward AI. Electric Capital counted 25,623 monthly active crypto developers in late October 2026, down 36% in a year; nobody has measured where the leavers went. What can be measured is what the stayers are asked to build: at ETHGlobal's in-person hackathons, sponsors asking for AI or agent work held at about five per event from 2025 to 2026 while every other kind of sponsor fell from about 21 per event to 5, so agent tracks went from 18% of sponsors to 53%. The Web3 skill that carries over is adversarial engineering, and the evidence a reviewer can check is the same in both fields.

Facts and counts checked on 5 November 2026.

Is the crypto developer pool shrinking?

Yes. Electric Capital's developer dashboard put monthly active crypto developers at 25,623 in the week of 28 October 2026, down 36% in a year and well below a peak of 45,931 in June 2025. The experienced core is shrinking too: developers with two or more years in crypto fell 25% over the year. They are still 11% above three years ago, likely because developers who arrived two and three years ago have now been around long enough to count as established.

Some of those who leave take their specialty with them. Sam Blackshear, co-founder and CTO of Mysten Labs, the company behind Sui, announced in August 2026 that he was joining Anthropic to do defensive security research. His turning point, he said at a security panel he hosted in April, was using Claude to port a static analysis tool he had built at Facebook over to Move, the language Sui contracts are written in.

How many Web3 hackathon sponsors now ask for AI agents?

At ETHGlobal's five in-person events in 2026, 29 of 55 sponsors put AI or agents in a track title, from a third of sponsors in Mumbai to 10 of 16 in New York. Sponsors fund the integrations they want built, so a prize page is a fair read of what Web3 companies want from developers, and the same count on the 2025 pages gives the baseline.

AI and agent tracks at ETHGlobal in-person events, 2025 and 2026

Event	Dates	Sponsors	Sponsors with an AI or agent track title	One such track
Taipei	4 to 6 Apr 2025	18	3	Celo, "Best AI Agent on Celo"
Prague	30 May to 1 Jun 2025	14	1	Hedera, "AI, Agents & Hedera Services"
Cannes	4 to 6 Jul 2025	28	4	Artificial Superintelligence Alliance, "Innovator's Edge: for most impactful and useful AI Agent"
New York	15 to 17 Aug 2025	27	8	OpenSea, "Best AI Experience with OpenSea MCP"
New Delhi	26 to 28 Sep 2025	21	4	Polygon, "Best Use of x402 Agentic Payments on Polygon"
Buenos Aires	21 to 23 Nov 2025	46	8	Circle, "Best AI Agent Wallet with Circle Wallets"
Cannes	3 to 5 Apr 2026	12	6	Ledger, "AI Agents x Ledger"
New York	12 to 14 Jun 2026	16	10	Google Cloud, "Best On-Chain Agent Economy Application"
Lisbon	24 to 26 Jul 2026	8	5	The Graph, "Best AI Tooling for The Graph"
Tokyo	25 to 27 Sep 2026	7	4	Curvegrid, "Best AI Agent Project"
Mumbai	5 to 7 Nov 2026	12	4	0G, "Physical AI: Agents with a Body"

Compiled from the prize page of each in-person hackathon on ETHGlobal's event calendar on 5 November 2026: 28 of 154 sponsors (18%) in 2025 against 29 of 55 (53%) in 2026. A sponsor counts when at least one track title names AI, an AI agent, "agentic", an LLM or an agent product such as World's AgentKit; ETHGlobal's own prizes and the finalist perks are left out, and without World's AgentKit tracks New York 2026 would be 9 of 16. Online events, including the agent-only Agentic Ethereum (2025) and Open Agents (2026), are excluded, and Mumbai was still running on the day of the count.

Most of that jump is sponsors leaving, not sponsors converting. Per event, AI and agent sponsors went from about 4.7 to 5.8, while everyone else went from about 21 to 5. Agent work is the part of the sponsor budget that survived the downturn, and it is specific: Web3 companies want agents to use their rails (wallets, payment flows, name services).

Several finalists took that brief seriously. By our reading of their project pages, six of the ten ETHGlobal Cannes 2026 finalists were agent projects (ENShell, DIVE, Corpus, ALMA, maki and npmguard), and half of those were built around limiting what the agent can do. ENShell runs every action "through a four-layer security pipeline before a single wei moves"; ALMA enforces an onchain whitelist of allowed calls with a revocable 30-day key; maki keeps key material in hardware, and its page says the model "interprets intent but never moves funds".

That is the same instinct Vitalik Buterin set out in April 2026 in his post on running LLMs securely: require human plus LLM 2-of-2 confirmation for risky actions, and allow a daily limit of about $100 to bypass the human. Smart-contract developers have spent years assuming every input is hostile and every key is a target, and an agent that holds a wallet needs exactly that habit.

The standards those tracks named point the same way. ERC-8004, a draft Ethereum standard from August 2025, gives agents identity, reputation and validation registries, and x402, an open payment standard documented by Coinbase's developer platform, lets a service charge a request whether "the buyer is a human or a machine". Google Cloud's 2026 New York track asked for both.

Is AI work a Web3 thing or an everyone thing?

An everyone thing. A count of the 678 top-level posts in Hacker News' October 2026 "Who wants to be hired?" thread, using a broad keyword list, finds that 461 of them, 68%, mention AI. Of the 34 who mention Web3, 26 do (76%), a little above the thread's rate. Web3 developers are doing what every developer on the market now does, and only about 1 in 20 job-seekers mention Web3 at all. A post counts even when it says "no AI work", so this measures what people put in front of an employer, not what they can do.

The job market shows the same spread. In the Indeed Hiring Lab's AI tracker data, 7.34% of US job postings mentioned AI at the end of September 2026, up from 3.71% a year earlier.

Are AI tools turning specialists into generalists?

They widen what one builder can attempt, and the review, testing and deployment work does not shrink with it. No dataset yet measures specialists becoming generalists, so the answer is pieced together from studies of parts of it.

METR's 2025 randomized study found 16 experienced open-source developers took 19% longer with AI tools on their own repositories, while expecting to be 24% faster. Its February 2026 update, with newer tools and 57 developers, estimates a speedup but calls its own signal unreliable. For smart contracts, Diana Levytska of AstraKode wrote in April 2026 that "generating code was never the real bottleneck" (her post on where the bottleneck moved): the bottleneck was testing and safe deployment.

The tools have adjusted to that bottleneck. Since February 2026, BuidlGuidl's Scaffold-ETH 2 has shipped an AGENTS.md file that coding agents read for project context, plus skill files, from ERC-20 to Solidity security, that an agent loads before it writes code.

What do reviewers trust when everyone lists AI?

Work that someone other than the builder stands behind, because the usual signals stopped working.

Take-homes went first. Tristan Hume, a lead on Anthropic's performance optimization team, wrote in January 2026 that on the company's own take-home, "Claude Opus 4 outperformed most human applicants" within the time limit (Anthropic's post on AI-resistant evaluations). Its replacement simulates novel work, and judgment about how to invest in tooling is part of the signal. In a Karat survey of 400 engineering leaders published the same month, 71% said AI makes technical skills harder to assess.

Skill badges answer a narrower question. LinkedIn's verified AI skills, launched on 26 January 2026, are issued by tool vendors such as Replit and Lovable based on how you use their product. That shows you used the tool, not what you built with the tool or whether it held up.

Simon Willison's December 2025 standard for code review is the useful frame: "Your job is to deliver code you have proven to work" (his post on code proven to work). Stretch it from one pull request to a career and the evidence that a stranger in either field can check looks like this:

a pull request a maintainer reviewed and merged in a repository you don't control, where the thread shows a real change
a placement the organizer names on its own results page (a finalist spot or a top-three track finish, not a share of a pool prize), with your team
a role your employer confirms, rather than one you typed
a finding a third party paid for or ranked: an audit-contest result on Code4rena, Sherlock or Cantina, a bounty paid on Immunefi, or an eval an outside party ran

A demo with tests is still worth having, but it is your claim until someone else runs it.

These live in different places, and a reviewer rarely chases more than one. A Dapping profile puts the projects you shipped, the roles verified companies confirmed and the wins organizers recorded on one proof page, so a reviewer sees what you built and who signed off on it in one link.

Start with the agent work you would most want a reviewer to see. If it has none of the four behind it yet, the cheapest one to get this month is usually a maintainer's review on an upstream fix, or an entry in the next agent track at a hackathon that publishes its results.

Why we widened Dapping to builders in Web3 and AI

In October 2026 we widened our line from Web3 to Web3 and AI: Dapping is now the verified professional graph for builders in Web3 and AI. We made the call in mid-October on earlier readings of the same sources, Electric Capital's decline, the agent tracks at ETHGlobal New York and how developers describe themselves when they look for work. The fuller counts compiled for this piece point the same way. A line that named half of a builder's work was describing less of it every month.

A verified professional graph is a network of people, companies and work in which every claim shows whether someone else stands behind it. Nothing in that depends on a chain. When a company Dapping has verified confirms a role, the profile marks it, so a reviewer can see which roles are backed. The methodology page explains how to read each kind of proof.

What changed is what sits around builders. AI companies now have their own categories (AI x Crypto, AI Applications, AI Infrastructure and AI Research), and their jobs, hackathons and programs are being added the way the Web3 catalog was built. An AI project you add sits on the same proof page as your Web3 work and your confirmed roles.

Whatever you call the field on your next application, a reviewer will ask the same question of every line on it: who else stands behind this? Answer it before they ask: list the agent work you most want reviewed as a Project with your teammates credited, next to the roles that already have someone behind them.

Frequently asked questions

Should I call myself a Web3 developer or an AI engineer?

Name the work instead of the field. When about two-thirds of job-seekers on Hacker News mention AI, the word separates nobody, and "Web3 developer" undersells an engineer who builds agent wallets. A headline such as "smart-contract and agent engineer, built a spend-limit layer for agent wallets" tells a reviewer both stacks at once, and the link under it should open the backed version of that claim.

What counts as proof for a pseudonymous builder?

The same outside parties, tied to the handle instead of a legal name. Audit-contest results under a consistent handle, organizer-named hackathon placements, bounties paid to the handle's address and merged pull requests all attach to a pseudonym. A contract deployed from an ENS-named address shows the handle shipped something; it becomes proof once an auditor or an integrating protocol stands behind it. The one item that usually needs a real identity is an employer-confirmed role.

Are Electric Capital's and Artemis's developer counts comparable?

No. Electric Capital counts monthly active developers who author original code in crypto repositories. Artemis, as reported by CoinDesk in March 2026, counted about 4,600 active developers, down 56%. Both point down. Quote each with its own method, and never credit the Artemis decline to Electric Capital.

Web3 verifies everything except people

kishan 🐙 — Mon, 21 Sep 2026 21:29:19 +0000

I have spent a lot of time around hackathons, and the same thing happens at every one.

A team ships something real in seventy-two hours. It works on Sunday. They demo it, the room is genuinely excited, and then everyone flies home.

By Wednesday the group chat is quiet. A month later the repo has not moved and the demo link is dead. Six months after that, one of those builders is applying for a grant or a role, and there is nothing left to point at. The work happened. The proof did not survive the week.

I saw the same failure from the other side of the table. Reviewing grant applications, past a certain number, I got faster. Not better. Faster. There were too many, they read alike, and I had no reliable way to separate a builder who had shipped for three years from someone who had written a very good paragraph. I know I passed on people I should not have. I still think about that.

For a long time I thought the problem was simply that proof was scattered. DAO contributions nobody could confirm. Reputation trapped in a Discord that went quiet. Builders I had mentored who could
ship a protocol and could not assemble a page that made a stranger believe it.

That diagnosis was right and too small.

What actually broke

The heuristic I was leaning on, without ever naming it, was writing quality. It worked because a compelling account of a technical contribution used to take understanding to produce. You could not
easily fake the texture of having done the thing.

That correlation is gone. Anyone can now produce a paragraph that reads like someone who did the work, and no filter further down the funnel recovers what that one used to catch.

So the pile got bigger and the signal inside it got weaker at the same time.

Then the other side of the conversation stopped being safe. Fake recruiter personas at crypto companies now deliver malware through coding assessments, hunting for wallet files and session
tokens. Microsoft documented one such campaign in March 2026. Separately, and widely documented, the traffic runs the other way: operators place workers inside legitimate companies using stolen identities.

Put those together and the shape of the problem changes. A builder receiving a message from a company, and a company receiving an application from a builder, now face the same problem from opposite ends. Neither can cheaply confirm the other is real. Both are being targeted by people who understand that.

The value of a verified professional identity went up. The cost of faking one went down.

Which leaves an industry built on not having to take anyone's word for it taking everyone's word for it. We verify transactions by default, contracts by convention, token supply by design. Professional identity is still self-reported.

The idea

Nothing on a profile should count for much unless someone other than you confirms it.

That is the whole of Dapping, and it came out of the grant pile. Self-attestation is precisely what stopped working, so we built the thing that does not rest on it.

It sounds obvious. It is also not how any professional network currently operates. Everywhere else, you write your own history and the platform prints it.

For a builder: a page you can send

A profile on Dapping is a proof page. Your projects, your skills, the ecosystems you work in and your history, at one link, built to be sent rather than maintained.

What separates it from a bio is where the history comes from. Experience is confirmed by the company you worked at, or through a work email checked against that company's own domain. Either
way, a badge exists because a named party with something to lose put their name on it.

That is the only kind of claim worth showing a stranger.

The point is not really the badge. The point is not starting from zero every time. Most builders I know have explained the same three years of work to twenty different people in twenty different formats, and watched the context fail to survive the retelling. A page that carries its own evidence is one you build once.

Pseudonymity survives it, because it has to. A great deal of serious Web3 work happens under a handle, for reasons ranging from jurisdictional risk to plain preference, and a verification system
that demands legal identity excludes the people it exists to serve. So what gets verified is the claim, not the identity behind it. What you show and what you keep private stays yours to set.

For a company: a page that outranks the strangers

Most Web3 companies are described by strangers. A Telegram admin using your logo. A job post on a board you have never heard of. Three contract addresses claiming your ticker.

A company hub is the page that outranks all of it. Claim it and it becomes canonical: your real team, your products, your open roles, the contract address you actually deployed. When someone says they work for you, there is finally somewhere to check.

It runs in the other direction too. Once your company is verified, your team's roles are attested through you, which is what makes their profiles worth trusting and yours worth checking.

That matters most at the moment of contact. When you reach out to a builder, you are asking a stranger to take a risk on you, and usually the only thing backing the request is a display name. The same holds in reverse when an application lands. Somewhere to check turns out to be what lets the conversation start.

Why it is a graph and not a directory

Every piece of this exists somewhere already. Job boards list roles. GitHub holds code. Explorers hold contracts. Conference sites hold events. What none of them hold is the connection between
them, and the connection is where trust actually comes from.

So jobs, grants, bounties, hackathons, accelerators and events sit in the same place as the companies behind them, and every listing opens into the company it belongs to. Projects open into the team that shipped them.
A message from someone you do not know arrives carrying their profile and the employer they have actually verified.

A role means more when the company confirming it is one you can open and inspect. A project means more when the team is attached to it. Each of those is a weak signal alone and a strong one together, which is why they had to be built in one place rather than integrated afterwards.

The other end of the same problem

The reviewer's problem and the builder's problem are the same problem wearing different faces. If a builder cannot prove what they did, then nobody evaluating them can tell either. So the graph has
to work in that direction too.

When you are hiring, you can search builders by the ecosystems they work in, by whether their experience has been confirmed, and by what they are open to. Every result opens into the evidence
rather than a headline, and a role you have already posted can be matched against the people whose history actually fits it. The part that normally costs hours, working out whether a promising
profile is real, is already done. The same search runs across projects rather than people when what you need is a team to partner with instead of a person to hire.

When you run a hackathon, a grant programme or a campaign, you can attest that someone took part. It takes a minute, and it is the difference between a builder holding a screenshot and holding a
credential. Go back to the team that shipped on Sunday and flew home on Monday. An attestation is the thing that still exists six months later, when they need it. The same record gives you a public
board of the people building in your community, so contribution stays visible after the event instead of dissolving into a group chat that goes quiet.

And if you are an ecosystem, the question you actually want answered is who is building on you. Not who posted about you, and not who applied for a grant eighteen months ago. That view is the projects, the companies, the builders and the opportunities connected to your chain, with the evidence behind each one graded rather than asserted, and the onchain activity across the whole portfolio in one place.

None of it is a separate product. It is the same graph read from the other side.

The part I would check first

If you are going to be sceptical about any of this, be sceptical about the score.

Karma is our answer to how much of your work someone else will stand behind. It is a signal, not a verdict, and I would rather you check the mechanism than trust the number.

Here is the mechanism. Without someone independent vouching for you, your score meets a ceiling that sits below the verified badge, and nothing you do on your own lifts it. That ceiling is enforced in the code rather than asserted in a policy. However much you post, however complete your profile, the badge stays out of reach until someone outside your own control puts their name to
your work.

You cannot verify yourself into it.

And none of it is for sale. Karma, verification and where a builder ranks are earned, and nothing you can spend changes any of them. A trust signal with a price is a trust signal with a market, and
a market in badges makes every badge worthless, including the ones issued before the market existed.

How each signal is weighed is at dapp.ing/trust/methodology. The mechanics
behind everything above, in more detail than belongs in an essay, are at docs.dapp.ing.

Why I am building it

I have built a reputation system before. The lesson that stuck from it is that reputation is worth nothing as a display. It only matters when it changes what someone can access, borrow, or be trusted with. A score nobody acts on is decoration.

That is the bar I am holding this to. Not whether a profile looks credible, but whether it changes who gets the grant, the role, the reply.

Proof of work was solved in 2009. Proof of worker is still open.

Dapping is in beta and free for builders. Claim your proof page.

Why Web3 Builders Need Proof

Shivam Soni — Thu, 20 Aug 2026 16:18:39 +0000

Why Web3 Builders Need a Proof Page

Web3 work rarely lives in one place.

A builder might contribute to a protocol, complete a bounty, join a hackathon, receive a grant, and ship a side project, all within the same year. But when someone asks, What have you worked on?, answering that simple question can become surprisingly difficult.

You start searching for a GitHub repository, wallet activity, an old hackathon page, a product demo, a grant update, or a post you shared months ago. Sometimes, you even send someone a teammate’s Telegram handle because they are the only person who can confirm what you contributed.

Soon, a simple question turns into a scavenger hunt.

Every link shows something, but no single link explains the complete contribution. The person reviewing your work still has to figure out what you built, what your role was, which team you worked with, and whether anyone can confirm it.

That is why Web3 builders don’t need another profile that simply repeats their bio, job titles, and skills. They need one place where their work, relationships, and supporting evidence come together.

The work exists. What’s missing is a clear way to connect the work, context, and evidence.

Web3 Work Doesn’t Fit a Traditional Resume

Traditional resumes were designed for a simple career path: one person, one role, one company, and one period of employment.

Web3 careers rarely follow that structure.

In a single year, a builder might contribute to an open-source protocol, complete a bounty, join a hackathon team, receive a grant, advise a DAO, and ship a product of their own. These experiences often overlap, and each one contributes something different to the builder’s professional story.

Trying to fit all of that into a traditional resume strips away much of the context that makes the work meaningful.

A resume reduces experience to titles and dates. A portfolio highlights a few polished projects. GitHub shows code but may not explain the builder’s role or the outcome. A wallet records activity without showing the person, team, or purpose behind it. Social profiles show conversations and community involvement, but they do not always show what was delivered.

Each platform captures one part of the builder’s experience, leaving hiring teams, grant reviewers, and potential collaborators to reconstruct the rest.

This is more than an inconvenience. When valuable work is difficult to understand, it also becomes difficult to discover.

Web3 builders do not lack experience. They lack a professional format designed for how that experience is actually created.

Fragmented Proof Costs Builders Opportunities

When professional proof is scattered, opportunities do not always go to the strongest builder. They often go to the person whose experience is easiest to understand.

That creates a real disadvantage for builders with credible but non-linear careers.

A recruiter may overlook a developer who delivered valuable work through bounties because their experience does not fit familiar job titles. A founder may find a GitHub repository but still be unable to understand the builder’s role, responsibilities, or impact. A grant reviewer may see an old project page without knowing what happened after the grant ended.

In each case, the evidence exists, but evaluating it requires extra time and effort.

The builder also has to repeat the same work for every opportunity: gather old links, explain past contributions, find supporting evidence, and ask former teammates to confirm their involvement. What should be a professional record becomes something they must rebuild every time.

For recruiters, founders, and grant teams reviewing many candidates, this friction matters. If understanding someone’s experience requires opening ten tabs and piecing together several disconnected sources, the evaluation may stop before a useful conversation begins.

That means credible builders can miss interviews, grants, collaborations, and introductions, not because they lack experience, but because their experience is difficult to evaluate quickly.

The cleanest profile may win the first look. The strongest builder may never get the chance to explain.

From Resume To Proof Page

Most professional resumes are built around self-reported information: a job title, a list of skills, previous experience, and a few achievements. This information is useful, but it still asks the reader to accept those claims without seeing the context behind them.

A proof page goes one step further. It connects what a builder says they have done with the work, people, and evidence that help explain it.

For example, listing a dApp on a resume does not explain what the builder actually contributed. A proof page can connect that project to their role, public work, team relationship, product demo, company verification, or a recommendation from someone involved.

The same applies to hackathons, bounties, and grants. Instead of becoming isolated achievements on old programme pages, they can remain connected to the builder, the project, and the work that followed.

Even an open to work status becomes more useful when it appears alongside relevant skills, projects, experience, and supporting evidence. It gives recruiters and founders the context they need before starting a conversation.

The difference is simple: A resume tells your story. A proof page gives people a reason to believe it.

What a Dapping Proof Page Connects

Dapping gives Web3 builders one public proof page where their work, experience, and supporting evidence can be understood together.

A builder’s page can bring together:

Professional experience and skills
Shipped projects and product demos
GitHub contributions and public activity
Hackathons, grants, bounties, accelerators, and events
The companies and dApps connected to their work
Recommendations from people they have worked with
Experience verification from relevant organizations
Professional intentions, such as being open to work, collaboration, or funding

These details do not have to remain isolated. A project can connect to the dApp it was built for. An experience can connect to the company and include verification. A recommendation can appear alongside the work it helps explain. Public activity can provide additional evidence of how the builder contributes over time.

This gives recruiters, founders, and collaborators a clearer understanding of what someone has built, what role they played, who they worked with, and what they are looking for next.

For builders, the benefit is simple: instead of rewriting the same story or sending a collection of links for every opportunity, they can share one page that grows with their work.

This connected structure is the foundation of Dapping’s professional graph for Web3, where builders, companies, dApps, and opportunities can be discovered with the context behind them.

What This Looks Like for a Builder

Consider a Solana developer who contributed to an open-source protocol, completed a bounty, won a hackathon with a small team, and later received an ecosystem grant.

Without a proof page, those achievements remain separated. The protocol contribution lives on GitHub. The bounty appears on a submission platform. The hackathon has its own project page and demo. The grant announcement is buried in an old social post.

When a recruiter, founder, or collaborator asks about their experience, the builder has to find each link and explain how everything fits together.

A Dapping proof page can connect the protocol contribution to the relevant dApp, role, and public code. The bounty can remain connected to the submission and organization behind it. The hackathon can show the project, demo, and team members involved. The grant can connect to the ecosystem programme, funded work, and resulting progress.

Recommendations and experience verification can add context from the people and organizations involved.

Instead of seeing four unrelated achievements, a visitor sees how the builder’s work developed over time, what they contributed, who they worked with, and where that experience led next.

The proof page does not create credibility. It makes the credibility a builder has already earned easier to see.

Verification Adds Context

Verified is one of the easiest words to overstate in Web3. Dapping uses it more carefully, as an additional trust signal rather than a universal guarantee.

Experience verification can provide supporting evidence through a company attestation or qualifying company-linked work email. Recommendations and reviews add human context from people who have worked with the builder. Dapping’s Karma model organizes signals across Foundation, Proof, Validation, Contribution, and Momentum to make a professional record easier to inspect.

These signals can strengthen a builder’s claims, but they do not guarantee the quality of their work, the safety of a company, a successful hire, or eligibility for an opportunity. Recruiters, founders, and collaborators must still apply their own judgment.

Dapping’s purpose is not to make professional judgment disappear. It is to give people better evidence and context so they can make more informed decisions.

Proof Becomes More Valuable Over Time

Web3 achievements can lose professional value as their context fades. Hackathon pages disappear, grant records become outdated, social posts get buried, and people move to different teams. The work still happened, but understanding who contributed and what they accomplished becomes more difficult over time.

A connected proof page preserves that context. The project remains connected to the builder, the builder remains connected to the team, and recommendations or verification stay close to the experience they support. When the next opportunity appears, the builder has a professional record to share instead of another folder of disconnected links.

That is how proof compounds. It is not about building a louder personal brand or relying on an opaque ranking. It is about creating a professional history that becomes more useful as the builder’s work grows.

Build Your First Proof Page

You do not need to document everything you have ever done before your profile becomes useful.

Start with the work that best explains where you want to go next:

Claim a public handle and write a clear headline.
Add two projects or experiences that show substantive work.
Connect the relevant company, dApp, public account, or supporting link.
Request verification or a recommendation where it adds meaningful context.
Share the public proof page the next time someone asks, What have you worked on?

Web3 builders have already done the hard part: the work.
It should not take a scavenger hunt to see it.

Build your proof page with Dapping
View an example proof page on Dapping

Dapping is early, and we are learning which kinds of proof help builders and teams understand work most clearly. After you build your page, tell us what still feels missing.