ENS/NameStone identity bound to deployer
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 checks whether the deployer address has a bound Ethereum Name Service (ENS) domain or NameStone name that resolves to a verifiable human identity — one where the ENS registration itself is connected to a social profile, GitHub account, or other identity anchor. Measurement is programmatic via ENS resolution: the factor queries the reverse ENS record for the deployer address and, if present, traces the ENS name to any linked identity records. Category 7 context: an ENS name bound to a deployer is a weak but non-trivial accountability signal — it requires the deployer to have established an on-chain identity prior to deployment.
**Why it matters** ENS names are not a strong identity guarantee — they can be registered pseudonymously — but their presence indicates that the deployer made an active choice to establish an on-chain identity, which marginally increases the cost of disappearing after a rug. More importantly, ENS names linked to verifiable social profiles (e.g., a vitalik.eth-style linkage where the ENS resolves to a Twitter account with history) provide meaningful corroborating identity signal. The absence of any ENS binding on a high-TVL deployer is a weak negative signal, particularly for protocols where other identity signals are also absent.
**Green / Yellow / Red** Green is scored when the deployer has an ENS or NameStone name that resolves to a verifiable identity anchor — linked to a GitHub account with multi-year history, a public social profile, or a prior audited-protocol deployment. Yellow applies when an ENS name is present but resolves only to the address itself or to a pseudonymous social handle with no further verifiable history. Red is not applicable as a standalone grade trigger; this factor is a positive mitigant or neutral signal, not a disqualifier.
**Common gray cases** Gray is assigned when the deployer uses a multi-sig factory or CREATE2 pattern where the originating EOA is not the direct deployer of record, making ENS reverse-resolution inapplicable.
**Notable historical examples** No cross-hacked incidents currently linked in database for this factor.
Measurement what to look for #
Determine whether the deployer address has a bound ENS or NameStone name resolvable to a verifiable identity.