Why we built Dapping: a proof page for builders, canonical hubs for companies, and verification that ends with someone accountable rather than with the person making the claim.
By Kishan Marsonia, founder of Dapping.
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.
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.
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.
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.
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.
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 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.
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.
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.
