Team other-protocol involvement history
A dev identity & insider risk factor in the v1.7.0 rubric. Measured per protocol on a s cadence.
Methodology how we score #
**What this measures** This factor documents the record of current and prior protocol roles for each team member — whether they have previously contributed to audited, live, and non-exploited protocols; whether any prior protocol they contributed to was subsequently exploited; and whether any prior project under their name was abandoned or exit-scammed. Output is a structured list of protocol involvement with outcome classification per role. Category 7 context: a team member's prior protocol track record is the strongest available proxy for security culture and operational competence, distinct from code quality which audits assess separately.
**Why it matters** Prior involvement in a rugged or exit-scammed protocol is a documented precursor in the dataset. AlexLab experienced two independent exploits across separate vectors, suggesting team-level security culture deficiencies rather than isolated bugs. Hope Finance's three multisig signers coordinated the drain — their prior roles were not disclosed. Conversely, team members with documented histories at major audited protocols (Uniswap, Aave, Compound core contributors) represent a verifiable competence and accountability signal. The factor is not deterministic: contributors who moved between legitimate protocols carry positive signal even if one of those protocols was later exploited for unrelated reasons.
**Green / Yellow / Red** Green is scored when core team members have documented prior contributions to two or more audited, non-exploited protocols with verifiable on-chain deployment history. Yellow applies when prior involvement exists but protocols were smaller, less audited, or one of the prior protocols was exploited (though not by the same team member's code). Red is scored when any team member has a verified prior association with a protocol that was exit-scammed or where that member is listed in a curator rug database.
**Common gray cases** Gray is assigned when the team is pseudonymous and no prior protocol involvement can be verified through OSINT, or when stated prior involvement cannot be confirmed via on-chain deployer or contributor evidence.
**Notable historical examples** No cross-hacked incidents currently linked in database for this factor.
Measurement what to look for #
Document current or prior protocol roles for team members (conflicts of interest, prior rugs, prior successful launches).