Trustless Index Scoring Rubric: Smart Contracts

The Trustless Index evaluates smart contracts and protocols on five core dimensions of trustlessness: No Admin, Immutable, No Proxy, Open Source, and Audited. Each metric is scored from 1.0 (worst) to 10.0 (best). The Trustless score is the average of all five.

Our framework is designed to be absolute, not relative. That means a protocol scoring 10.0 does not imply another must score close at 9.0. To enhance fact-based evaluation and minimize subjectivity, each dimension now features granular criteria tied to verifiable, on-chain, and documented evidence, such as function counts, code analysis, historical changes, and third-party reports. Scores are assigned based on strict matching to these bands, with cross-verification from blockchain explorers, official repositories, and audit documents required for all assessments.

No Admin

Assesses the presence and control of administrative privileges, verified through contract code inspection, governance docs, and historical transaction logs for any admin actions. Focus on the number, scope, and controller of privileged functions.

10.0: No admin keys, no owner functions, no multisigs, no governance hooks that can alter any logic; fully renounced ownership with on-chain proof.
9.0-9.9: Extremely minimal non-critical functions (e.g., only 1-2 for cosmetic changes like metadata updates); no impact on user funds or core rules; controlled by immutable code only.
8.0-8.9: Very few non-critical functions (e.g., 3-4, such as fee routing to predefined addresses); verifiable time-locks or burns on any remaining keys; no history of use.
7.0-7.9: Limited non-critical functions (e.g., 5-6, including variable adjustments like interest rates within bounded ranges); controlled by decentralized DAO with high quorum (>50% participation required).
6.0-6.9: Moderate admin capabilities (e.g., 7-8 functions allowing pauses on peripheral modules); multisig/DAO can interfere temporarily but with on-chain veto mechanisms or short durations (<7 days).
5.0-5.9: Notable admin interference possible (e.g., 9-10 functions for upgrades on non-core elements); multisig/DAO controls with medium quorum (30-50%), evidence of past minor uses without fund risks.
4.0-4.9: Significant admin control (e.g., >10 functions enabling full pauses or selective upgrades); multisig/DAO with low quorum (<30%), documented history of interference in non-critical scenarios.
3.0-3.9: High admin presence (e.g., broad owner functions for core alterations); centralized multisig (e.g., 3/5 signers from one entity), multiple past interventions affecting operations.
2.0-2.9: Very high admin control (e.g., unrestricted owner access to alter logic or withdraw funds); single-entity multisig, frequent historical changes or pauses (>5 incidents).
1.0-1.9: Clear and total admin control; contract can be altered at will by a central owner or unrenounced deployer, with no restrictions and evidence of arbitrary modifications.

Immutable

Evaluates the fixed nature of the contract's bytecode and rules, confirmed via deployment history, upgrade logs, and code reviews. Quantify based on changeable elements, past upgrades, and mechanisms for future changes.

10.0: Finished product; bytecode is final with no hooks or parameters changeable; on-chain verification shows no upgrade paths, and deployment tx renounces all mutability.
9.0-9.9: Near-perfect immutability; only 1-2 highly bounded configurable parameters (e.g., fixed-range fees); no history of changes post-deployment.
8.0-8.9: High immutability; 3-4 configurable parameters (e.g., adjustable within 10% bounds via time-locked votes); rare changes (1 in history, non-core).
7.0-7.9: Strong immutability; 5-6 parameters adjustable (e.g., governance-approved rates); infrequent changes (2-3 total, with community consensus).
6.0-6.9: Moderate immutability; upgradeable via proxy for minor elements; occasional changes (4-5 historical, affecting auxiliary logic only).
5.0-5.9: Limited immutability; proxy or governance allows mid-level upgrades (e.g., module swaps); moderate change history (6-7 incidents, some core-adjacent).
4.0-4.9: Weak immutability; major functions upgradeable by governance vote; frequent changes (8-10 total, including core rule tweaks).
3.0-3.9: Poor immutability; fully mutable hooks for core logic; high change frequency (>10 historical upgrades, often without full consensus).
2.0-2.9: Very poor immutability; open upgrade paths controlled by admins; extensive history of alterations (>15, including fund-impacting changes).
1.0-1.9: No immutability; fully mutable with core logic swappable at will by central authority, verified by ongoing or unrestricted upgrade mechanisms.

No Proxy

Measures the use of upgradeable proxies, assessed through contract architecture (e.g., via proxy detection tools like OpenZeppelin scanners), deployment artifacts, and admin control over proxies.

10.0: Contract deployed directly; no upgradeable proxy in place; all logic self-contained and immutable from inception.
9.0-9.9: Extremely minimal proxy use (e.g., only for 1 auxiliary module like oracles); core logic fully direct and immutable.
8.0-8.9: Limited proxies (e.g., 2-3 for non-critical peripherals); core remains direct, with proxies time-locked or renounced.
7.0-7.9: Some proxies (e.g., 4-5 modules); core mostly immutable, upgrades require high-threshold DAO (>50% quorum).
6.0-6.9: Moderate proxy deployment (e.g., 6-7 major functions proxied); upgradable by governance with medium quorum (30-50%).
5.0-5.9: Notable proxies (e.g., 8-9 functions); core partially proxied, history of minor upgrades without fund risks.
4.0-4.9: Significant proxy control (e.g., >10 functions); major logic upgradable by low-quorum governance, some past interferences.
3.0-3.9: High proxy reliance; proxy controlled by multisig with broad swap powers, multiple historical logic changes.
2.0-2.9: Very high proxy control; admin/multisig can swap logic freely, frequent swaps (>5 incidents).
1.0-1.9: Total proxy dependency; logic fully swappable at will by central admin, with no restrictions and evidence of arbitrary changes.

Open Source

Gauges code transparency, verified by on-chain source matching (e.g., Etherscan verification), repository access (GitHub/GitLab), and coverage percentages from code audits or tools like Slither.

10.0: Fully verified source code on-chain; open GitHub/GitLab repository with 100% coverage, transparent deployment history including all txs and scripts.
9.0-9.9: Extremely open; 95-99% verified, minor unverified helpers (e.g., standard libraries); full repo with commit history.
8.0-8.9: Highly open; 90-94% verified, small obfuscated components; repo includes deployment details and most dependencies.
7.0-7.9: Mostly open; 80-89% verified, some unverifiable modules; repo public but partial history.
6.0-6.9: Moderately open; 70-79% verified, notable unverifiable helpers; repo available with basic docs.
5.0-5.9: Limited transparency; 60-69% verified, multiple closed components; repo partial or forked without full context.
4.0-4.9: Weak transparency; 50-59% verified, significant unverifiable code; repo restricted or incomplete.
3.0-3.9: Poor openness; 30-49% verified, majority obfuscated; minimal public repo access.
2.0-2.9: Very poor; 10-29% verified, almost all closed-source; no meaningful repo or history.
1.0-1.9: No transparency; <10% verified or fully closed-source/non-verified bytecode, no public repo.

Audited

Appraises security reviews, runtime history, and ongoing protections, sourced from audit reports, bug bounty platforms, and incident trackers. For fully immutable contracts, factor evergreen audit status and waive bug bounty requirements if audits remain valid indefinitely; for mutable contracts, require active bug bounties to incentivize ongoing scrutiny, with audit recency considered ideal at <6 months.

10.0: 3+ professional audits, >5 years runtime without exploits. For fully immutable contracts, audits must be evergreen; for non-immutable contracts, an active bug bounty is required.
9.0-9.9: 3+ professional audits, >3 years runtime, minor issues resolved, audits recent or evergreen. For non-immutable contracts, bug bounty required; waived for fully immutable with evergreen audits.
8.0-8.9: 2+ audits, >2 years runtime, no critical exploits, some medium findings patched. For non-immutable contracts, bug bounty required; waived for fully immutable with evergreen audits.
7.0-7.9: 2+ audits, >1 year runtime, audits may expire with upgrades but history is clean. For non-immutable contracts, bug bounty required; waived for fully immutable with evergreen audits.
6.0-6.9: 1+ audits, 6-12 months runtime, limited track record, minor unresolved issues. For non-immutable contracts, small bug bounty required; optional for fully immutable.
5.0-5.9: 1+ partial-scope audits, <6 months runtime, no/inactive bounty; younger project with some patched vulnerabilities. Bug bounty encouraged but not mandated, regardless of immutability.
4.0-4.9: 1 limited or self-conducted audit, minimal runtime (<3 months), no bounty; evidence of small exploits or unpatched mediums. Bug bounty encouraged but not mandated, regardless of immutability.
3.0-3.9: Poor; no professional audits, runtime with incidents (1-2 minor exploits), unresolved issues. No bug bounty considerations apply.
2.0-2.9: Very poor; no audits, history of exploits (>2), ongoing critical vulnerabilities. No bug bounty considerations apply.
1.0-1.9: No known audits; unresolved critical issues or major exploits, no runtime security measures. No bug bounty considerations apply.

Trustless Score

The final Trustless score is the arithmetic mean of the five categories above.

Notes on Interpretation

A high score in Audited does not equate to perfect safety. For example, a protocol may score 9.0 for audits due to multiple reports and a bug bounty, but its upgradeable nature means audits can become outdated with code changes. In contrast, an immutable protocol maintains evergreen audits, justifying a 10.0 if criteria are met. While all metrics are equally weighted mathematically, No Admin and Immutable represent the core of trustlessness—protocols scoring low here cannot be considered truly trustless, even with perfect audits. All scores must be verified against primary sources, with pros (e.g., enhanced security from audits) and cons (e.g., potential for admin abuse) weighed for balanced assessment.

Trust nothing. Verify everything.