How to verify a Web3 or AI developer's past work, claim by claim

To verify a Web3 or AI developer's past work, check each claim in two steps: tie the work to the candidate's account, then the account to the person. Most records prove less than they look: GitHub's Verified badge proves which key signed a commit, and a verified Etherscan contract proves its source matches the bytecode, but neither says who wrote the code. So ask the candidate to close each gap: sign a sentence you write from their deployer address, walk you through a pull request (PR) a maintainer merged in someone else's repository, and name a past employer you reach through its own public channel. A Dapping profile shows which roles a company confirmed and which records an organizer issued.

Facts were checked on 4 November 2026 against each platform's documentation, the FBI's public notices and the named sources.

The one-hour check, in order

Verifying one finalist takes about an hour if you run the checks in this order, cheapest first, and finish before any offer goes out:

1. Compare the GitHub account's created_at with its oldest commits (2 minutes).
2. Find PRs merged into repositories the candidate doesn't control, and pick one with review comments (10 minutes).
3. Read the Contract Creator for each contract they claim, and note factories and multisigs (5 minutes).
4. Send the signing sentence for each deployer address and verify the reply (5 minutes).
5. Check each hackathon prize on the organizer's own page (10 minutes).
6. Ask for the finalist's Dapping profile link and note which roles a company confirmed and which records an organizer issued (5 minutes).
7. Contact one past employer, for a role no company has confirmed, through a channel you found yourself (10 minutes to send).
8. In the interview, walk through the PR and one contract or model (20 minutes).

If a check fails, move that claim to the employer check or the interview.

Why real work doesn't prove who the person is

Taylor Monahan, a security researcher at MetaMask, said in April 2026 that North Korean IT workers' claimed years of blockchain experience are genuine, and that "Lots of DPRK IT workers built the protocols you know and love" (Monahan's comments in Cointelegraph). A worker who did the work can sign and defend the PR, and the FBI's October 2026 notice on North Korean IT workers says they "cannot be identified reliably with a single indicator".

What does each record prove?

A verified claim is one that someone other than the candidate confirmed.

Compiled from the documentation of GitHub, Git, Etherscan, Sourcify, EAS, Hugging Face, arXiv and LinkedIn on 4 November 2026.

How do you check a GitHub history?

The Security Alliance (SEAL) framework for screening North Korean IT workers lists this tell: "The account creation date is later than the commits in its hosted repositories" (SEAL's tactics page). Open https://api.github.com/users/<handle> and read created_at. One exception: a repository imported from GitLab or an old employer's server keeps its original dates, so ask before you conclude. The test runs one way: a young account with old commits needs an explanation, but an old account proves only that the account is old.

Workers also edit the .git config of a cloned repository to put their own account on it, so search GitHub for a distinctive commit message from the candidate's repo; an older copy under another name is the original.

A merged PR in a repository the candidate doesn't control is the strongest public evidence of code they wrote. Search GitHub for is:pr is:merged author:<handle> -user:<handle> (GitHub's search syntax); each merged PR in the results carries a merged_by field naming the maintainer who accepted it (pull request API). Check that the maintainer's history on the project predates the candidate's account, then read the review thread before the interview, and ask the candidate which comment they pushed back on and how it was settled.

How do you tie a deployed contract to the candidate?

Etherscan's source verification succeeds only when the submitted source reproduces the exact bytecode onchain (Etherscan's verification docs), and Sourcify's Match, as opposed to Exact Match, can differ in comments and variable names (Sourcify's match levels). Neither records who wrote the smart contract, and a fork of Uniswap or Compound deployed from the candidate's own wallet passes both. If Etherscan shows a Similar Match, with a yellow badge naming another contract, the bytecode matches code someone else verified (Etherscan's verification types). Either way, diff the source against the protocol it forks and ask the candidate to walk through what they changed.

What the chain records is an address. The contract's Etherscan page shows its Contract Creator, and the getcontractcreation endpoint adds a contractFactory field when a factory contract did the deploying (endpoint docs). If the creator is a team multisig or a company's deploy key, the address can't point to one person, and the claim becomes an employer claim.

When the creator is a personal wallet, ask the candidate to prove control of it. Send a sentence you write on the day, for example: "I control 0x... and deployed the [contract name] contract for [project]. Signed for [your company] on 4 November 2026." The candidate signs it in their wallet, on Etherscan's Verified Signatures tool or with Foundry's cast wallet sign, and sends back the signature. You paste the address, the exact text and the signature into the tool's verify option and confirm all three match. Don't publish it without the candidate's agreement. The text has to be yours and new, for the reason Sign-In with Ethereum puts a nonce and an issued-at time in every message (EIP-4361): an old signature proves only that someone once held the key.

How do you check hackathon wins and AI work?

An organizer's page lists the project and the prize it won, and nothing about who wrote which part. The ETHGlobal project page for OniBlock, from ETHGlobal Tokyo 2026, lists the Uniswap Foundation prize it won and links the source code, with no team list. On Devfolio only the hackathon's creator adds winners (Devfolio's winners guide). An organizer that Dapping has verified can also issue a winner record; when the builder chooses Show on profile, it sits in the Activities tab of their profile with the organizer named, so the prize carries the organizer's name rather than the candidate's word (how organizers issue records). Check the prize on the organizer's page rather than a screenshot, then look in the linked repo for the candidate's signed commits: GitHub stores a verified_at time when it verifies a signed commit at push (GitHub's signature docs), which the author can't set, so it should fall within the event or just after it.

Hugging Face models, datasets and Spaces are Git repositories (Hub repositories), and Hugging Face says Git "does not authenticate the actual commit authors"; only GPG-signed commits show as Verified (Hugging Face commit signing). For papers, arXiv's endorsement "is not peer review"; it confirms that a submitter belongs to the scientific community (arXiv endorsement); an ORCID iD linked to the arXiv account connects the papers to one author record (arXiv and ORCID). In the interview, ask the candidate to open the training or eval logs behind one published result and explain a choice in them.

How do you check a past employer?

Reach the company through a channel you found yourself, because the reference the candidate supplies is part of the claim. Socket's threat research team studied 80 suspicious engineering profiles in 2025, and its back-channel checks with industry contacts found, in multiple cases, no record of the candidate at the named company (Socket's investigation). SEAL adds that some listed employers are companies the workers control.

A LinkedIn workplace badge doesn't settle it. LinkedIn verifies a workplace through a work email at the candidate's current company (LinkedIn's workplace verification), so the badge covers today's employer and no past role.

For DAOs and startups that closed, look for what the team published: contributor posts on the governance forum, grant reports naming the team, the project's site in the Internet Archive. A contributor paid onchain can sign from the address that received payment, the same check as the deployer.

How do you run this check on Dapping?

A builder's Dapping profile puts the employer and organizer checks on one page, each claim next to how it is backed. For a finalist who has one:

1. Ask for the profile link. It has the form dapp.ing/profile/<username>.
2. Read the label on each role in the Experience tab. At a company Dapping has verified, a role is confirmed in one of two ways, and the label names which. Company attested means an owner or admin of the company's hub confirmed it. Work email verified means the builder confirmed a code sent to an address on the company's domain, and Platform reviewed means a Dapping admin then reviewed that proof. The work email itself is never shown. Self-attested means the builder confirmed the role at a company hub they run themselves, and a role with no label is one the builder typed. Run the employer check on both.
3. Open the company's hub yourself from the company directory rather than from a link the candidate sent. Its People tab lists the people the company confirmed as current team, and a hub with the verified mark had its official X account and a company-domain email reviewed by a person at Dapping. Claiming a hub and verifying it are separate steps, so look for the mark itself.
4. Check the Activities tab for hackathons and programs. Each record names the company that issued it and the outcome, participant or winner, and can name the role the builder played, such as mentor or judge. Set it beside the organizer's own page.
5. Open the Portfolio tab. Each Project has its own page in the Projects directory that lists, under Members, the teammates who approved their credit, and the builder's Portfolio card names the area they worked on, such as Engineering or Design. That gives you the first walkthrough question: which part was yours, and which commits in the linked repo show it.
6. Read the Recommendations tab. Each one is a named person's account of working with the candidate, with the relationship stated, and a useful lead for the reference you then contact yourself. The writer owns the text.

To find more finalists like this one, search builder profiles by skill, role or location, then open each proof page and message the builder from it. Filters that narrow to people whose work history is confirmed depend on your company's plan (pricing).

Before you weigh a candidate's history, read what each proof label checks.

How do you confirm the person at the offer?

Confirm the person by tying the account to a name and a place at the offer, and escalate on combinations of signals, not single ones. The FBI's October 2026 notice says North Korean workers rotate through bank accounts, street addresses and social accounts unusually often, and its January 2025 notice tells employers to check whether phone numbers and emails recur across resumes. And SEAL puts the usual salary discount these workers accept at 25 to 50% (SEAL's mitigation page).

Pay salary into an account in the candidate's own name, ship any laptop to the address on their ID, and check that the person on the first day is the one you interviewed. The FBI lists E-Verify (the US work-eligibility check), multiple forms of identification and live verification as steps that add friction. Screen the payout address too: OFAC's 28 October 2026 action sanctioned 10 people and one entity who facilitated North Korean IT worker schemes, and TRM Labs counts eight wallet addresses in the listings (TRM Labs' summary).

Start with the signing sentence for your next finalist, and ask for their Dapping profile link before the reference calls, so you know which roles a company has already confirmed. If your company hires builders, claim and verify your company hub so the roles you confirm carry your name.

Frequently asked questions

Is it safe to ask a candidate to sign a message?

Yes, if it's a plain message. A personal_sign message under EIP-191 is prefixed so that it can never be an Ethereum transaction, and signing it costs no gas. Write readable text with the date and your company's name, and never ask for a transaction or a token approval.

What if all of their past work is private?

Then the employer check counts for more, and the walkthrough moves to a system they built: the constraint behind its design and what broke in production. A role their employer confirmed on Dapping is backed by the company even when the code is private. Look for public traces too, such as a conference talk or an audit report naming the team.

Should a take-home test replace these checks?

No, run it after them. Anthropic reported in August 2025 that North Korean operators using its model "do not appear to be able to write code" without it, yet passed technical interviews (The Register on Anthropic's report). A take-home shows what a candidate produces with help, so use it to confirm what the walkthrough showed, not to replace it.