There are two ways a repository can be counted as a blockchain repository:

We tie each technology (a language or a package) to an ecosystem. For example, Solidity maps to EVM, CosmWasm to Cosmos, and Anchor to Solana. This lets us lift the per repository technology information up to the ecosystem level that people think in.

Of course, a repository can include multiple packages or languages from different ecosystems. Then, it is counted for all these ecosystems and it becomes a “multi-ecosystem repository”.

This identification is not complete, since it is possible for a repository of a blockchain to not use any SDK or language of this ecosystem, but still be building on top of it. For instance, an indexer that reads directly from an external REST API may lack any packages of this particular blockchain, but it is of course a repository of this ecosystem. Unfortunately, there is no perfect solution to this problem, but we continuously improve BDR by solving more and more edge cases of such each day.

On the contrary, this method is almost always correct, meaning that a repository that uses a blockchain language or related package is a blockchain repository excluding some unnatural edge cases. As a result, you can conclude that all numbers on BDR are a tight lower bound on real statistics of an ecosystem.

Nevertheless, we do not want this identification to undermine the value that BDR creates: We continuously scan the entire public repository archive, which is again more than 339 millions, and find the most exotic and indie blockchain repos out there to include in our metrics. Moreover, we almost never give false positives, thus all metrics we have cover virtually every public blockchain repository and developer except a small percentage. This is by far the best analysis tool that is built for the blockchain developer ecosystem.

The first important limitation is private to public repository change. If a repository was created as private, and then made public, it may take some time for us to find this repository. There is no magical API returning “just-made public” repos, so we need to resync our data set continuously to make sure we never miss something. This is not an important limitation in most times, since we resync our data often enough to minimize the effect.

Another equivalent situation is public repositories that start using blockchain long after their first commit. For instance, a big repository may decide on integrating blockchain years after the launch of a project (this is rare, but it happens). These repositories also fall in a similar category with previously private repositories, but are actually harder to catch. In particular, we do not retry all repositories continuously, so if a repository includes blockchain technologies looong after it is created, then BDR has no ways of automatically identifying this repo. Nevertheless, it is important to note that this is only true in exceptionally long delays, so even if a repository includes a blockchain a month or a year later it has been created, we include it until the end of the next search epoch. Moreover, you can always send us an email for us to recheck and include a repository.

Both these limitations mean that BDR data is never finalized, and even the data from a very old date may be changed any time. Of course, the probability of this happening decreases over time. However, let us describe such a scenario with a very possible example. Think that a company was building a financial product over Ethereum with Solidity, and they built a huge repo with thousands of commits. However, they preferred keeping their code private, and even if they were building from 2020, their involvement was not reflected on BDR. Then, they move their repo to public in 2026, and all of a sudden a commit history of 6 years enters the Ethereum ecosystem data on BDR. Thus, all general and EVM stack related statistics of BDR get updated from 2020 to 2026. This scenario is very plausible, and it describes well how BDR data can be updated retroactively any time.

A final remark is on the habits of programmers. As it is known, not all developers push their commits to their public repository at the end of each day. Moreover, commits get merged to the main branch even less often, and we only count a commit once it is pushed to the main branch. As a result, there is a natural delay in the results that BDR shows. When you observe last week’s statistics, you will notice that it will increase significantly in the coming weeks. Of course, this increase follows a logarithmic trend over time. Nevertheless, it is an important limitation for researchers looking to learn about a specific date, and you should consider a data point safe to use only after giving it at least a week. This is of course not a limitation of our software, but the very nature of how building works. Not everything is published as it is built.

Once a repository is confirmed as a blockchain repository, we collect its commit history: who wrote how much code and when.

We distinguish developers by their GitHub accounts. A single person's contributions across different repositories are merged under one developer. This has two important consequences:

We also have a simple check to prevent artificial inflation: if an abnormal number of commits pile up in a very short time right after a repository is created, we treat that repository as suspicious and leave it out of the count. Then, our team continuously checks such repositories by hand and tries to understand if it is a valid contribution or not.

We do not collect a repository once and forget it; we revisit it at regular (approx. a few hours) intervals and add new commits, so the data stays current. In contrast to repositories, our commit data is both complete and correct, meaning that we rarely miss a commit belonging to a repository that we have matched as a blockchain repository. Nevertheless, there may always be some delay before we include a new commit.

Finally, there is an important limitation of this approach, that we consider as a feature rather than a bug. If a developer is working on a blockchain repository, but is not writing any blockchain related code at all (which is quite often the case in mono-repo projects), we still count their commits as “blockchain related”. The idea here is that if a developer is working on a blockchain project, their work is a part of this ecosystem in some way or another. However, this situation is important to highlight: For instance, the number of active developers in the EVM stack does not give the number of Solidity developers. It is possible that most commits included as EVM do not contain any Solidity or Ethereum related code, but it is certain that all commits counted were submitted to a project that is building on the EVM stack.

We produce developer metrics from the raw commit data we collect. The core idea here is this: to count a developer as "active" on a given day, we do not look only at that day but at the last 28 days. Because we measure sustained activity instead of a single day's snapshot, the numbers are more stable.

With the same logic, we break developers down by how regularly and how long they have been active, and we compute these at the level of each ecosystem, each technology, and the total (global) level. On top of that, we also produce metrics such as the number of developers joining and leaving, along with retention rates.

You can find details of each graphic in the information icons it has. The most basic form of our data is the information of how many commits a developer has sent to each ecosystem for each day. All other information may be derived from this simple format.

Finally, the developer location is collected directly from reported locations of developers in their GitHub profile page. Since many developers do not share such data or write hard to interpret information such as “over the clouds”, this data is far from being complete. Moreover, we have no claim over its accuracy, since developers are free to report any location of their choosing. Nevertheless, we give a nice visualization of over 100,000 developers’ reported locations on BDR, which we believe may be important and accurate enough in most applications.

There are two separate rhythms:

The published numbers cover the period from the start of 2020 to today. Even though we collect raw data going back to 2014, we deliberately start the published figures from 2020.

There is an enormous amount of public data online, and we believe it is vital that we make the best out of it. This of course does not mean that “anything public out there is to be indexed”, but we think the core of open source development is being able to reach people with your code. BDR is built to this end: allowing developers to reach people.

Our methodology and methods will definitely evolve over time, as BDR is used more and our date becomes more meaningful. Our ask from you is to be in contact with us, and tell us what we can do better or different. BDR is built for the blockchain ecosystem, for sure, but it is built for developers before anything.

We thank all developers that made their code public and BDR possible.