This script treats DLTs like Radix and Ethereum like engines and attempts to measure their efficiency in creating utility.
Introduction
Mechanical efficiency is measured by dividing Work or Power Output by Power Input:
η = W / I = Work (or Power) Output ÷ Power Input
The following method substitutes Github repos for Work and Google Trends volume as a measure of Power Input. The assumption is that amount of ecosystem activity will be roughly reflected in the search volume.
In this version, the number of Github repos for Radix and Ethereum is determined using the comparable search terms “Scrypto Radix” and “Solidity Ethereum”. The search volumes for “Scrypto Radix” are not large enough to register so instead we have used “XRD Radix” and “ETH Ethereum” to maintain equivalence and eliminate searches for other uses of the term ‘Radix’.
Results
The figures below are a single snapshot taken on 14 July 2023 and are preserved as a record of that run. Both inputs move continuously – GitHub repository counts grow and Google Trends rebases its scores against whatever window is queried – so re-running the script today will produce different absolute numbers and ratios. As of August 2026 it also produces no Radix row at all: the section Status of the method, below, records a re-run of the script and what broke.
DLT | Repos | Efficiency (η) (23/07/14) | Vs Ethereum | Search terms (Github) | Search terms (Google Trends) |
12461 | 8.45 | 1 | “Solidity Ethereum” | “ETH Ethereum” | |
1076 | 0.79 | 11x | “Rust Solana” | “SOL Solana” | |
Avalanche | 88 | 0.09 | 91x | “Solidity Avalanche” | “AVAX Avalanche” |
Cardano | 176 | 0.09 | 97x | “Plutus Cardano” | “ADA Cardano” |
Radix | 21 | 0.07 | 123x | “Scrypto Radix” | “XRD Radix” |
Method & Python Script
Install VS Code: https://code.visualstudio.com or another IDE.
In VS Code open a new terminal window by navigating to Terminal > New Terminal.
Install Homebrew by pasting the following code into the terminal and pressing Enter:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"Install Python in the same way:
brew install pythonNext, install the modules that the script needs (dependencies). The script imports
tqdmfor its progress bar as well asrequestsandpytrends, so all three go in:pip3 install requests pytrends tqdmNow, create a project folder and navigate to it in VS Code via File > Open Folder.
Create a new Python file in VS Code via File > New File. Name it something like DLTefficiency.py
Copy and paste the following script into DLTefficiency.py and save it.
# v.0.0.3 import requests from pytrends.request import TrendReq from concurrent.futures import ThreadPoolExecutor from tqdm import tqdm # Function to get the number of Github repositories for a search query def get_github_repo_count(session, search_query): url = f"https://api.github.com/search/repositories?q={search_query}" try: response = session.get(url) response.raise_for_status() return (search_query, response.json()['total_count']) except requests.exceptions.HTTPError: return (search_query, None) # Function to get the worldwide popularity score from Google Trends for a search query def get_google_trends_score(pytrends, search_query): pytrends.build_payload([search_query], timeframe='today 1-m') interest_over_time_df = pytrends.interest_over_time() if not interest_over_time_df.empty: return (search_query, interest_over_time_df[search_query].sum()) else: return (search_query, None) # Function to calculate efficiency score for a search query def calculate_efficiency_score(session, pytrends, search_query_pair): github_search_query, google_trends_search_query = search_query_pair with ThreadPoolExecutor(max_workers=2) as executor: github_future = executor.submit(get_github_repo_count, session, github_search_query) google_future = executor.submit(get_google_trends_score, pytrends, google_trends_search_query) github_repo_result, google_trends_result = github_future.result(), google_future.result() if github_repo_result[1] is not None and google_trends_result[1] is not None: return (search_query_pair, github_repo_result[1] / google_trends_result[1]) else: return (search_query_pair, None) # Main program to calculate efficiency scores for different search queries search_queries = [("Rust Solana", "SOL Solana"), ("Plutus Cardano", "ADA Cardano"), ("Solidity Avalanche", "AVAX Avalanche"), ("Scrypto Radix", "XRD Radix"), # ("wasmRun the script from the terminal with:
python3 DLTefficiency.pyStatus of the method (August 2026)
The script above was re-run in full on 13 August 2026, in a clean virtual environment, to check whether it still works. It does – with one exception, and the exception is Radix.
The Radix search term has expired
Google Trends returns nothing for "XRD Radix". The query falls below the threshold at which Trends will report a series at all, so interest_over_time() hands back an empty frame, get_google_trends_score() returns None, and the script prints Error calculating efficiency score for 'Scrypto Radix' and 'XRD Radix' – the one row this page exists to produce. It is not rate limiting: in the same session, over the same one-month window, Radix returned 1,441, XRD 1,623, ETH Ethereum 895 and SOL Solana 1,229, and only the two-word Radix conjunctions came back empty.
This is the same failure the 2023 run had already worked around one step earlier. That run found "Scrypto Radix" too small to register and substituted "XRD Radix" to keep the comparison equivalent; three years on, the substitute has gone the same way. "Radix DLT" still registers – 100 over the same window – and preserves the disambiguation the original pairing was chosen for, so it is the term the script needs today.
A 2026 reading
With that single substitution the script completes. Run on 13 August 2026, GitHub counts read from the Search API and Trends scores summed over a one-month window:
| DLT | Repos (2026) | Repos (2023) | Trends score | Efficiency (η) | Vs Ethereum (2026) | Vs Ethereum (2023) |
|---|---|---|---|---|---|---|
| Ethereum | 18,275 | 12,461 | 895 | 20.42 | 1 | 1 |
| Solana | 4,553 | 1,076 | 1,229 | 3.70 | 6x | 11x |
| Cardano | 268 | 176 | 1,239 | 0.22 | 94x | 97x |
| Avalanche | 201 | 88 | 972 | 0.21 | 99x | 91x |
| Radix | 40 | 21 | 100 | 0.40 | 51x | 123x |
Read the Radix row with care: it is the only one whose Trends term changed between the two runs, so its 2023 and 2026 figures are not measuring the same thing and the move from 123x to 51x is not a like-for-like improvement. The other four rows kept both of their search terms. What is directly comparable across the two runs is the GitHub side, which uses fixed queries: repositories matching “Scrypto Radix” went from 21 to 40, against Ethereum’s 12,461 to 18,275.
What the metric can and cannot carry
Two limits are worth stating plainly, because they bound how much weight any version of this table will bear. The first is in the method: build_payload is called with a single keyword at a time, and Google Trends scales every series to 100 at its own peak for the window queried. Each score is therefore normalised against that term’s own maximum, not against the others, so the denominator compares the shape of each chain’s attention rather than its volume. The second is the failure documented above: a term small enough to fall under the reporting threshold returns nothing rather than a small number, so the metric stops working precisely where the answer would be most interesting.
pytrends is no longer maintained
The Google Trends dependency is a community reverse-engineering of an endpoint Google does not publish, and it has stopped being maintained. GeneralMills/pytrends is archived and read-only: its last code commit landed 22 April 2023, its README asks for maintainers, and 152 issues are open behind the freeze. The latest release on PyPI is 4.9.2, published 13 April 2023. It installed and ran cleanly for the figures above, but nothing will fix it the next time Google changes the endpoint – the README says as much.
