Conservative run output on a 500+500 Arbitrum governance\/control cohort. Node colors encode node\/evidence types in the visualization, not governance-vs-control cohort membership.<\/p>\n
Onchain systems love to count identifiers.<\/p>\n
Wallet addresses. DIDs(decentralized identifiers). Governance voters. Delegates. Safes.<\/p>\n
Those counts are useful, but they are not the same thing as entity counts. A single operator can control many wallets. A DAO team can manage multiple Safes. A bridge, exchange, or relayer can make unrelated addresses look connected.<\/p>\n
`unmasking-did<\/a>` is not a deanonymization tool and it is not a Sybil detector. It is an evidence-preserving linker: every cluster must explain which signals connected the identifiers, and what those signals are allowed to mean. The point is to measure coordination without collapsing it into identity.<\/p>\n `unmasking-did<\/a>` separates primary evidence kinds from derived coordination signals.<\/p>\n Primary evidence kinds are stored as typed rows and used directly by link\u00a0policy:<\/p>\n Evidence definition.<\/p>\n Derived coordination signals are computed at cluster or feature level\u200a\u2014\u200anot stored as evidence\u00a0rows:<\/p>\n Derived signals<\/p>\n It is easy for pipelines to blur these categories. A shared funder becomes evidence of common control; a DID becomes proof of identity. `unmasking-did<\/a>` keeps the semantics separate: evidence type defines what a link means, while policy thresholds define how cautiously it can be\u00a0used.<\/p>\n Fixed cohort seed \u2192 Alchemy ingest + Safe\/ENS\/DID enrichment \u2192 typed evidence rows \u2192 conservative link policy \u2192 monitoring layer with run isolation and Jaccard lineage \u2192 JSON, graph, and Markdown artifacts.<\/p>\n Before Arbitrum, I tested the pipeline on a small Scroll DAO Safe set: five governance Safes clustered through repeated Safe-owner evidence, while the Admin Multisig stayed separate. That was enough to validate control-style signals, but not enough to test funding-based coordination at\u00a0scale.<\/p>\n The failure mode I wanted to test next was simple: would funding evidence accidentally turn a governance dataset into one giant\u00a0entity?<\/p>\n Note that Full run specification can be found\u00a0here<\/a>.<\/p>\n The original linker allowed `funded_by` to behave too much like merge evidence. That produced a giant mixed\u00a0cluster:<\/p>\n Metric runs<\/p>\n A 425-address component is visually persuasive. But if the glue is common infrastructure\u200a\u2014\u200aservice-like funders, routers, high-fanout sources\u200a\u2014\u200athe component is not an interpretable entity cluster. It is infrastructure wearing the shape of identity.<\/p>\n Shared funding is not the same as shared\u00a0control.<\/p>\n A single shared funder can support a \u201crelated candidate\u201d label. It should not automatically merge addresses into a\u00a0cluster.<\/p>\n The fix was not to remove `funded_by`. Funding still matters\u200a\u2014\u200ait just needs to be demoted from naive identity evidence to conservative coordination evidence.<\/p>\n { In plain\u00a0English:<\/p>\n one shared funder is not enough\u200a\u2014\u200arequire at least two<\/strong> shared `funded_by<\/em>` keysthose links need at least two short-burst hits (block delta \u2264\u00a05,000)service-like keys are suppressed\u200a\u2014\u200arouters, bridges, zero\/system addresses do not merge\u00a0clustershigh-fanout keys above the cap are treated as infrastructure<\/p>\n Timing is the key addition. Two addresses funded by the same source months apart are not the same signal as two addresses funded repeatedly in a tight block\u00a0window.<\/p>\n Metric runs with two\u00a0types<\/p>\n The top cluster went from 425 to 5. In this run, we observed no governance\/control mixed clusters among the top clusters shown after conservative filtering. Treat this as a consistency check, not proof of absence: it reflects what survives the policy\u200a\u2014\u200aincluding service and fan-out suppression\u200a\u2014\u200anot everything that ever co-occurred in raw\u00a0flows.<\/p>\n Two concentration metrics are worth calling out. The Gini coefficient is 0.024 and the Nakamoto coefficient is 477 (computed over inferred cluster sizes: the number of clusters needed to account for 50% of all clustered addresses). Both confirm the output is not secretly dominated by a few large components.<\/p>\n On the ingestion side, 1,988 Alchemy calls produced 14,101 transfer rows and a 10 MB SQLite database, with no `db_size_stop` trigger. The canonical summary, report, and bounded graph artifacts are in\u00a0here<\/a><\/p>\n Advanced metrics panel for run run-1777967119432576, policy profile arbitrum_gov_conservative_v1.<\/p>\n Without a control group, every common funder can look suspicious. With one, the analysis can ask comparative questions under the same policy and\u00a0window.<\/p>\n For the count rows below\u200a\u2014\u200ashort-burst clusters, high top-funder share, common-sink clusters, and `candidate_*` clusters\u200a\u2014\u200acounts are computed over pure-by-cohort multi-address clusters only. Singleton clusters are included in the median cluster size and multi-address cluster-rate summaries.<\/p>\n Gov. vs.\u00a0control<\/p>\n In this run, control is equal or higher across these coordination-oriented indicators. That does not prove governance is clean; it means governance does not appear elevated relative to this activity-matched baseline under the current conservative policy.<\/p>\n One caveat: the control cohort is ARB token transfer participants in the same block window\u200a\u2014\u200aan activity-matched comparison, not a random sample of the full Arbitrum population. It controls for on-chain activity level, not for all behavioral differences. The baseline is useful; it is not a population ground\u00a0truth.<\/p>\n Any claim that governance addresses behave unusually would need to clear this baseline first. The control cohort sets the floor, not the\u00a0verdict.<\/p>\n The review-priority buckets only rank which clusters are worth reviewing first. They are not risk labels, misconduct labels, or claims emitted by the core\u00a0linker.<\/p>\n These labels are review-priority buckets, not risk or misconduct labels.<\/p>\n For this project, the viewer is mostly an audit surface: it shows the evidence rows behind a cluster so I can tell whether a merge came from Safe ownership, shared funding, or a policy artifact. Cluster counts alone do not tell you\u00a0that.<\/p>\n The full narrative viewer at https:\/\/egpivo.github.io\/unmasking-did\/viewer\/index.html<\/a>Clicking a graph node reveals its evidence type and degree. The interpretation boundary is explicit in the UI: coordination evidence, not claims about humans or malicious actors.<\/p>\n This is not a Sybil detector. A real attack requires a target objective\u200a\u2014\u200aairdrop farming, vote manipulation, reputation abuse\u200a\u2014\u200aand this system does not observe objectives. What it produces is a cluster with a named evidence policy and an inspectable trail. Whether that cluster is interesting depends on context the pipeline does not\u00a0have.<\/p>\n A single snapshot is easy to\u00a0overfit.<\/p>\n For monitoring, the useful questions are whether clusters grow, split, disappear, or change funding patterns across\u00a0windows.<\/p>\n The pipeline is designed for that shift. Each run has a fixed input snapshot, a frozen block window, and a policy profile that defines how evidence is interpreted. That makes runs comparable, not just reproducible.<\/p>\n The next useful version is boring on purpose: rerun the same policy every month, diff the clusters, and investigate only the changes that survive the same evidence\u00a0rules.<\/p>\n Note that this post is originally from my blog\u00a0post<\/a>.<\/p>\n Funding Is Not Identity: A Conservative Approach to Onchain Entity Linking<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":" Conservative run output on a 500+500 Arbitrum governance\/control cohort. Node colors encode node\/evidence types in the visualization, not governance-vs-control cohort membership. Why Identifier Counts Are Not Entity\u00a0Counts Onchain systems love to count identifiers. Wallet addresses. DIDs(decentralized identifiers). Governance voters. Delegates. Safes. Those counts are useful, but they are not the same thing as entity counts. […]<\/p>\n","protected":false},"author":0,"featured_media":163768,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-163767","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/163767"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=163767"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/163767\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/163768"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=163767"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=163767"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=163767"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Evidence Before\u00a0Identity<\/strong><\/h3>\n
The Arbitrum Governance\/Control Dataset<\/strong><\/h3>\n
The Naive Failure: `funded_by` Creates a 425-Address Cluster<\/strong><\/h3>\n
Conservative Policy: Repeated + Short-Burst + Non-Service<\/strong><\/h3>\n
“funded_by_policy”: {
“enabled”: true,
“min_shared_keys”: 2,
“min_short_burst_hits”: 2,
“service_fan_out_cap”: 50,
“short_burst_block_delta”: 5000
},
“fan_out_cap”: 50,
“min_evidence”: 1
}<\/p>\nResult: Top Cluster 425 \u2192\u00a05<\/strong><\/h3>\n
Why the Control Cohort\u00a0Matters<\/strong><\/h3>\n
The Viewer<\/strong><\/h3>\n
What This Is\u00a0Not<\/strong><\/h3>\n
Next: From Snapshots to Monitoring<\/strong><\/h3>\n