Hiring pseudonymous developers: how do you vet someone who isn't doxxed?

You have found a strong developer for your crypto project. Their GitHub is full of good work and people in your Discord vouch for them. Yet you have never seen their face or learned their real name, and they intend to keep it that way. This guide explains why that is common in crypto, and how to hire pseudonymous developers safely: check their skills first, then limit your risk before you give them any access.

Why so many crypto developers stay pseudonymous

A pseudonymous developer works under a stable public name, such as a GitHub handle, that is not their legal name. That is different from being anonymous. An anonymous contributor leaves no stable identity behind, while a pseudonym builds a track record over time that you can check. In crypto slang, the opposite is being "doxxed", which means the developer's real name and face are public, usually by choice.

Two reasons explain most cases. The first is culture. Bitcoin itself was published by an author known only as Satoshi Nakamoto, and many developers in this world expect to be judged on their code rather than their CV.

The second is safety. People who work in crypto are often assumed to hold crypto, which makes them targets. Physical attacks to force victims to hand over their coins, nicknamed "wrench attacks", reached 72 verified cases in 2025, 19 of them in France.

So a candidate who will not share their name is not a warning sign in itself. Many of the people you want to hire have good reasons to stay private.

What changes when you hire pseudonymous developers

You will often meet these developers on GitHub, Discord or Reddit rather than LinkedIn. Once you have, the usual hiring tools disappear. There is no CV to check, no former employer to call and no background check. You judge the person on what they have done in public, and on what they do for you.

The risk is real, because a hidden name can also hide a fake candidate. North Korea runs schemes in which IT workers use stolen identities and fabricated personas to get hired by companies abroad. Once hired, some of them have copied company code and then demanded a ransom.

So the useful question is a practical one. What could this person do with the access you give them, and how quickly would you notice?

How to vet a developer without a CV

Without a CV, you look at public work first, then at what the person does in a controlled test. Each check covers a different risk, so combine several.

Start with their GitHub history, and look past the grid of green squares that counts their activity. Open their pull requests, the code changes they proposed to other projects, and see whether the people who run those projects accepted them. A name on a change proves little on its own, because anyone can type any author name into it. Changes signed with a key tied to the account carry a "Verified" badge on GitHub, which is stronger evidence. To confirm the account is theirs, ask them to post a short message you choose from it.

Then look at audit results. Many crypto developers build a reputation by finding bugs in smart contracts, the programs that run on a blockchain. Platforms such as Sherlock run audit contests, open competitions where researchers race to find these bugs, and publish researcher rankings. Look for your candidate's handle there.

Check their history on the blockchain too. If they say they launched a smart contract, look it up on a block explorer, a public website such as Etherscan that displays everything recorded on a blockchain. It shows which address created the contract. Then ask your candidate to sign a short message of your choosing from their wallet, the app that holds the keys to that address. Wallets use this kind of signature to log people in to apps, and only the person who controls the address can produce it.

Ask who can vouch for them. A reference from a founder or open source lead who has worked with the handle, and who has a public reputation to lose, is worth more than a crowd of anonymous fans. Then check that the story holds together. Details that don't match from one profile to another, or a surprisingly thin portfolio site, deserve a direct question.

Ask for a live call with the camera on, even if they keep their name to themselves. A refusal of any live contact deserves a question too. A call alone proves little, though, because some fake candidates have used face-swapping software during video interviews.

Finally, test the work itself. Give them a small, real task from your to-do list, paid at a fair rate. Watch how the person asks questions and whether others can review their code easily. If that goes well, start with a short contract with a fixed scope before any long-term arrangement.

How to limit the risk once they start

Good vetting lowers the risk. Your setup decides how much damage one person can do.

Give access in steps. Start with what the first task needs, then widen it as trust builds.

Separate the keys. A private key is the secret that controls a wallet or a contract. No single person, and certainly no new hire, should be able to move funds or change a live contract alone. A multisig wallet solves this, because it needs several people to approve each transaction. With Safe, for example, you choose the owners and how many of them must confirm.

Review every change. Require a second person to approve code before it goes live.

Put it in writing. A short contract should cover the scope, who owns the code, what stays confidential and what happens to access when the work ends. When the engagement ends, remove access the same day.

Many pseudonymous developers will also ask to be paid in crypto. For a salaried position or control over user funds, plan a real identity check before the start date. Any role in a licensed business needs one too, which is part of why hiring in a regulated market is different. Paying someone who turns out to be under sanctions can bring civil or criminal penalties.

Where to start

1. Decide which roles can stay pseudonymous and which need an identity check.
2. List the access each role needs in its first month, and nothing more.
3. Put company funds and the keys that control your contracts in a multisig wallet before the hire.
4. Prepare a paid test task taken from your real to-do list.
5. Check public work: code accepted by other projects, the "Verified" badge, audit rankings, contracts they launched.
6. Ask for one live call and one reference from someone with a public reputation.
7. Start with a short contract and widen access in steps.

Hiring with Other--Side

Other--Side recruits the key people for companies in complex, regulated markets, from the first hire to the full leadership team. Technology is one of the functions we cover, alongside compliance, operations, product and finance. Before you meet a candidate, we check them against the rules of your market. You can read more about our services, or start a conversation about the developer you are trying to hire.