TERRA VALIDATOR VOTING: TIMING AND CHOICE CONGRUENCE Method version: 23 October 2026 Purpose ------- Identify repeated close voting, consistent nonzero delays, and sequential management patterns across ALL identified validator accounts in the available chain vote corpus. The target corpus is Phoenix-1 genesis to latest indexed block, not merely a hand-picked set of validators or contentious proposals. Coverage is reported separately and can be substantially smaller while older transactions are being collected. Do not call a partial result an all-history finding. Input and evidence ------------------ The collector supplies successful Cosmos governance vote events with exact proposal IDs, voter addresses, choice/weighted-choice vector, block height, block timestamp, transaction hash, nested-message path, top-level signer(s), authz grantee(s), and source/explorer URL. Raw response files are retained by the collector. A vote nested in MsgExec belongs to its declared voter; the executor is recorded separately. Failed transactions are excluded. Staking operator addresses are converted by Bech32 payload from terravaloper to terra and the checksum is regenerated, not by textual prefix substitution. Every conversion validates the source checksum. Current monikers are labels, not a claim that the present brand owned that validator throughout history. Current bonded/unbonded status is not applied retrospectively. Historical validator creation, edit and active-set records are separate identity evidence. Genesis monikers and dated Create/Edit messages are accepted as optional inputs. Outputs preserve current name, genesis name and the last observed name by each vote's date separately. A partial list of edits is not a complete label history and a label change does not itself prove a change of beneficial owner. Only explicit validator-account votes enter validator-pair statistics. Delegator votes do not become validator votes because stake is delegated to that validator. They remain in the collection but outside these metrics. The analysis writes SHA-256 hashes of its inputs. Regeneration after corpus expansion produces a new result; preserve earlier input/result snapshots when using them as evidence. Ballots and denominators ------------------------ FIRST: earliest observed successful vote by that validator on that proposal. LAST: latest observed successful vote. This is the final chain ballot only if the complete proposal vote history has been collected. Every later vote and choice change remains in raw events. Both versions are analysed separately. Choices are canonical exact weighted vectors; ABSTAIN and NO_WITH_VETO are not YES, and no ballot is not ABSTAIN. One denominator is each pair's co-voted proposals. Also show each validator's total observed proposals and the Jaccard participation overlap. Report dates of observed activity overlap; this is not proof of historical active status. Do not calculate congruence against all chain proposals while silently treating nonparticipants as disagreements, agreements or deliberate abstentions. Pair measurements ----------------- For every pair with at least one co-voted proposal: * same exact choice count / co-voted count; * Wilson 95% descriptive interval for the observed same-choice fraction; * same-block and same-transaction counts; * absolute inclusion-time separation <=30s, <=60s, <=5m, <=15m and <=1h; * signed lag B minus A, median, median absolute deviation (MAD), interquartile range, 10th/90th percentiles and median absolute lag; * A-before-B, B-before-A and timestamp ties. Ties cannot establish an order; * mean-rank gaps within each proposal's observed validator ballots; * actual shared authz executor and common top-level signer counts; * all proposal IDs and per-proposal linked transactions, including exceptions. Nonzero offsets and schedules ---------------------------- For each pair, find the densest lag interval of widths 60s, 120s, 600s, 1800s, 7200s (half-widths +/-30s, +/-60s, +/-5m, +/-15m, +/-1h). The interval may lie anywhere on the signed lag axis, including hours or days away from zero. Its midpoint is the reported centre; its median is a separate field. A 5-minute half-width is a 10-minute-wide learned interval, NOT the same as the <=5-minute proximity count around zero. Also explicitly count B about one hour after A, or A about one hour after B, with +/-5-minute tolerance. Low lag dispersion and consistent ordering are reported even when timestamps are not adjacent. Per-validator circular phase statistics show concentration by UTC time of day, hour, five-minute interval and minute. They are exploratory schedules. A public notification, shared shift, polling timer or common software can create these patterns without common signing control. Block timestamps are inclusion times, not precise signing, submission or decision times. Chronology and groups --------------------- Yearly and quarterly pair summaries show whether patterns persist or arise only during a particular period. An exploratory change screen chooses the largest difference in <=60s or <=5m timing rates across chronological splits with at least five co-voted proposals on either side. Only changes of at least 50 percentage points are written. These are observed candidate breakpoints, not dates when control changed; missing data or a different mix of proposal types can create such a difference. Complete per-proposal evidence supports further rolling windows as the historical corpus grows. Candidate triples require every pair to have a repeated concentrated lag pattern, then the same checks are repeated on the three-way common-proposal intersection. A-B and B-C proximity alone cannot label A-C as coordinated. For the complete triple, report total span, exact order including ties, most common order and its frequency. Changing order is stated, not hidden. This is a candidate-group screen, not an ownership classification. Baselines and sample size ------------------------- On each proposal compute the same-choice and close-time fractions across all observed validator pairs. Summing these proposal-specific rates gives a network reference for a pair's actual set of co-voted proposals. Thus consensus YES votes on popular upgrades are not automatically described as unusual. For an exploratory shortlist, shuffle timestamp assignments within EACH proposal and exact-choice stratum while preserving that proposal's active voter labels and observed timestamp distribution. This preserves network vote bursts, deadline surges, proposal timing, choice popularity and participation. Record a fixed random seed and repetition count. Compare close-time count and the learned densest-offset count after repeating the same lag search. These shuffle exceedance fractions are reference diagnostics, not a formal claim of statistical significance: pairs were selected after examining the data, many pairs/windows were searched, and individual operators' persistent work schedules are not preserved. Do not describe a low fraction as proof of collusion. A stronger follow-up is preregistered testing on newly arriving proposals or splitting early-history training from later-history holdout data. At least 10 co-voted proposals is the preferred screen for an enduring pattern; all smaller samples are explicitly flagged. Ten is a practical reporting threshold, not a magical proof threshold. A pattern on all six available proposals can be interesting but cannot support 'on every proposal in history.' Interpretation ladder --------------------- 1. Similar choices: alignment, often ordinary consensus. 2. Repeated narrow timing or stable offsets: shared process / automation lead worth investigating. Does not identify the process, owner or intent. 3. Shared message execution or current vote authorization: direct operational link. Distinguish granted capability from historical use. 4. Common authorized executor actually votes for multiple validator accounts: direct evidence of common execution authority for those transactions. 5. Independently sourced ownership/custody declarations can establish entity relationships. Timing alone never supplies this missing identity evidence. The same transaction may carry independently signed messages. An authz grantee may be a disclosed service. A shared reward destination may be a treasury or custodian. Operational links are material even where ownership remains open. Existing Max Power packet ------------------------- The previous file is gauge/incentive evidence, not Cosmos validator governance. Its verified close votes and two-vault bot authority remain useful context but must not be merged into validator congruence denominators. The prior audit corrected a claimed same-minute 100% bot pair: its transactions were 83 seconds apart and allocation vectors differed. The chain governance analysis begins with the new transaction corpus. Reproduction ------------ python3 analyze_votes.py --votes ../collection/votes.json \ --validators ../entities/validator_identities.json \ --proposals ../collection/proposals.json --out results \ --genesis ../entities/genesis_validators_verified.json \ --moniker-history ../entities/dated_validator_monikers.json \ --permutations 1000 --permutation-pairs 100 --seed 20261023 python3 test_analysis.py Outputs: all-pair JSON/CSV, proposal-level linked evidence CSV, quarterly segments, candidate triples, validator schedule profiles, network baselines, shared execution records, identity map and a hashed-input coverage summary. Seven checks cover address/checksum conversion, timestamp precision, a fixed one-hour offset with outlier, lag-window bounds, first-versus-later ballots, historical name chronology, and a supported before/after timing change. FULL-HISTORY ADDENDUM The final census covers 231 historical operators, but the vote ledger is not an active/bonded-validator census at each height. Use "historically registered validator accounts". Any Wilson interval in the raw tables is a nominal descriptive binomial calculation only: proposal observations are dependent, and the enumerated corpus is not an independent random sample. The threshold 10 is a preferred screening minimum, not a statistical guarantee of robustness. No inferential probability of collusion is estimated. The session_check.py sensitivity check groups each account's consecutive selected vote events with gaps <= 1,800 seconds, then separately <= 21,600 seconds. Pair observations sharing a tuple of account session IDs count once, using median lag. This checks proposal-batch dependence; it does not guarantee independence of the resulting sessions. Triple summaries count tuples of all three account session IDs. Joint lag-band matches are reported separately from the minimum of individual pair match rates.