Founder and Team Research
Founder and team research evaluates capability, incentives, integrity and execution history without confusing charisma, follower count or pedigree with evi
Reading progress — saved on this device
Learning objectives
- Verify team identity, experience and prior execution where possible.
- Assess incentives, conflicts, key-person dependence and disclosure quality.
- Separate relevant expertise from reputation signalling.
What it is
Team quality matters because early crypto projects often depend heavily on a small group for engineering, treasury decisions, governance proposals and emergency response. The more centralised the operational reality, the more founder due diligence matters.
Relevant experience is role-specific. A famous finance executive may not be able to ship secure protocol code, while a strong engineer may lack distribution or regulatory capability. Map people to the actual execution requirements.
Integrity signals include consistency of disclosures, treatment of prior stakeholders, handling of incidents and willingness to correct errors. No single biography proves trustworthiness.
How to analyse it
Verify employment, prior projects, publications, repositories, corporate records and public presentations where legally and ethically appropriate. Treat unverifiable claims as uncertainty rather than automatically true or false.
Map token and equity incentives. Founder allocations, vesting, treasury control and related entities can create conflicts even when the product is legitimate. Large future unlocks may also affect retention incentives.
Assess key-person risk. If one founder controls fundraising, protocol upgrades, multisig access and public communications, the project may have a governance bottleneck that is not visible in org charts.
Review incident behaviour. How a team responds to exploits, outages or missed targets can reveal operational quality more reliably than prepared marketing material.
Research framework
| Check | Why it matters | What to verify |
|---|---|---|
| Relevant capability | Tests execution fit | Match founders and executives to engineering, product, commercial and compliance needs. |
| Verification | Tests disclosure quality | Cross-check biographies, code, prior projects and corporate records. |
| Incentives | Tests alignment | Review token/equity ownership, vesting, compensation and related parties. |
| Key-person risk | Tests resilience | Identify single points of operational or governance dependence. |
Evidence hierarchy and limitations
Avoid over-weighting elite employers, universities or venture investors. These can provide useful priors, but due diligence should update on actual project-specific execution and behaviour.
Pseudonymity changes the evidence set. When identity cannot be verified, stronger weight may be placed on long-lived reputation, signed releases, code contributions, multisig distribution and transparent operational controls.
Worked example and thought exercise
A protocol advertises a ten-person engineering team, but repository history shows 85% of core code written by one founder who also controls two of three multisig keys. The headcount is less important than the concentration of critical knowledge and authority.
Another pseudonymous team has five years of signed releases, multiple independent contributors and a well-distributed multisig. Lack of legal names still creates uncertainty, but operational evidence may be stronger than a superficial doxxed team.
Thought exercise: Which evidence would make you comfortable with a pseudonymous team, and which risks would remain regardless?
Common mistakes and practical workflow
- Treating prestigious prior employers as proof of protocol competence.
- Ignoring founder token vesting and related-party entities.
- Assuming a large team means low key-person risk.
- Equating pseudonymity with fraud or, conversely, treating it as irrelevant.
Practical workflow
- List critical project functions and accountable people.
- Verify material experience and prior work.
- Map ownership, vesting, compensation and related parties.
- Identify key-person and knowledge concentration.
- Review behaviour during past incidents, delays and stakeholder conflicts.
Knowledge checkpoint
- Why is role-specific experience more useful than pedigree alone?
- How can vesting affect incentives?
- What is key-person risk?
- How can incident response reveal team quality?
FAQs
❓ Must a team be publicly identified?
No, but pseudonymity increases uncertainty and makes operational controls and long-lived reputation more important.
❓ Are famous investors proof of quality?
No. They may improve credibility but do not replace independent research.
❓ What should be checked about founder tokens?
Allocation size, vesting, unlock timing, governance power and related-party transfers.
❓ Why review former projects?
They provide evidence about delivery, security, stakeholder treatment and execution under stress.
Summary
Team due diligence combines verified capability, incentive alignment, operational concentration and behaviour under stress. Reputation is a starting prior; project-specific evidence should determine the conclusion.
Want this in a personalised order?
Take the crypto assessment and get a custom path of 10 modules matched to what you already know. Free, no card required.
Build my path →