defirisk.co
rubric v1.7.0

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.

Data & output #

Data source
ENS `reverseResolver` lookup + NameStone API for deployer address
Output format
Green / Yellow / Red
Evidence artifact
Deployer address + ENS name (if any) + resolution result
Confidence signal
green = ENS name bound and resolvable to consistent identity; yellow = ENS name bound but identity not further verifiable; red = no ENS/NameStone binding; gray = deployer address not identified

Scored protocols 0 carry this factor#

No protocols have been scored for this factor yet.

Linked hacks no historical incidents linked#

No historical incidents are linked to this factor.
rubric_version v1.7.0factor RD-F-117category 7carried 0critical no