DEV Community: Dapping

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.