Builders First

• Pre-registration: I wrote down each claim and the result that would disprove it, and committed them before pulling any data.
• Developer activity comes from GH Archive, a public record of GitHub events. A monthly active developer (MAD) is a GitHub account that pushed code or opened a pull request in one of an ecosystem's repos that month. The repo lists come from Open Dev Data by Electric Capital.
• C1 compares the share of new developers still active 3, 6 and 12 months later, NEAR against the median of Solana, Sui, Aptos and Base, for monthly cohorts from 2022-01.
• C2 uses Granger tests, which ask whether past values of one series improve forecasts of another, on monthly changes in NEAR MAD and contract deployments at lags 1 to 6. With six tests, a Bonferroni correction (dividing the 0.05 significance level by the number of tests) sets the bar at p < 0.0083.
• C3a divides monthly contract deployments by MAD. C3b checks every hackathon commit author for earlier NEAR activity in GH Archive and in their GitHub event feed, and counts commits that carry AI co-author trailers.
• GH Archive's own volume breaks in 2025-06 and collapses after 2026-02. A coded rule stops the series at 2026-02, and I re-ran C2 and C3a on coverage-adjusted MAD.
• Data as of: GH Archive (GHA, a public record of GitHub events) usable through 2026-02 (coverage rule); NEAR contract deployments through 2026-11 (current month partial; C2 and C3a use months through 2026-02 to match GHA); hackathon cohort fetched 2026-11-12; Open Dev Data commit d664cfa.

I logged these in the order I made them. Where the order of a decision and the data matters, I give commit hashes so it can be checked with git log.

1. Ecosystem names (2026-11-12). Open Dev Data calls them NEAR, Solana, Sui, Aptos and Base; I included all sub-ecosystems. Base is in the taxonomy, so it is the EVM L2 peer. The taxonomy is pinned to the commit recorded in data/cache/ecosystems_meta.json. I call the package's taxonomy module directly, which runs the same code as open-dev-data export.

2. GH Archive window (2026-11-12). I started the history at 2021-01, not 2019-01, to fit the BigQuery sandbox budget (dry-run costs are in sql/COSTS.md). A developer active before 2021 who returns in 2022 can therefore count as new in early cohorts. Cohorts still start at 2022-01, so each has at least 12 months of look-back.

3. Developer identity and events (2026-11-12). A developer is the GH Archive actor.login of a PushEvent or PullRequestEvent (any action) on an ecosystem repo. Counting merged pull requests only would mean reading the large payload column for every month, which the budget did not allow. Electric Capital counts original commit authors, so my absolute numbers differ from its Developer Report, while trends are comparable. I removed bot logins by pattern ([bot], -bot, dependabot, github-actions, renovate).

4. NEAR deployments (2026-11-12). Deployments come from transaction_actions (action_kind = 'DEPLOY_CONTRACT', signed directly by an account), not receipt_actions, which would cost about 3× more to scan. This excludes contracts created by factory contracts, and I chose that on purpose, not only to save cost. A transaction-level deployment is an account shipping code it chose to ship, which is a developer action. Factory deployments (DAO, token and meme-coin factories) are mostly end users pressing a button in someone else's app. They measure that app's popularity, and one viral factory can add thousands of deployments in a month. The bias runs the other way too. The series undercounts teams that deploy through their own factory or a deployer contract (some upgrade or multisig flows), and it counts redeploys of the same contract separately. If developers shifted toward factory-style deployment over time, the series would fall even if output did not. Unique deployers are distinct signer_account_id values. The NEAR BigQuery dataset was current (latest block_date 2026-11-12 at fetch time), so I needed no RPC back-fill.

5. Incomplete months (2026-11-12). The current calendar month is partial, so I excluded it from every monthly series and from cohort follow-up.

6. C3a threshold (2026-11-12). The pre-registration did not define "flat" numerically. I fixed it: C3a holds only if mean monthly contracts per MAD from 2025-01 is more than 10% above the 2023-01 to 2024-12 mean. I report a Mann-Whitney test alongside, but it is not part of the criterion.

   Order of events: I committed the threshold in 4d4fc58 (2026-11-12 20:01:34 UTC). That was before the developer-activity data commit 3cefe2f (20:04:15 UTC) and before I had computed or looked at any MAD figure. It was not before all data existed. I had already downloaded and printed the NEAR deployment series (the numerator, 48ddb53), and four of the six GH Archive raw chunks (2021 to 2024) had been written to data/raw/ about a minute earlier, unopened. The 2025 and 2026 chunks, which hold the whole post-period, arrived after the commit.

7. C3b cohort (2026-11-12). Repos come from nearhunt.xyz entries that link a GitHub repository. Commits are from each repo's default branch, from 2026-10-19T00:00Z to the fetch time. Commits whose author has no linked GitHub account are left out of author counts but kept in the AI-trailer share. Prior NEAR activity is defined in item 9. The committed activity cache stores logins as unsalted SHA-256 prefixes, and I compare those hashes.

8. GH Archive coverage breaks (2026-11-12, found after download). GH Archive's own volume is not stable. An event-type breakdown (data/cache/gha_type_volume.csv, data/cache/gha_pushpr_volume.csv) shows push volume falling about 30% in 2025-06 and staying lower, and pull-request volume collapsing from 2026-03 to 2026-08 before pushes also fall in 2026-09. The breaks are in the source and hit every ecosystem, so they lower measured developer counts with no change in real activity. I responded in code (stats.py) in two ways.

   • Cutoff. A month is good if push and pull-request volume are both at least 80% of the median of the 12 months before it. Series based on GH Archive end at the month before the final run of failing months (stats.last_good_month), and later months are excluded from MAD, retention follow-up, C2 and C3a. I chose the 80% threshold after looking at the GH Archive volume series only, not at any ecosystem's numbers. The dashboard charts push and pull-request volume with the cutoff marked.
   • Coverage-adjusted MAD. A failing month before the cutoff marks a level break. From that break on, I divide monthly MAD by push plus pull-request volume relative to the median of the 12 months before the break, capped at 1 (stats.coverage_factor). This assumes developers are lost in proportion to events, which over-corrects (developers with few events are lost first), so it is a conservative test. C2 and C3a are computed on raw and adjusted MAD and shown side by side. If a claim's result differs between raw and adjusted, I report it as FRAGILE, and a fragile claim does not count toward the verdict.
   • Budget. I ran these two volume queries once each, within the budget I set (sql/COSTS.md).

9. C3b uses two sources (2026-11-12). The coverage drop would make some returning NEAR developers look new, which would favour C3b. An author counts as new to NEAR only if both sources show no NEAR-ecosystem activity before 2026-10-19. The first is GH Archive from 2021-01 to 2026-10-18 (monthly tables to 2026-09, daily tables for 2026-10-01 to 2026-10-18). I still use the incomplete late-2026 months here, because more data can only move authors from new to returning. The second is the author's public GitHub event feed (/users/{login}/events/public), which covers about the last 90 days and at most 300 events, checked for push or pull-request events on NEAR-ecosystem repos before 2026-10-19. Very active authors can hit the 300-event cap before the feed reaches 2026-10-19. I report how many did, and I show the C3b share both with all authors and with capped, truncated authors excluded. The kill criterion uses the lower of the two shares.

• Deploys → developers (the reverse of C2, raw MAD, log-differenced): Granger p-values lag 1: 0.948, lag 2: 0.012, lag 3: 0.021, lag 4: 0.014, lag 5: 0.026, lag 6: 0.022. Bonferroni threshold across 6 lags: 0.0083. No lag survives the correction, so this is a hint, not a finding. It was not pre-registered and has no effect on the verdict.
• C2 out-of-sample check (fit to 2024-12, one-step forecasts after): adding lagged MAD changes forecast RMSE by a factor of 1.36 for deploys and 1.03 for unique deployers (below 1 would mean developers help predict usage).

• GHA volume breaks in 2025-06 (pushes fall about 30%) and collapses after 2026-02 (pull requests, then pushes). Series end at 2026-02; C2 and C3a are also run on coverage-adjusted MAD, and disagreements would be reported as FRAGILE.
• Developer identity is the GHA actor of a push or PR on a repo listed in Open Dev Data. Electric Capital counts original commit authors, so levels differ from the Developer Report. Private repos and unlisted repos are invisible.
• I started the history at 2021-01 to stay within the BigQuery budget, so some developers counted as new in 2022 had been active before 2021.
• Deployments are transaction-level DEPLOY_CONTRACT only. I excluded factory-created contracts on purpose (THESIS.md, Methodology changes, item 4).
• C3b covers 367 repos with a GitHub link out of 678 nearhunt.xyz projects (764 official submissions); 1,500 commits had no linked GitHub account. 16 authors hit GitHub's 300-event feed cap; 11 of them have feeds that stop after 2026-10-19 and are shown both included and excluded.
• AI co-authorship is detected from commit trailers only, a lower bound. The repo share uses repos with at least one non-bot commit (366 of 367); 1 repo's only author has a login ending in "-bot" and is removed by the bot filter.
• I fixed the C3a threshold (>10%) after I had seen the deployment series. THESIS.md, Methodology changes, item 6, gives the exact order of events with commit hashes.