sandbox/src/monitor/networkMonitor.ts:190-194:
return {
requestedIps: [...new Set(snapshots.requestedIps)].sort(),
requestedHosts: [...new Set(snapshots.requestedHosts ?? [])].sort(),
requestCount: snapshots.requestedIps.length,
...
};requestedIps is deduped before being returned, but requestCount is taken from the raw (pre-dedup) array length. A single long-lived TCP connection that shows up as both an ESTABLISHED row and a TIME_WAIT row after a reconnect produces requestCount = 2 even though only one host was contacted. Downstream, this feeds result.requestCount which is then written on-chain as requestIpCount (AgentAuditRegistryV2 uses this as a reputation signal).
This makes the metric noisy and developer-unfriendly — two consecutive audits of an identical agent can produce different requestIpCount values purely based on TCP state timing.
Either:
requestCount: new Set(snapshots.requestedIps).size, or- rename the field to
connectionCount and document the noise.
sandbox/src/monitor/networkMonitor.ts:190-194:requestedIpsis deduped before being returned, butrequestCountis taken from the raw (pre-dedup) array length. A single long-lived TCP connection that shows up as both an ESTABLISHED row and a TIME_WAIT row after a reconnect producesrequestCount = 2even though only one host was contacted. Downstream, this feedsresult.requestCountwhich is then written on-chain asrequestIpCount(AgentAuditRegistryV2uses this as a reputation signal).This makes the metric noisy and developer-unfriendly — two consecutive audits of an identical agent can produce different
requestIpCountvalues purely based on TCP state timing.Either:
requestCount: new Set(snapshots.requestedIps).size, orconnectionCountand document the noise.