Solidity (0.8.x)

This assessment applies the coupling account — coupling as access to a shared resource, and the coupling floor [1], [2] — and the knowledge-embodiment theorem [3]; the language is assessed against its official reference [4].

1 Assessment

This page assesses Solidity in five parts: core coupling — what the language’s own constructs force; ecosystem coupling — what the surrounding platform, tooling, and community cost; engineering readiness — whether the artifact can be reproduced, verified, observed, worked in quickly, connected to other languages, and governed openly; the profile — the unscored facts a score cannot express; and the scoring detail — the mechanism marks and the arithmetic behind every score. A ✅ bullet marks a construct that helps. A ⚠️ or ❌ bullet marks a cost; the scoring model does not price every cost named here.

Core coupling 50/100 · Ecosystem coupling 61/100 · Engineering readiness 56/100

1.1 Core coupling

1.1.1 Type

  • ✅ Statically typed and compiler-checked: Every state variable, parameter, and return value has a declared type
  • ✅ Value and reference types are distinguished: uint256, address, and bool are value types, while arrays, structs, and mappings are reference types
  • ❌ No sum types: A choice between alternatives is an enum plus a struct, or a separate contract, and the compiler cannot check the union (T4)
  • ✅ Contracts and interfaces declare the ABI: A function signature in an interface fixes the external call shape
  • ✅ No null: A uint256 starts at 0 and an address starts at the zero address, so absence is a value convention
  • ⚠️ The data location is stated at every use: memory, storage, and calldata must be written for a reference type, and a wrong location changes the meaning of an assignment

1.1.2 Construction

  • ❌ A constructor is optional: A contract without an explicit constructor is deployed with default state, so deployment validation is optional (C4)
  • ✅ Contracts are the unit of encapsulation: State and functions live in one contract, and external, public, internal, and private state the visibility
  • ✅ Inheritance with C3 linearization gives a defined order: contract B is A orders the bases linearly, so super resolves predictably
  • ✅ Mappings and structs are declared members: A mapping(address => uint256) and a struct state the storage shape
  • ✅ Constructors and initializer functions validate deployment: constructor(...) and an initializer modifier set and check the initial state
  • ⚠️ delegatecall couples two contracts to one storage layout: The callee runs against the caller’s storage, so the layouts must agree exactly

1.1.3 Memory

  • ✅ No garbage collector and no collection pause: The EVM memory is a per-call byte array that is discarded when the frame returns
  • ✅ The data location makes copying visible: memory copies a value into the call, and calldata reads it in place
  • ✅ Values are freed when a call frame returns: The caller never frees memory
  • ✅ constant and immutable remove a storage read: A value fixed at compile time or at construction is embedded in the bytecode
  • ⚠️ Persistent storage is expensive and manual: A write to a fresh storage slot costs 20 000 gas, so layout and write count are economic decisions
  • ⚠️ A storage pointer aliases contract state: A local storage reference points into state, so a write through it is persistent

1.1.4 Error

  • ❌ Failure is checkable but not exhaustive: require and revert abort a call, and nothing forces a caller to handle the failure (Er3)
  • ❌ An unchecked low-level call is silently ignored: (bool ok, ) = addr.call(...) compiles even when ok is discarded, so a failed external call can pass unnoticed
  • ✅ require(cond, "reason") states a precondition: A failed precondition reverts with a message
  • ✅ Custom errors carry structured data cheaply: error InsufficientBalance(uint256 available); and revert InsufficientBalance(a) return named fields
  • ✅ try/catch handles an external call failure: Since 0.6 a failed external call can be caught
  • ✅ Arithmetic is checked by default since 0.8: An overflow or underflow reverts, and unchecked { ... } is the explicit opt-out

1.1.5 Concurrency

  • ❌ The language has no concurrency: A transaction runs sequentially on a single EVM thread, so there is no concurrent primitive (K1)
  • ❌ Execution is coupled to the gas limit: A call that runs out of gas reverts, so control flow depends on the gas the sender supplies
  • ✅ A transaction is atomic: The state changes commit together or revert together, so no partial state remains
  • ✅ External calls within one transaction are ordered deterministically: The sequence is fixed by the bytecode
  • ⚠️ Reentrancy is an ordering hazard: An external call can re-enter the contract before it returns, so checks-effects-interactions or a reentrancy guard must be applied by hand
  • ⚠️ Atomicity stops at the transaction boundary: Two contracts touched in one transaction succeed or fail together, and no further coordination exists

1.1.6 Platform

  • ❌ The EVM is the only target: The compiler emits EVM bytecode, and there is no other runtime (P1)
  • ❌ The chain context is injected into every contract: msg.sender, msg.value, block.timestamp, block.number, and tx.origin are globals, so logic is coupled to the caller, the block, and the chain
  • ✅ EVM-compatible chains share the runtime: A contract deploys to Ethereum, an L2, or any other EVM chain
  • ⚠️ The context globals differ in meaning per chain: On an L2 block.number may be the L1 height and the sequencer sets block.timestamp, so a timing assumption does not transfer
  • ⚠️ An upgradeable contract separates logic from storage: A proxy delegates to an implementation, and the storage layout must stay compatible

1.1.7 Trade-offs (not coupling)

  • Gas metering is the execution model: A deliberate economic constraint, not a language defect
  • Turing completeness is an expressive-power choice: Decidable automated verification of arbitrary properties cannot follow from it
  • The domain is on-chain contracts: Outside that domain the language has no use, which is a scope decision
  • Inheritance is provided: The language includes single and multiple inheritance, and C3 linearization orders multiple bases
  • Static typing helps but does not remove domain risk: The type system checks types, not economic or adversarial behaviour
  • The 0.8 release line changes semantics: Checked arithmetic and removed implicit conversions are a deliberate tightening, not a defect

1.2 Ecosystem coupling

1.2.1 Performance

  • ✅ The cost model is explicit in gas: Every operation has a known price, so cost is stated rather than measured
  • ✅ The solc optimiser reduces the emitted bytecode: The compiler optimises the code it produces
  • ✅ Execution is deterministic across nodes: Every node computes the same result, which consensus requires
  • ⚠️ Performance is not measured in wall-clock time: Gas, not throughput, is the design constraint
  • ⚠️ Storage reads and writes dominate cost: A warm storage read costs 100 gas and a write costs far more, so a layout decision sets the cost
  • ⚠️ The EVM is slow in general-computing terms: A loop over state is expensive by construction

1.2.2 Ecosystem

  • ✅ Foundry, Hardhat, and Truffle provide build and test tooling: Compilation, testing, and deployment are covered
  • ✅ OpenZeppelin Contracts gives audited base contracts: Standard tokens and access control arrive as reviewed libraries
  • ✅ solc is a released, versioned compiler with a range pragma: A file states the compiler versions it accepts
  • ❌ The ecosystem is niche, young, and chain-specific: Package reuse is limited to an EVM audience, and the tooling field is small (Ec3)
  • ⚠️ Tooling churn is high: The build-tool field has shifted toward Foundry, and older tooling is losing support
  • ⚠️ There is no language-level package manager: Dependency management comes from the build tool, such as npm or a git submodule

1.2.3 Evolution

  • ✅ The compiler is released on an active cadence: 0.8.x releases add features and fixes
  • ✅ pragma solidity ^0.8.0 pins the compiler range per file: A source file states the versions it accepts
  • ✅ Breaking changes are grouped into release lines: 0.8 turned on checked arithmetic and removed implicit conversions
  • ✅ The release notes state every breaking change: A migration path is documented for each release
  • ⚠️ The 0.x versioning carries no compatibility promise: Every minor release may break, so a compiler range is mandatory in practice
  • ⚠️ A deployed contract cannot be changed: The bytecode on chain is fixed, so an upgrade needs a proxy pattern from the start

1.2.4 Domain

  • ✅ The language is the right tool for EVM smart contracts: The ABI, the storage model, and the chain context match the problem
  • ✅ The type-safe ABI supports standard interfaces: An ERC-20 or ERC-721 contract is expressed as an interface with typed functions
  • ❌ Domain lock-in to on-chain contracts: Outside the EVM the language has no application (D1)
  • ⚠️ Blockchain-specific concerns are only partly covered by constructs: Reentrancy, front-running, and key management have no dedicated language construct
  • ⚠️ The gas model is part of the domain semantics: Every construct has an economic effect the programmer must consider

1.2.5 Learning

  • ❌ The learning curve is steep: The blockchain model — accounts, gas, storage, reentrancy, and the ABI — must be learned on top of the language (L1)
  • ✅ The syntax is familiar to JavaScript developers: The grammar is ECMAScript-like, with braces, semicolons, and dot access
  • ✅ Modifiers give a readable access-control idiom: modifier onlyOwner states a precondition at the function
  • ✅ The documentation and community resources are good: The Solidity documentation and the OpenZeppelin guides are maintained
  • ⚠️ A mistake has a direct economic cost: A vulnerability in a deployed contract can be exploited immediately, so experience is expensive to acquire

1.2.6 Syntax

  • ✅ ECMAScript-style syntax: Braces, semicolons, and the . member operator match JavaScript
  • ✅ Modifiers are a declarative precondition: A modifier wraps the function body and names the condition at the signature
  • ✅ Data locations are stated in the signature: function f(uint[] calldata xs) shows where the argument lives
  • ✅ Contract and interface declarations read as a module: The contract is the top-level unit and names its own scope
  • ⚠️ Inline assembly { ... } uses the lower-level Yul syntax: A low-level block changes the language inside the braces
  • ⚠️ A modifier hides the code it wraps: The reader sees the modifier name, not the rewritten body

1.2.7 Testing

  • ✅ Foundry runs tests written in Solidity: forge test executes contracts as tests
  • ✅ Hardhat runs a TypeScript test suite against a local chain: Accounts, deployment, and assertions are scripted
  • ✅ Fork testing reproduces mainnet state: forge test --fork-url runs against a pinned block
  • ✅ Fuzzing and invariant testing are built into Foundry: A property is checked over generated inputs
  • ✅ Coverage and gas reporting are available: forge coverage and forge snapshot report coverage and cost
  • ⚠️ The compiler does not catch reentrancy or access-control faults: Those faults pass every type check

1.2.8 Security

  • ❌ The domain has canonical vulnerability classes: Reentrancy, front-running, and access-control faults are the field’s recurring failures, and Solidity was partly blamed for The DAO hack in 2016 (Q3)
  • ⚠️ Reentrancy needs an explicit ordering discipline: Checks-effects-interactions or a reentrancy guard must be applied by hand
  • ✅ Arithmetic is checked by default since 0.8: An overflow or underflow reverts rather than wrapping silently
  • ✅ require and custom errors make a failure explicit: A failed precondition reverts with a reason
  • ⚠️ delegatecall and low-level calls bypass type checking: The callee and the target are chosen at run time
  • ✅ Static typing and the ABI prevent type confusion at the boundary: An external call is encoded against a declared signature

1.3 Engineering readiness

1.3.1 Reproducibility

  • ❌ Dependencies resolve without a lock by default.

1.3.2 Supply chain

  • ⚠️ Published packages carry no signed provenance by default.
  • ⚠️ The package registry is a flat name space.

1.3.3 Observability

  • ⚠️ No stable tracing and metrics standard.
  • ⚠️ The standard library has no structured logging.

1.3.4 Feedback

  • ✅ No charged mechanism in this dimension.

1.3.5 Interop

  • ❌ No general foreign-function interface.
  • ⚠️ No maintained portable target.

1.3.6 Governance

  • ✅ No charged mechanism in this dimension.

1.4 Profile

Unscored, and kept separate from every score on purpose. The profile records what a mechanism price cannot express: what a running program costs, how well a coding model and an agent work in the language, and whether a safety-critical path exists.

1.4.1 Energy and cost

What this axis asks: what does a running program cost in energy and time?

  • ⚠️ Runs on a virtual machine, above native code in the energy and time benchmarks [5]; a causal re-analysis attributes most of the gap to execution time [6].

1.4.2 AI and agent readiness

What this axis asks: how well does a coding model and an agent work in this language?

  • ⚠️ Moderate training data: models write it competently, with measurable language-specific weakness [7].

1.4.3 Safety certification

What this axis asks: is there a certified or standards-qualified path to a safety-critical system?

  • ⚠️ No certified or standards-qualified path for safety-critical systems.

1.5 Scoring detail

1.5.1 Core coupling Dimensions

Dimension Mechanism Description Present Cost
Type T1 dynamic no static check — 0
T2 weak static — 0
T3 dynamic/duck dispatch — 0
T4 no sum types ✅ −4
T5 no generics — 0
T6 no namespaces — 0
T7 type erasure/reflection — 0
T8 operator overloading — 0
T9 inheritance required for polymorphism — 0
T10 no null-safety — 0
T11 no module boundary — 0
T12 no effect tracking ✅ −8
T13 async/sync colouring — 0
T14 unchecked foreign boundary — 0
Type subtotal −12
Construction C1 global mutable state by default — 0
C2 no immutability by default — 0
C3 constructors coupled to allocation — 0
C4 no constructor/validation ✅ −4
Construction subtotal −4
Memory M1 manual deallocation — 0
M2 GC non-deterministic pauses — 0
M3 no RAII — 0
M4 no ownership model — 0
Memory subtotal 0
Error Er1 no structured path — 0
Er2 unchecked exceptions only — 0
Er3 errors ignored/non-exhaustive ✅ −4
Er4 no composable result type — 0
Error subtotal −4
Concurrency K1 GIL/no parallel ✅ −15
K2 shared mutable state default — 0
K3 manual sync no race detection — 0
K4 no structured concurrency — 0
K5 no primitives — 0
Concurrency subtotal −15
Platform P1 cannot function outside one vendor/domain ✅ −15
P2 single-vendor but other uses — 0
P3 legacy/discontinued platform — 0
Platform subtotal −15

Core Dimensions score: 50/100 — total cost = −50 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

1.5.2 Ecosystem coupling Dimensions

Dimension Mechanism Description Present Cost
Performance R1 interpreted no AOT/JIT — 0
R2 GC pauses — 0
R3 JIT warmup — 0
Performance subtotal 0
Ecosystem Ec1 no package manager — 0
Ec2 fragmented tooling — 0
Ec3 small/niche/discontinued ✅ −8
Ec4 proprietary — 0
Ec5 platform-locked tooling — 0
Ec6 monoculture — 0
Ec7 legacy burden — 0
Ecosystem subtotal −8
Evolution V1 breaking changes — 0
V2 frozen — 0
V3 discontinued — 0
V4 glacial standards — 0
Evolution subtotal 0
Domain D1 domain/vendor lock-in ✅ −15
D2 poor domain fit — 0
D3 framework forces architecture — 0
Domain subtotal −15
Learning L1 steep ✅ −8
L2 large surface/multi-paradigm — 0
L3 sparse docs — 0
Learning subtotal −8
Syntax S1 verbose — 0
S2 inconsistent — 0
S3 punctuation-heavy — 0
Syntax subtotal 0
Testing G1 weak tooling — 0
G2 poor debugging — 0
G3 runtime-only errors — 0
Testing subtotal 0
Security Q1 memory-unsafe — 0
Q2 dynamic/weak typing risk — 0
Q3 known vulnerability/injection ✅ −8
Security subtotal −8

Meta Dimensions score: 61/100 — total cost = −39 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

1.5.3 Engineering readiness Dimensions

Dimension Mechanism Description Present Cost
Reproducibility Y1 build not reproducible — 0
Y2 dependencies not pinned ✅ −8
Reproducibility subtotal −8
Supply chain Y3 no signed provenance ✅ −8
Y4 registry without namespacing ✅ −4
Supply chain subtotal −12
Observability Y5 no stable tracing standard ✅ −8
Y6 no structured logging ✅ −4
Observability subtotal −12
Feedback Y7 slow build — 0
Y8 no fast in-editor analysis — 0
Feedback subtotal 0
Interop Y9 no foreign-function interface ✅ −8
Y10 no portable target ✅ −4
Interop subtotal −12
Governance Y11 single-vendor governance — 0
Y12 closed specification — 0
Governance subtotal 0

Readiness Dimensions score: 56/100 — total cost = −44 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

Verdict: Solidity’s design yields high language-imposed coupling, most of it imposed by its domain. The type system is static and the data locations are explicit, but the EVM injects the chain context into every contract, execution is single-threaded and gas-metered, and the language runs nowhere else. Main strengths: a type-safe ABI, checked arithmetic since 0.8, custom errors, and mature test tooling in Foundry and Hardhat. Main weaknesses: no sum types, an optional constructor, a failure path a caller may ignore, no concurrency, platform lock-in to the EVM, and a security model in which reentrancy and access-control faults are the domain’s canonical failures.

The formal development. The definitions, theorems, and proofs behind this page are published in:

All published papers

References

[1]
Y. Loth, “On the nature of coupling: All coupling as shared resource access.” Zenodo, Aug. 2026. doi: 10.5281/zenodo.21925122.
[2]
Y. Loth, “Coupling as a consequence of cohesion: Decomposition, the coupling floor, and domain-imposed coupling.” Zenodo, Aug. 2026. doi: 10.5281/zenodo.21925201.
[3]
Y. Loth, “On the nature of cohesion: Cohesion as correctness relative to a partitioning rule.” Zenodo, Jul. 2026. doi: 10.5281/zenodo.21703193.
[4]
Ethereum Foundation, “Solidity documentation.” Ethereum Foundation, 2024. Available: https://docs.soliditylang.org/
[5]
R. Pereira et al., “Energy efficiency across programming languages: How do energy, time, and memory relate?” in Proceedings of the 10th ACM SIGPLAN international conference on software language engineering (SLE), 2017, pp. 256–267. doi: 10.1145/3136014.3136031.
[6]
N. van Kempen, H.-J. Kwon, D. T. Nguyen, and E. D. Berger, “It’s not easy being green: On the energy efficiency of programming languages,” in Proceedings of the 40th IEEE/ACM international conference on automated software engineering (ASE), 2025. doi: 10.1109/ASE63991.2025.00131.
[7]
S. Joel, J. J. Wu, and F. H. Fard, “A survey on LLM-based code generation for low-resource and domain-specific programming languages,” ACM Transactions on Software Engineering and Methodology, 2025, doi: 10.1145/3770084.