Agent DNA: which agents are really the same thing underneath

Method dna-1.0 · code: services/dna, packages/store/src/dna.ts, packages/intel/src/dna-active.ts · API: /v1/dna/* · Explorer: /dna · migration 025_dna.sql

Agent DNA answers one question about the Census (every ERC-8004 agent on Ethereum and Base mainnet that we index): which of these agents are the same thing, or run by the same hand, without running any of them and without any model call. It reads data the Census, the Unsolicited Ratings probes and the On-chain Backtest already collect, reduces each agent to a set of comparable keys, links agents that share them, and reports the groups with the evidence that links them.

It is a similarity finding, not a verdict, and never a statement about an agent's quality. Two agents in one cluster are likely run by one operator or built from one template; the page of every cluster says which signals link them and how confident we are. The numbers in section 8 are from a real run on the full Census and include a manual precision check.

#1. What goes in (and what does not)

Not used: anything an owner told us in confidence; probe-derived signals of an agent whose owner opted out of Unsolicited Ratings (their evidence is excluded from the run, and /v1/dna/agents/:id returns signals: null for them; chain-derived clusters stay, because they are public chain data). Nothing here runs an agent or calls an LLM, and the job has no dependency on the the LLM inference host.

#2. Operator clusters ("one operator")

Every agent is turned into keys, one family per signal. Agents sharing a key are candidates. A signal has a weight (what sharing that key alone says about "same operator") and an owner-span cap: a key shared by more distinct owners than the cap is a platform (a hosting service, a launchpad, an exchange wallet), not an operator, and is ignored for linking. Caps are a large part of the precision story: without them a single hosting domain would merge tens of thousands of unrelated agents.

Linking rule. A signal with weight >= 0.8 links on its own (union of the whole bucket). Weaker signals link two clusters only when independent evidence corroborates: the noisy-OR of the strongest weight per evidence class between them must reach 0.8. Classes: host facts (endpoint host, TLS certificate and server address count once: they describe the same host), tool set, registration content, agentURI template, on-chain habit. For example host 0.5 + shared tool set 0.5 + identical text 0.35 = 0.91; host + certificate + address alone stay at 0.5. One weak signal never links; two usually do not. A weak merge is refused when it would create a cluster over 3,000 agents, and weak buckets spanning more than 40 clusters are skipped as too generic. Clusters are connected components of the resulting graph (union-find); we do not use Louvain, because the thresholds already keep components from chaining and community detection would add arbitrary splits to what are mostly exact-key groups.

Basis and confidence are reported per cluster:

• registrant: one owner wallet. Confidence high, unless the registrant looks like a platform: a distinct agent wallet per agent (>= 10 and >= 30% of members, e.g. Olas, which registers on behalf of users) marks the cluster custodial and confidence low ("shares a registrant wallet, not evidence of a single operator").
• minter: several owners linked only through shared registration transactions or directories. Whoever sent the transaction created these agents, and may have transferred them to different owners afterwards (a sale or airdrop). Confidence medium. When at least 80% of such a cluster's agentURIs sit on a host that serves more than 30 unrelated owners (a launchpad or hosting platform minting for its users), the cluster is marked platformMinted and confidence low.
• infrastructure / mixed: several owners linked by shared exact endpoints or funders (infrastructure), or by both those and shared transactions or directories (mixed). High when an exact shared protocol endpoint or funder links the owners; medium when only corroborated weak evidence does.

"Operator" therefore means "the same registrant, minter or infrastructure", which is what can be read from public data; it is not a legal or identity claim.

#3. Template families, white-label copies and lineage

A family is a group of agents that are the same thing, whoever runs them: identical registration content (docExact), near-duplicate text, the same MCP tool set (names plus description openings, or 3+ tool names), or the same A2A skill-id set (4+ skills, buckets over 300 skipped). Near-duplicates are found with MinHash (64 permutations over word 2-shingles) and 16-band LSH, then verified with exact Jaccard >= 0.85; LSH buckets over 120 documents are skipped. Families spanning more than one operator cluster are crossOperator: copy networks, template launchpads or forks. A family spanning more than 50 operators is widelyShared (a default text or popular template, e.g. the demo description "only test") and gets confidence medium at best.

A family is white-label when 2+ members have 3+ tools, all with the same tool set, run by 2+ operators under 2+ different normalised names: the same software behind different brands. Only agents with an observed MCP tools/list can be tested for this (about 460 endpoints today), so the white-label count is a floor.

Lineage. For each agent whose registration content equals or closely resembles that of an agent registered earlier by a different operator, the closest earlier one (highest similarity, then earliest) is its parent: copy for identical content, fork for Jaccard 0.60 to 0.99, with a diff (name changed, tokens, endpoint hosts and tools added or removed). One parent per child. Direction rests on the registration block, which orders registrations, not authorship: the real origin may not be in the Census, and a later registration of an older project looks like a fork.

#4. Feedback rings (sybil signals for reputation)

Wallets are mapped to entities (an operator cluster when the wallet owns agents of one, otherwise the wallet). ERC-8004 feedback is a directed edge from the client wallet to the receiving agent's entity. We flag:

• intra: an operator cluster of 2+ agents receiving at least 10 non-revoked feedback events of which at least 30% come from the cluster's own wallets;
• mutual_pair / mutual_ring: entities connected through reciprocal feedback (A gave feedback to B and B to A), taken as connected components; flagged when at least 10 events and at least 50% of everything the group's agents received come from inside the group. shape is star when one hub carries >= 80% of the mutual pairs, dense otherwise, pair for two.

Revoked feedback is excluded. A ring is not an accusation: protocols can legitimately vouch for each other, and a hub that thanks everyone who rates it forms a star. The flag marks reputation that cannot count as independent, with counts attached. Pure outside clients (wallets that own no Census agent) are never part of a ring.

#5. Where it appears

• GET /v1/dna/agents/:agentId, /v1/dna/clusters, /v1/dna/clusters/:id, /v1/dna/stats, /v1/dna/rings[/:id], /v1/dna/builds[/:buildId].
• Unsolicited Ratings: GET /v1/ratings rows and GET /v1/ratings/:agentId gain an additive cluster field (operator cluster id/size/confidence, template family, ring) and a sybilCaveat string when the agent shares an operator with others or sits in a ring. No score or tier is changed. GET /v1/ratings?collapse=clones returns one agent per operator cluster / template family (the best rated; a better-rated twin in either group hides the agent), with the hidden count implicit in meta.total.
• Honesty Index: GET /v1/honesty gains dna.twinGroup per build and ?collapse=twins (see section 7). The stored, attested snapshot is not modified.
• Explorer: /dna (numbers, top operators, rings, cluster browser, Active DNA of our builds), /dna/:clusterId, /dna/ring/:id, a DNA section on every Census agent page, a card on /stack.

#6. Reproducibility and attestation

A run replaces the derived snapshot (dna_agents, dna_clusters, dna_rings, dna_lineage) in one transaction and records a dna_runs row with the numbers. Cluster ids (dnc_… operator, dnf_… family, dnr_… ring) are inherited across runs from the previous cluster with the largest member overlap (Jaccard >= 0.5), so links stay valid while clusters grow.

The snapshot hash is sha256 over a canonical form of the method version and every cluster as its sorted member list (clusters sorted, ids excluded). It is attested on Ethereum Sepolia EAS with the schema string methodVersion,uint32 runId,uint32 agents,uint32 operatorClusters,uint32 familyClusters,uint32 feedbackRings,uint32 largestOperatorCluster,bytes32 snapshotHash; anyone can fetch /v1/dna/clusters, rebuild the canonical form and compare. The run is deterministic for fixed inputs (tested). A daily systemd timer (karatum-dna.timer, 03:40 UTC) recomputes it.

#7. Active DNA: our own builds

The behavioural fingerprint of a Karatum build (packages/intel/src/fingerprint.ts: the distribution of behaviour classes over scripted canary probes, with a noise floor measured between two halves of the baseline) is the build's DNA. /v1/dna/builds reads the stored fingerprints:

• dnaId is the baseline hash; every later fingerprint is listed with its drift; status: "changed" when the latest drift exceeds the certification policy limit (0.15 beyond the build's own noise floor, the same rule that turns a certificate STALE). A model or prompt swapped silently behind the same build id is exactly this event, now visible without opening a certificate.
• Behavioural twins: builds on the same probe set whose baselines are within 0.10 mean per-probe total-variation distance share a twinGroup. nearest lists the three closest builds.
• GET /v1/honesty?collapse=twins keeps one build per twin group (the best ranked).

External Census agents have no behavioural fingerprint; they are only ever compared passively. Calibration of the drift rule itself is in docs/reports/fingerprint-calibration-*.

#8. Run on the full Census, and how wrong it is

Run 4 of 2026-10-16 (snapshot hash 0x071cd3bd…c5990300, attested on Ethereum Sepolia EAS, uid 0xf28d20ce…a6f6f4), computed in 18 s from the live Census (raw numbers docs/reports/agent-dna-2026-10-16.json, hand check docs/reports/agent-dna-2026-10-16.md).

Coverage of the inputs. 205,406 agents (Base 151,246, Ethereum 54,160). Registration content readable for 29,847 (14.5%: 27,421 fetched documents plus 2,426 documents inlined in the agentURI that the run parses itself); the other 175,559 are compared only on wallets, registration transactions and the agentURI string, because the Census resolves a bounded batch per day. 6,243 agents declare endpoints, 459 have an observed MCP tool list, 1,934 declared hosts were scanned (1,455 answered a TLS handshake), 450 Ethereum owner wallets have a first funder (389 found, 277 low-volume), 114 wallets were backtested (24 with a stable on-chain habit).

Operator clusters. 17,841 clusters of 2+ agents containing 114,236 agents (55.6% of the Census). Sizes: 13,912 pairs, 3,253 of 3-9, 605 of 10-99, 61 of 100-999, 10 over 1,000. The largest is 15,264 agents (agents.exquisite.land, an NFT-agent project registering through 8 wallets); the next are 8,568 (Signalbound), 6,877 (ag0.xyz, 84 owners linked by shared registration transactions), 3,261, 2,293. 15,407 clusters are one registrant wallet (72,396 + 789 agents; 2 of them, 789 agents including Olas' 774, are platform-like registrants and labelled low). 2,434 span several owners: 2,292 are platform minting (two or a few unrelated owners per transaction on a host serving many owners, mostly centralcity.ai; 4,919 agents, labelled low), 57 are medium-confidence minter batches (3,280 agents), and 85 are linked by shared infrastructure or a funder (high or medium). Weak evidence merged only 4 clusters. Confidence: 15,487 high, 59 medium, 2,295 low. Funder links produced 12 multi-owner clusters (several of them pairs and quadruples of wallets funded by one small wallet).

Template families. 1,479 families containing 14,185 agents; 620 span 2+ operators. 1,137 are identical content (high), 267 near-duplicate (medium), 58 trivial text (low), 9 widely shared defaults over 50 operators (4,120 agents, e.g. "only test" across 222 operators), 8 shared tool sets. White-label: 2 families (one with 9 agents under 8 names and the same three MCP tools; one "# Rift" family of 64 agents under 2 owners). A floor: only 459 agents have a tool list.

Lineage. 9,390 agents are a copy (6,979, identical content, 628 distinct parents) or fork (2,411, mean similarity 0.81, 405 parents) of an agent registered earlier by another operator.

Feedback rings. 558,897 ERC-8004 feedback events (125 revoked), 24,228 client wallets, 10,275 of which own Census agents, 5,349 reciprocal entity pairs. 14 rings containing 932 agents: 11 mutual rings (10 dense, 1 star), 2 mutual pairs, 1 intra-cluster. The largest: 131 wallets, 212 agents, 91% of the feedback they received comes from inside the group; the second: 62 wallets, 448 agents, 64%. Feedback inside rings is 4,813 events, 0.9% of all events: a concentrated phenomenon, not the norm.

What it does to the Unsolicited Ratings board. Of the 771 agents with a UR tier, 482 sit in an operator cluster (84 clusters), 437 in a template family, 629 in either, and 237 are in a feedback ring. GET /v1/ratings?collapse=clones keeps 229 of the 771 (398 hidden by an operator twin, 392 by a family twin, 542 either). Five operators account for 280 rated agents. No score or tier changed.

Precision (hand check, 22 clusters; details in the report). 0 wrong among 22; 8 independently confirmed, 7 same-registrant only, 2 true links but different users of a platform (already low confidence), 5 plausible but unconfirmed (3 shared infrastructure or transaction, 2 funder-linked). Upper 95% bound on the unflagged error rate: about 15%. The first pass of the check found six classes of false link that were fixed before this snapshot (wallet-provider endpoints, site roots, host/certificate/IP counted three times, exchange hot wallets as funders, platform minting, default texts); the corrected rules are the ones described above. Agreement with the strongest evidence (pairs sharing a key in buckets of up to 200 agents that have the same owner, i.e. agree with the registrant link): 88% for shared registration transactions (12% cross owners), 97% for exact endpoints on a company domain, 65% for endpoint host, 55% for identical text, 42% for tool sets, but only 7% for exact protocol endpoints on a tenant app: those links are almost all cross-owner, so they are where a wrong link would hide, and where the hand check looked hardest (sample items 12, 13, 14, EVM Fleet Commander). The weak signals disagree with "same registrant" 35 to 58% of the time, which is why they only corroborate. Recall is not measured: it has no ground truth.

#9. What this cannot tell you

• That two agents are controlled by the same legal person, or that clustered agents behave alike. Registrant wallets can be platforms; owners can sell agents; one operator can use many wallets we never link.
• Anything about the 144k agents whose registration file has not been fetched yet beyond wallets, transactions and the agentURI string. Coverage of content-based signals grows as the Census resolves more files; the counts above are for the day of the run.
• Recall. Operators that hide behind fresh wallets, unrelated hosts and rewritten text are not found; DNA finds sloppiness and scale, not careful adversaries.
• Funding links on Base, server-header fingerprints (we send no HTTP request for this) and MCP tool schemas (the probe stores names and description openings only).