Freedom Score Methodology
How we assess decentralisation in AI projects. Six dimensions, scored criteria, and why the exact number matters less than the reasoning behind it.
Every crypto project claims to be decentralised. Most are not. The Freedom Score is our attempt to cut through the marketing and assess how much sovereignty a project actually delivers to its participants.
The score measures one thing: how much control do users, contributors and tokenTokenA digital unit of value or access rights tracked on a blockchain. Tokens can represent ownership in a project, a right to use a service, a share of future revenue, or simply a tradable asset with no underlying claim.Like a physical poker chip a casino issues. The chip itself has no value. What makes it worth something is what it lets you do at the casino, what the casino has promised, and how much other people will pay you for it.Read more → holders genuinely have, versus how much remains with a founding team, company or foundation? A project that calls itself decentralised but runs permissioned infrastructure, holds majority token supply, and makes all decisions through a three-person team gets scored accordingly. We are testing for the “token bolted on” problem: the gap between the decentralisation narrative and the operational reality.
The six dimensions
Not all dimensions carry the same weight, because not all of them contribute equally to user sovereignty. Infrastructure and governance get the most because they determine whether decentralisation is structural or cosmetic.
Infrastructure decentralisation (0-20)
The physical and technical layer. Who runs the nodes, who controls the hardware, and can anyone participate?
| Score range | Criteria |
|---|---|
| 0-4 | Fully centralised infrastructure operated by single entity |
| 5-8 | Multiple operators but controlled by foundation/company; permissioned |
| 9-12 | Permissionless node operation with some centralisation vectors (e.g., reliance on single cloud provider, foundation-run critical infrastructure) |
| 13-16 | Broadly distributed infrastructure with minor centralisation concerns |
| 17-20 | Fully permissionless, geographically distributed, no single points of failure |
Governance decentralisation (0-20)
Who makes decisions? Token votes are necessary but not sufficient. We look at whether governance power is genuinely distributed or concentrated among insiders who happen to hold the most tokens.
| Score range | Criteria |
|---|---|
| 0-4 | All decisions made by founding team / single entity |
| 5-8 | Token voting exists but team holds controlling stake or has veto power |
| 9-12 | Functional governance with broad participation but significant team influence |
| 13-16 | Active DAODAODecentralised Autonomous Organisation. A way to coordinate decisions and manage a treasury using token-weighted voting instead of a traditional company structure. Token holders propose and vote on changes directly.Like a shareholder-run company where every shareholder can vote on every decision, the votes are public, and the company can't do anything the shareholders don't approve. The coordination is messier than a normal company but nobody has unilateral control.Read more → governance with meaningful community control and transparent processes |
| 17-20 | Fully community-governed with no privileged parties, immutable core contracts |
Token distribution fairness (0-15)
How the token supply was created and distributed. Fair launches score higher than insider-heavy allocations. VestingVestingA schedule that locks up tokens allocated to insiders, investors, and team members, releasing them gradually over months or years. Vesting prevents insiders from dumping on public buyers immediately after launch.Like a new employee's stock options at a startup. You don't get all the shares on day one. They unlock over four years so you stick around and do the work rather than cashing out and leaving.Read more → schedules, VCVCVenture Capital. Private investors who fund projects at an early stage in exchange for equity or token allocations. VC rounds are typically pre-launch, at steep discounts to any future public price, with multi-year vesting.Like angel investors in a startup who buy shares before the company goes public. They take more risk because the company might fail, so they get a better price. Once the company IPOs they can sell, and the public market pays whatever price it thinks is fair.Read more → concentration and whale dominance all factor in.
| Score range | Criteria |
|---|---|
| 0-3 | Majority allocation to team/investors with short or no vesting |
| 4-6 | Heavy insider allocation but with meaningful vesting schedules |
| 7-9 | Balanced allocation with fair launchFair LaunchA token launch where everyone has the same access from day one. No private sale, no insider allocation, no VC discount. Tokens are distributed by mining, staking, or open public sale at a single price.Like a 100m sprint where everyone starts behind the same line at the same time. Some runners are faster, but nobody gets to start 10 metres ahead because they paid extra. The race is decided by the run, not by who bought the best position.Read more → elements or significant community distribution |
| 10-12 | Majority community-distributed through miningProof of WorkThe original blockchain consensus mechanism where miners compete to solve computationally expensive puzzles. The winner proposes the next block and earns the rewards. Proof of Work secures Bitcoin and most pre-2020 chains.Like a lottery that runs every 10 minutes where the tickets cost electricity. Whoever spends the most electricity buying lottery tickets has the best chance of winning that round's prize. Nobody can fake the result because the proof of their work is verifiable by everyone.Read more →, stakingStakingLocking up a cryptocurrency to help secure a blockchain network, usually in exchange for rewards. The locked tokens act as a security deposit that can be taken away if the staker misbehaves.Like putting down a large rental deposit for an apartment. You get the money back if you behave, you earn interest while it's locked, and the landlord takes it if you trash the place.Read more →, or open participation |
| 13-15 | Fair launch or fully community-distributed with no insider pre-mine |
Censorship resistance (0-15)
Can anyone use the network without permission? Can the project operators blockBlockA batch of transactions added to a blockchain at a set interval. Each block cryptographically links to the previous one, creating an append-only chain that can't be rewritten without redoing all the work since.Like a page in a ledger. Every page has a fixed number of entries, every page references the previous page, and once a page is filled and signed off it can't be edited without visibly invalidating every page that came after. The chain is just a very long series of these sealed pages.Read more →, filter or restrict what participants do?
| Score range | Criteria |
|---|---|
| 0-3 | Platform can censor users, restrict access, or modify outputs at will |
| 4-6 | Some censorship vectors exist; terms of service can restrict usage |
| 7-9 | Resistant to casual censorship but vulnerable to coordinated pressure |
| 10-12 | Strong censorship resistance with few realistic attack vectors |
| 13-15 | Fully censorship-resistant; no entity can restrict access or modify outputs |
Data sovereignty (0-15)
Who controls user data? Self-custody, privacy guarantees, data portability and platform visibility all contribute here.
| Score range | Criteria |
|---|---|
| 0-3 | User data controlled entirely by project; no export, no self-custody |
| 4-6 | Some data portability but platform retains control and visibility |
| 7-9 | Users control their data with some platform dependencies |
| 10-12 | Strong self-custody of data with verifiable privacy guarantees |
| 13-15 | Full user data sovereignty; zero-knowledge or fully encrypted; no platform visibility |
Anonymisation vs confidentiality. For AI inferenceInferenceRunning a trained AI model to produce an answer. Inference is what happens when you type a prompt into ChatGPT and get a response. The model takes your input, computes a best guess, and returns it.Like asking an expert for their opinion. The training was the decades they spent becoming an expert. The inference is the 30 seconds it takes them to answer your specific question.Read more → and compute projects specifically, we distinguish between anonymisation (the provider does not know who sent the data, but can see its contents during processing) and confidentiality (the provider cannot see the data contents, enforced by hardware or cryptography). Policy-based non-storage claims (zero data retention) without cryptographic or hardware enforcement are anonymisation. They belong in the 7-9 range. Hardware-attested privacy (TEETEETrusted Execution Environment. A hardware-secured region of a CPU or GPU where code runs in isolation, so even the machine's operator can't read what's happening inside. TEEs give decentralised AI inference privacy guarantees.Like a bank vault inside a bank. The bank owns the building, staffs the lobby, and runs the security cameras. But what's inside the vault is invisible to everyone, including the bank staff, unless the customer opens it.Read more → with verifiable remote attestationAttestationA cryptographic proof that a piece of code is running on a specific hardware enclave in an unmodified state. Attestation lets remote users verify that a service is genuinely running what it claims to be running.Like a tamper-evident seal on a medicine bottle. The seal itself doesn't make the medicine safe, but it gives you a way to verify that nobody opened the bottle and swapped the contents before you bought it.Read more →) qualifies for 10-13. Mathematical privacy guarantees (FHEFHEFully Homomorphic Encryption. A cryptographic technique that lets you compute on encrypted data without decrypting it. The result is also encrypted, and only the data owner can read it. FHE is the strongest form of computational privacy.Like sending a sealed box of ingredients to a chef, having the chef cook a meal inside the box without ever opening it, and getting back a sealed box with the finished meal. Only you can unseal it and see what's inside.Read more →, MPCMPCMulti-Party Computation. A cryptographic technique where multiple parties jointly compute a function over their inputs without any party revealing its input to the others. Useful for shared computation on private data.Like a group of friends calculating the average of their salaries without anyone revealing their actual salary to the others. Each person contributes a piece of the answer, and the pieces combine into the result, but nobody learns anything except the average itself.Read more → with independent verification) qualify for 13-15. A project that claims privacy but relies solely on contractual commitments rather than verifiable mechanisms should not score above 10 regardless of how strong the policy language is.
Open source and transparency (0-15)
Is the code public? Can operations be verified independently? Are finances disclosed? Reproducible builds, on-chain verification and transparent treasuries all score higher.
| Score range | Criteria |
|---|---|
| 0-3 | Closed source; no visibility into operations or codebase |
| 4-6 | Partially open source; key components proprietary |
| 7-9 | Mostly open source with transparent operations but some opaque elements |
| 10-12 | Fully open source with regular public reporting and verified on-chain operations |
| 13-15 | Fully open source, reproducible builds, all operations verifiable on-chain, transparent treasury |
Grading scale
The six dimensions produce a score out of 100, which maps to a letter grade.
| Grade | Score | Meaning |
|---|---|---|
| A | 85-100 | Genuinely decentralised. Sovereignty-first. |
| B | 70-84 | Meaningfully decentralised with minor concerns |
| C | 55-69 | Partially decentralised. Significant centralisation vectors remain. |
| D | 40-54 | Largely centralised with decentralisation narrative |
| F | 0-39 | Centralised project with a token bolted on |
No project we have reviewed scores an A. That’s by design. Genuine, full-stack decentralisation is extraordinarily rare and most projects that claim it are overstating their position. A score in the B range represents genuinely impressive decentralisation with realistic acknowledgement that perfection doesn’t exist yet.
How /100 maps to /10 on project cards
On project listing pages, the Freedom Score displays as a simple number out of 10. This is the /100 score divided by 10 and rounded to the nearest whole number. So a project scoring 63/100 displays as 6/10, and a project scoring 35/100 displays as 4/10.
The /10 display is for quick comparison. The full /100 breakdown with evidence for each dimension lives in the project review itself. Always read the full review before drawing conclusions from the headline number.
Evidence requirements
Every score must be justified with specific, verifiable evidence. We follow a source hierarchy:
- On-chain data (block explorers, smart contracts, governance records) beats everything else. If the whitepaper says one thing and the chain says another, the chain wins.
- Primary documentation (official docs, whitepapers, GitHub repositories) is the baseline.
- Independent reporting (audits, security research, investigative journalism) provides crucial third-party verification.
- Market data (CoinGecko, CoinMarketCap, exchange data) for supply and distribution figures.
- Community and social data used for sentiment only, never for factual claims.
Single-source claims are flagged. If only one source supports a data point, we note the limitation rather than present it as established fact.
Subjectivity acknowledgement
The score ranges define criteria-based boundaries. A project either has permissionless node operation or it doesn’t. It either has a fair launch or it doesn’t. These boundaries are as objective as we can make them.
The exact position within a range involves editorial judgement. Two projects might both have “permissionless node operation with some centralisation vectors” (9-12 range), but one has 63 providers and the other has 8,000 nodes. The researcher places them differently within that range based on the evidence. This is a feature, not a bug. Pretending that decentralisation assessment is purely mathematical would be dishonest.
We publish the evidence alongside every score so you can disagree with our placement and reach your own conclusion. The reasoning matters more than the number.
Scores change over time
Every Freedom Score is a point-in-time assessment. Projects evolve. Governance mechanisms get deployed or abandoned. Token distributions shift. Security audits happen or don’t happen. Chain migrations change the infrastructure picture entirely.
We update scores when material changes occur, note the date of assessment, and explain what changed. A project that scores 6/10 today might score 8/10 in twelve months if it delivers on its decentralisation roadmap. It might also score 4/10 if governance centralises further.
Each project review includes a “path to improvement” section identifying specific, concrete steps that would increase the score. It’s not a wish list. It’s our assessment of what would move the needle based on the evidence we have reviewed.