Distributed systems
Independent computers coordinate over a network, where messages can be delayed and individual nodes can fail.
CIRCULA: Expiry-Aware System Design for Blockchains
CIRCULA studies expiry and renewal in the programmable environment provided by blockchains’ shared state, validation rules and verifiable history. The research programme develops formal semantics, a minimal prototype and reproducible experiments to assess effects and costs, including whether useful information remains for verification or recovery after expiry. Inspired by circulation and its Latin root circulus (“circle”), the name evokes the lifecycle of digital claims and rights: validity, expiry and possible renewal. [1]
THE SCIENTIFIC AIM
Lifetime rules as a design choice
Blockchains commonly retain records and verification state after an operation is completed or a right becomes inactive. Lifetime rules already exist as timeouts, timelocks and retention policies, but their assumptions, enforcement layers and recovery requirements are often studied separately.
CIRCULA connects these questions in one fixed technical context: native ledger-level operations with expiry-conditioned validity and renewal. It asks which designs preserve correctness and auditability, how much persistence can be bounded, and what new verification, recovery or operator costs arise.
THE WIDER PERSPECTIVE
Auditability and recovery
Expiry changes validity. The research will examine what information is retained, discarded or becomes unavailable, and under which conditions verification, contestation or recovery remain possible.
CIRCULA investigates the availability and usefulness of information that may remain after expiry.
THE CONCEPTUAL FRAMEWORK
Key concepts
The foundations explain how nodes maintain a shared ledger. The validity concepts describe what CIRCULA will model, implement and evaluate.
Foundations
Blockchain
A shared ledger that groups transactions into blocks linked by cryptographic hashes, so participants can verify the order and history.
Consensus
A protocol for nodes to agree on a shared result, such as which transactions enter the ledger and in what order.
Programmability
Rules encoded in the protocol or in smart contracts determine how ledger operations are validated and executed. This is the programmable context in which CIRCULA studies expiry.
Validity and evidence
Validity interval
The period in which a ledger operation meets its lifetime conditions. Its start, end and notion of time must be specified.
Expiry transition
The transition from valid to expired at a defined boundary. The system’s design determines how historical records are handled.
Renewal rule
An authorized operation that changes or extends a validity interval. Timing, permissions and late renewal need explicit semantics.
Evidence after expiry
Records or proofs that may remain after validity ends. CIRCULA will assess what is available and whether it supports verification or recovery.
Enforcement layer
The part of the system that checks lifetime conditions. CIRCULA investigates ledger-native enforcement and its costs and guarantees.
Audit and recovery
The ability to investigate past states, explain expiry decisions and support recovery while preserving a transparent historical record.
Persistence, growth and circulation
Coin Metrics snapshots compare infrastructure growth and holdings patterns for Bitcoin, Ethereum and USDC on Ethereum at the end of 2018 and 2025. Together, they show how growing ledger records coexist with concentration and dormancy, motivating explicit lifetime rules, bounded retention and recovery-aware archival. [2]
Infrastructure growth
Read each row from 2018 to 2025; the final column gives relative growth. Ledger size is a cumulative data proxy in GB; addresses and transactions are cumulative counts in millions; smart contracts are an end-of-period stock. People can use multiple addresses, and an address can represent multiple people. Growth rates use the underlying series before rounding, so very small displayed starting values can produce large percentages.
| Asset | Metric | End-2018 | End-2025 | Change (%) |
|---|---|---|---|---|
| BTC | Ledger size proxy (GB, cumulative) | 198.11 | 710.27 | +258.5% |
| New addresses (millions, cumulative) | 470.36 | 1,499.19 | +218.7% | |
| Transactions (millions, cumulative) | 368.69 | 1,290.96 | +250.1% | |
| ETH | Ledger size proxy (GB, cumulative) | 69.02 | 1,411.29 | +1944.8% |
| New addresses (millions, cumulative) | 73.44 | 388.79 | +429.4% | |
| Smart contracts (millions, end-of-period) | 9.05 | 63.36 | +600.0% | |
| Transactions (millions, cumulative) | 368.81 | 3,163.55 | +757.8% | |
| USDC on ETH | New addresses (millions, cumulative) | 0.02 | 25.80 | +116545.5% |
| Transactions (millions, cumulative) | 0.05 | 146.39 | +295302.2% |
Holdings and circulation
The left group shows shares of supply; the right group shows the implied USD value of those holdings in billions. Both “Change” columns report relative percentage changes; percentage points measure the absolute difference between shares. For example, Ethereum’s top-address share falls from 99.82% to 69.37%: a drop of 30.45 percentage points, or 30.5% relative to 2018.
| Asset | Indicator | Share of supply (%) | Implied value (USD bn) | ||||
|---|---|---|---|---|---|---|---|
| 2018 | 2025 | Change (%) | 2018 | 2025 | Change (%) | ||
| BTC | Top 10% of addresses | 98.94% | 98.83% | -0.1% | 63.68 | 1,727.28 | +2612.4% |
| On exchanges | 8.79% | 12.46% | +41.7% | 5.66 | 217.71 | +3746.9% | |
| Asset dormancy | 98.57% | 97.93% | -0.6% | 63.44 | 1,711.45 | +2597.7% | |
| ETH | Top 10% of addresses | 99.82% | 69.37% | -30.5% | 13.59 | 249.85 | +1737.9% |
| On exchanges | 16.95% | 11.78% | -30.5% | 2.31 | 42.44 | +1738.5% | |
| Asset dormancy | 91.45% | 90.19% | -1.4% | 12.45 | 324.82 | +2508.3% | |
| USDC on ETH | Top 10% of addresses | 99.99% | 99.85% | -0.1% | 0.25 | 51.63 | +20491.1% |
| On exchanges | 45.17% | 20.61% | -54.4% | 0.11 | 10.66 | +9308.7% | |
| Asset dormancy | 68.96% | 68.70% | -0.4% | 0.17 | 35.52 | +20442.9% | |
What the comparison reveals
Ledger data expands
Ethereum’s ledger-size proxy rises from 69.02 to 1,411.29 GB, about 20.4 times its 2018 level. This growing historical footprint motivates studying bounded persistence alongside audit and recovery requirements.
Dormancy remains high
Bitcoin’s dormancy indicator is still 97.93% in 2025, compared with 98.57% in 2018. Infrastructure growth can coexist with persistent inactivity, inviting further investigation into its relationship with circulation.
Shares and values differ
Ethereum’s exchange-held share drops from 16.95% to 11.78%, while its implied value rises from USD 2.31 to 42.44 billion. A lower supply share can still have a higher dollar value: the two groups answer different questions.
These snapshots describe trends. Establishing any causal effect of expiry would require further research. Concentration, exchange holdings and dormancy depend on custody, address reuse and accounting. Missing infrastructure metrics are inapplicable or unavailable as comparable series; cumulative counts and end-of-period stocks remain distinct.
Research questions
Four questions connect lifetime semantics, enforcement placement, measurable gains and costs, and bounded downstream validation. RQ1–RQ3 form the technical core; RQ4 considers only designs that pass its correctness, auditability and recovery gates.
Semantics
What does a lifetime rule mean?
Specify validity, expiry, renewal, auditability and recovery under explicit assumptions about time, triggering, finality and bounded persistence. The aim is to give each lifecycle event an unambiguous meaning that formal and executable models can test.
Placement
Where should the rule live?
Compare enforcement at the system, contract, wallet or service layer. A placement is retained only if it preserves the stated invariants and passes boundary conformance tests; higher-layer conditioning remains a possible outcome when native enforcement is not technically viable.
Evaluation
What are the gains and costs?
Under controlled expiry-sensitive workloads, compare bounded-persistence gains with additional verification, recovery and operator costs. Use explicit non-expiring or higher-layer baselines, and judge results against scenario-specific cost envelopes and measurement uncertainty.
Deployability
Which designs can be deployed?
For designs that pass the technical gates, examine which enforcement layers remain admissible under transparency, auditability, recovery and due-process constraints. Validation stays within the fixed project context; regulated-payment references set the boundaries of the comparison.
From question to evidence
Research method and work packages
The project follows a semantics-to-evidence pipeline. An evidence map fixes assumptions and baselines; formal and executable semantics define the checks; a bounded prototype demonstrates retained placements; controlled experiments compare their behaviour, costs and limits.
Fixed technical context
Native ledger-level operations with expiry-conditioned validity and renewal
RQ1 · RQ2 · RQ3Core technical axis
RQ4Downstream validation
WP1Evidence Atlas
RQ1–RQ4: framing inputs
WP2Semantic Reference
RQ1 + RQ3 modelling inputs
WP3Proof of Concept
RQ1–RQ2
WP4Evaluation Bench
RQ3–RQ4 + RQ2 placement comparisons
WP3 · Prototype componentsConsensusTokenomicsExpiry ledger
Evaluation refines semantics and baselines
Read from the fixed technical context through the research questions to the four linked outputs. Each work package shows its RQ coverage; evaluation feeds back into semantics and baselines. The prototype connects consensus, tokenomics and the expiry ledger.
WP1 / PLANNED WORK
Lifetime rules and enforcement layers
Document existing lifetime rules: what expires, which layer enforces the rule, and which assumptions it needs. The atlas provides the evidence and comparison boundaries for later work.
All research staff begin with this common framing.
PLANNED OUTPUT
CIRCULA Evidence Atlas
Annotated evidence · Lifetime-rule taxonomy · Comparison boundaries
WP2 / PLANNED WORK
Expiry, renewal and recovery semantics
Formalise issuance, transfer, expiry, renewal, contestation, settlement and recovery. Model what information is retained or discarded and under which assumptions verification or recovery is possible. Develop a deterministic executable reference and conformance scenarios.
The model states its assumptions about time and finality.
PLANNED OUTPUT
CIRCULA Semantic Reference
Formal semantics · Executable reference · Conformance scenarios
WP3 / PLANNED WORK
A bounded ledger prototype
Implement the selected semantics in a minimal node or small testbed. Examine expiry-aware primitives and bounded persistence, and test which verification or recovery interfaces can be supported after expiry.
Conformance checks determine which designs proceed to evaluation.
PLANNED OUTPUT
CIRCULA Proof of Concept
Bounded prototype · Conformance checks · Audit and recovery interfaces
WP4 / PLANNED WORK
Controlled comparisons with baselines
Compare selected designs with explicit baselines under controlled workloads. Measure persistence, verification and recovery costs; examine institutional and adoption constraints in the selected contexts.
Report uncertainty, limitations and negative results.
PLANNED OUTPUT
CIRCULA Evaluation Bench
Controlled comparisons · Reproducible configurations · Evidence snapshots
How evaluation refines the design
Evaluation is part of an internal scientific review cycle. Conformance failures revise semantics or implementation choices; experiments can refine baselines, observables and deployment boundaries. Only designs meeting correctness, auditability and recovery requirements proceed. Versioned research artefacts document those decisions.
Explore the results