Like Audit — Proposal at [DIS] Werra: Building Trust Infrastructure for Creator Commerce
Prepared by: @zz_tovarishch DAO Coordinator
Date: 2026-07-10
1. Background
Some community members raised a concern that the like count on this proposal did not look organic. As the DAO coordinator, I reviewed the likes using forum administrative data. This note documents only the likes that failed verification and the basis for disqualifying them.
Accounts are identified by their numeric forum user ID. Usernames, email addresses, and full IP addresses are withheld here to avoid exposing personal data and to keep the assessment free of identity bias; the coordinator retains the complete mapping and can make it available to the committee for independent verification. Any DAO member may request to review the basis for this action. Members are provided with the pseudonymised evidence record (account IDs, network-linkage labels, timelines, and activity metrics — the same form as this note), which is sufficient to verify the reasoning and the pattern. Raw personal data (email addresses, full IP addresses) is not redistributed.
2. Headline finding
The first post received 33 likes. Of these, 18 are attributable to a single coordinated operation. Eleven of the eighteen are linked at the network level, and eight of them share an IP address with the proposal author’s own account. The remaining 15 likes were reviewed and show no signs of coordination. They are highly potentially genuine and are not listed here.
3. Method and data sources
Signals were drawn from the forum’s administrative records: account creation timestamp, registration IP, last-seen IP, trust level, and activity metrics (days visited, topics entered, posts, total read time). Discourse assigns user IDs strictly in registration order, so ID adjacency is a direct measure of registration sequence. IP addresses are referenced by label (IP-1, IP-2) to demonstrate that accounts share an identical address without publishing the address itself.
4. Evidence
Cluster A — linked to the proposal author by shared IP
Eight liking accounts are tied to the proposal author’s own account through a shared IP address. Seven of them, together with the author, resolve to a single hub address (IP-1). An eighth (ID 4265) instead shares the author’s registration IP and was created on the very next user ID after the author (4264 → 4265), i.e. registered back-to-back from the same connection. Five of the eight were registered weeks to months before the proposal; their sessions nonetheless trace back to the author.
| User ID | Registered (UTC) | Trust level | Total read time | Days visited | Posts | Link |
|---|---|---|---|---|---|---|
| 4259 | 2026-04-25 | 1 | ~6.0 h | 48 | 12 | last-seen IP-1 (pre-aged) |
| 4265 | 2026-05-06 | 1 | ~5.1 h | 22 | 6 | author’s registration IP; consecutive ID 4264→4265 (pre-aged) |
| 4308 | 2026-06-14 | 1 | ~40 min | 3 | 0 | last-seen IP-1 |
| 4309 | 2026-06-14 | 1 | ~2.5 h | 23 | 4 | last-seen IP-1 (pre-aged) |
| 4312 | 2026-06-20 | 0 | ~21 min | 5 | 0 | last-seen IP-1 |
| 4360 | 2026-07-07 | 0 | ~8 min | 2 | 0 | registered + last-seen IP-1 |
| 4361 | 2026-07-07 | 0 | ~5 min | 1 | 0 | registered + last-seen IP-1 |
| 4364 | 2026-07-09 | 0 | ~10 min | 1 | 0 | last-seen IP-1 |
Cluster B — shared registration IP (IP-2)
Three accounts were registered from one single IP address (IP-2) within roughly one hour of each other on the same day.
| User ID | Registered (UTC) | Trust level | Total read time | Days visited | Posts | Link |
|---|---|---|---|---|---|---|
| 4367 | 2026-07-09 13:40 | 0 | 26 s | 1 | 0 | registered IP-2 |
| 4368 | 2026-07-09 14:29 | 0 | ~2 min | 1 | 0 | registered IP-2 |
| 4369 | 2026-07-09 14:40 | 0 | ~1 min | 1 | 0 | registered IP-2 |
Cluster C — same-burst behavioral signature
Seven further accounts were registered inside the same 48-hour window and share an identical profile: trust level 0, public profile hidden, one day visited, zero posts, total read time from tens of seconds to a few minutes, and disposable free-webmail addresses following one naming pattern. These accounts carry no direct IP link to Clusters A and B, but their user IDs are interleaved with the IP-confirmed accounts inside the same unbroken registration run (4360–4374), i.e. they were created back-to-back in the same batch. On that basis they are grouped here as pattern-consistent, with lower individual confidence than Clusters A and B.
| User ID | Registered (UTC) | Trust level | Total read time | Days visited | Posts |
|---|---|---|---|---|---|
| 4365 | 2026-07-09 | 0 | 46 s | 1 | 0 |
| 4366 | 2026-07-09 | 0 | ~10 min | 1 | 0 |
| 4370 | 2026-07-09 | 0 | ~22 min | 1 | 0 |
| 4371 | 2026-07-09 | 0 | ~1 min | 1 | 0 |
| 4372 | 2026-07-09 | 0 | ~5 min | 1 | 0 |
| 4373 | 2026-07-09 | 0 | ~2 min | 1 | 0 |
| 4374 | 2026-07-09 | 0 | ~13 min | 1 | 0 |
Cross-cutting signals
-
Consecutive registration. Thirteen of the eighteen accounts occupy the near-contiguous user-ID band 4360–4374. Because IDs are issued in registration order, this means the accounts were created back-to-back with essentially no unrelated registrations in between — a batch-registration signature.
-
Timeline. The proposal was posted on 2026-07-02. The thirteen burst-registered accounts were all created on 2026-07-07 and 2026-07-09, i.e. after the proposal, then used to like it. The five Cluster-A pre-aged accounts were created between April and June and pre-warmed to look organic.
-
Engagement. Every flagged account is trust level 0 or 1, with one day visited and no posts (aside from the pre-aged accounts’ minimal activity). None shows the browsing footprint of a genuine participant.
5. Limitation
The IP addresses in Clusters A and B fall in mobile/ISP ranges where carrier-grade NAT can place multiple unrelated users behind one address, so “same IP” is, on its own, weaker in this region than on fixed broadband. That caveat does not rescue these accounts: the proposal author’s own account sits on IP-1; several accounts use IP-1 as both their registration and last-seen address across a span of months; the Cluster-B trio share a registration IP within a single hour; and all of this coincides with consecutive user IDs and an identical low-engagement profile. The innocent-coincidence explanation would require the author and their supporters to repeatedly share carrier addresses over months while also registering in sequence and behaving identically.
6. Precedent
The Nervos forum has handled this before. In Growing the Italian ecosystem (talk.nervos.org/t/growing-the-italian-ecosystem/7707), the community identified a set of accounts that
, and the likes from those duplicate accounts were removed and the post closed so that the tally reflected genuine support.
The pattern there is the same one documented above.
7. Conclusion
The evidence above establishes, to a high degree of confidence, that 18 of the 33 likes originate from a single coordinated operation rather than from independent community members.
At this stage, the DAO’s metarules contain no explicit provision on coordinated or duplicate likes during the discussion phase, and the coordinator holds no authority to invalidate support by fiat. This conclusion, therefore, does not rest on the coordinator’s discretion. It rests on (a) the documented evidence and (b) the DAO’s own prior practice.
On that basis, the 18 likes in Clusters A, B and C would not be counted toward this proposal’s support.
Scope of this audit
This audit was initiated solely because a specific, evidenced concern was raised about this proposal while it was in its discussion window. It does not create a standing or proactive audit, and it places no obligation on the coordinator — or anyone else — to screen other proposals for the same patterns.
Consistent with the prior practice it relies on, which was itself triggered by community members raising the issue in-thread, this kind of audit is concern-driven only.
It is likewise not retroactive. Proposals whose discussion window has already closed without such a concern being raised are treated as settled and are not reopened on this basis.
This case also exposes a gap: there is no explicit anti-Sybil or duplicate-like clause at this stage of the process. Closing that gap in the meta-rules would remove the need to rely on precedent in future cases.