CARE: A Responsibility-Oriented Architecture for Domain-Scoped Resolution in Modular and Upgradeable Smart Contracts

CARE: A Responsibility-Oriented Architecture for Domain-Scoped Resolution in Modular and Upgradeable Smart Contracts Ali Rajabi Nekoo1 , Laleh Rasoul1 , Azadeh Zamanifar1,* 1 Department of Computer Engineering, SR.C, Islamic Azad University, Tehran, Iran

arXiv:2609.17647v1 [cs.SE] 15 Sep 2026

Emails: ali.rajabinekoo@iau.ir, laleh.rasoul@iau.ir, azamanifar@iau.ac.ir Abstract Modular and upgradeable smart-contract systems enable replaceable execution logic, but modular dispatch alone does not define which components own architectural responsibilities such as coordination, resolution, shared state, reusable services, and observation. This paper presents CARE, a responsibility-oriented architecture that makes these ownership boundaries explicit and introduces domain-scoped capability resolution, separating execution coordination from the authority that selects an execution target. CARE is defined through a formal architectural model from which five structural properties are derived. Its behavioral semantics are further encoded in TLA+ and evaluated with TLC against seven architectural invariants. Intermediate TLC results were used to refine the architectural model before the final validation run. A controlled empirical evaluation against EIP-2535 and a routingonly baseline shows that CARE introduces an approximately fixed 7.7k-gas runtime routing premium in the evaluated workloads, while localized capability replacement remains close to the routing-only control and substantially less expensive than the evaluated EIP-2535 reconfiguration path. Adversarial tests further characterize authorization controls and residual risks associated with delegated execution and reentrancy. These results position CARE as an architectural model for explicit responsibility ownership and localized evolution rather than as a universal replacement for existing smart-contract upgradeability mechanisms.

Keywords: Smart Contract Architecture; Modular Smart Contracts; Upgradeable Smart Contracts; Software Architecture; Domain-Scoped Resolution; Responsibility Separation; Formal Specification; TLA+; Model Checking; EIP-2535.

1

Introduction

Smart contracts increasingly implement systems whose behavior extends beyond a small collection of independent functions. Decentralized marketplaces, asset-management systems, financial applications, games, identity platforms, and governance systems may contain many business capabilities, persistent state, administrative rules, reusable services, and components that evolve at different rates. As these systems grow, their architecture becomes a question not only of implementing correct behavior, but also of determining where responsibilities reside and how those responsibilities evolve. Upgradeability mechanisms address an important part of this problem. Proxy-based architectures separate a stable interaction point from replaceable implementation logic, while modular mechanisms such as EIP-2535 allow multiple implementation components to coexist behind a common entry point. These approaches make code replacement and modular dispatch practical. They do not, however, inherently define how broader architectural responsibilities are distributed. This distinction becomes important in systems containing several functional domains. A contract can be modular in terms of deployment units while still centralizing unrelated architectural decisions in one routing structure. The same component may receive requests, own the global routing table, select implementations, expose shared configuration, and participate in system-wide concerns. Individual implementations may be replaceable, yet ownership of the architectural decisions surrounding those implementations remains implicit. 1

We argue that execution modularity and responsibility modularity are distinct concerns. A modular dispatch mechanism answers a question such as: Which implementation should receive this invocation? A responsibility-oriented architecture must additionally answer: Who owns the decision, within which scope, and which other concerns remain independent? CARE addresses this second problem. CARE is a responsibility-oriented architecture for modular and upgradeable smart-contract systems. It separates six architectural responsibilities into explicit component classes: • a Runtime Kernel (RK) coordinates execution; • a Resolution Authority (RA) owns execution resolution within one domain; • an Execution Module (EM) owns business behavior; • Shared Architectural State (SS) owns architectural state; • a Shared Architectural Service (SA) owns reusable shared behavior; • an Observation Hub (OH) owns architectural observation. The central mechanism is domain-scoped capability resolution. Instead of maintaining one global capability-to-implementation decision space, an execution request identifies both a capability and a resolution domain. The Runtime Kernel coordinates the request but does not own the capability binding. The Resolution Authority for the selected domain determines the active Execution Module. The normal execution path is therefore: Request → RK → RAd → EM → Result where RAd owns resolution for domain d. This design separates execution coordination from execution resolution. It also permits the same capability identifier to have different implementations in different domains without requiring one global capability namespace. CARE is intentionally narrower than a complete smart-contract lifecycle framework. It does not define a universal governance protocol, version-management system, rollback mechanism, storage-migration framework, vulnerability detector, or implementation-specific security library. Those mechanisms may be composed with CARE. The architectural contribution is to define who owns the runtime responsibilities within which those mechanisms operate. To make these boundaries precise, CARE is defined independently of Solidity through a formal architectural model. The model specifies component classes, responsibility ownership, legal dependency directions, domain membership, resolution functions, state-access rules, service relationships, and observation boundaries. Five structural properties follow from the model: 1. Unique Responsibility Ownership; 2. Domain-Scoped Centralized Capability Resolution; 3. Architectural State Ownership Independence; 4. Shared Service Ownership Independence; 5. Structural Observation Separation. 2

These properties characterize the architecture. They are not claims that every CARE implementation is automatically more maintainable, secure, reliable, or scalable. A second validation layer encodes the behavioral semantics of CARE in TLA+. Seven architectural invariants are checked with TLC over a bounded finite-state model. Intermediate TLC results were used during model development to refine the architectural constraints. The final model completed exploration of 360,980 distinct reachable states without violation of the seven enabled invariants. A Solidity reference implementation provides the third layer of evidence. Its operational behavior is evaluated using Direct execution, an EIP-2535-oriented Diamond implementation, and a minimal routing-only control. The experiments examine runtime dispatch, routing cardinality, domain partitioning, localized capability replacement, and independently enabled architectural concerns. The empirical results reveal a trade-off rather than a universal performance advantage. The evaluated CARE runtime path introduces an approximately fixed 7.7k-gas premium relative to the EIP-2535 execution path. Finer domain decomposition increases one-time deployment and configuration cost. Conversely, localized CARE capability replacement remains within approximately 0.61–1.72% of the minimal routing control across the tested replacement sizes and requires less gas than the evaluated EIP-2535 reconfiguration operation. CARE is therefore primarily intended for modular systems in which capabilities or functional domains are expected to evolve independently. For simple or rarely evolving contracts, a direct implementation or simpler proxy/routing architecture may be more appropriate. These comparisons characterize the tested implementations and should not be generalized into a claim that CARE is universally cheaper than EIP-2535. Finally, a threat-model-driven evaluation examines implementation-level security boundaries. Authorization controls reject unauthorized architectural mutations in the reference implementation. At the same time, delegated Execution Modules execute through delegatecall and therefore belong to the Runtime Kernel’s trusted computing base. CARE also does not inherently prevent reentrant or nested cross-domain execution. The contributions of this work are: 1. A responsibility-oriented architecture for modular smart-contract systems. CARE defines explicit owners for execution coordination, execution resolution, business execution, architectural state, shared services, and observation. 2. A formal model of domain-scoped capability resolution. The architecture is specified through entities, responsibilities, relations, mappings, and constraints from which five structural properties are derived. 3. Machine-checked validation of selected architectural behavior. A TLA+ model is checked against seven architectural invariants, with intermediate TLC results informing refinement of the architectural model before the final validation run. 4. A controlled empirical evaluation. A Solidity reference implementation is compared with EIP-2535 and a routing-only control across runtime, architectural-growth, localized-evolution, and concern-ablation experiments. 5. An explicit characterization of implementation trust boundaries. Adversarial tests distinguish enforced authorization controls from residual risks including trusted delegated code and reentrant execution. The remainder of the paper first positions CARE relative to existing smart-contract evolution and modularity work, then defines the architecture and formal model. Machine-checked validation 3

is followed by the empirical methodology and results. The final sections examine security boundaries, architectural trade-offs, threats to validity, and future work.

2

Background and Related Work

2.1

Smart-Contract Evolution and Modular Execution

Although deployed contract bytecode is immutable, deployed smart-contract systems continue to evolve. Studies of smart-contract development report recurring difficulties involving language constraints, testing, security, tooling, and upgradeability [1, 2], while broader reviews characterize smart-contract engineering as a combination of evolving implementation practices and unresolved development challenges [7]. Maintenance studies similarly show that contract evolution extends beyond corrective fixes and includes adaptation and internal improvement [3], [20–22]. Upgradeable architectures address this need by introducing indirection between a stable interaction surface and implementation logic. Empirical work has shown that upgradeable contract structures are used in practice [4], while developer studies identify additional complexity around initialization, storage compatibility, and interaction among upgradeable components [23]. EIP-2535 extends modular execution by routing function selectors to multiple facets behind a Diamond. This makes it an important comparison point for CARE: both architectures can support multiple replaceable execution components behind a stable entry point. The architectural unit of resolution differs, however. Diamond-style dispatch is organized around selector-to-facet relationships. CARE organizes execution around a pair: (Capability, Domain) and assigns ownership of resolution for each domain to an explicit Resolution Authority. This distinction is not an argument that selector-based routing is deficient. EIP-2535 and CARE address partially overlapping but different questions. EIP-2535 defines a modular dispatch and reconfiguration mechanism. CARE defines responsibility ownership and the architectural scope within which an execution target is resolved.

2.2

State, Lifecycle, and Responsibility Boundaries

Persistent state often has a longer lifecycle than the executable logic that manipulates it. Work on Ethereum state emphasizes the complexity and importance of persistent storage [8], while empirical upgradeability studies similarly treat preservation of existing state as a central concern [4, 23]. CARE does not introduce a new storage-migration protocol. Instead, it applies the distinction between behavior and state at the architectural level. Shared Architectural State owns architectural information independently from the lifecycle of individual Execution Modules. An EM may access state without becoming the owner of that state. This distinction is summarized as: Access(x) ̸⇒ Ownership(x) Version management and governance form another separate concern. LEAGAN addresses decentralized revision and version management [6], while TRUST considers a broader governed lifecycle involving version traceability, rollback-related concerns, and provenance [5]. CARE does not reproduce those mechanisms. A capability-binding update in CARE may be governed

4

through an external governance mechanism, but the governance protocol itself is outside the architecture defined here. Prior smart-contract design-pattern research also examines modularity, maintainability, control, and security [9]. CARE adopts a stricter responsibility-oriented interpretation of modularity: components are distinguished not merely because they are separately deployed but because they own different architectural decisions. In particular: ExecutionCoordination ̸= ExecutionResolution ̸= BehaviorExecution The three responsibilities may cooperate during one request while remaining independently owned.

2.3

Security, Observation, and Formal Reasoning

Smart-contract security research includes defect classification, vulnerability taxonomies, weakness analysis, detection, and repair [10–15]. Such work makes clear that architectural structure alone cannot establish implementation security. CARE therefore does not infer security from modularity. Instead, its architecture makes trust and responsibility boundaries explicit, and the reference implementation is evaluated separately through adversarial tests. Observation presents a similar distinction. Blockchain transactions and events provide visibility, but visible activity is not automatically architecturally understandable. Prior work distinguishes transparency, accountability, and understandability [16]. CARE assigns architectural observation to a dedicated Observation Hub so that ownership of the observation concern is explicit. This does not imply universal failure isolation. A telemetry failure may reasonably be ignored in one implementation, while a mandatory compliance record may need to make a transaction fail in another. Formal methods have also been applied to smart contracts at multiple abstraction levels [17]. Model-based approaches demonstrate the value of specifying relevant structures and properties before implementation [18]. CARE combines two formal layers: Architectural Formalization → Behavioral Model Checking The first defines the architecture deductively. The second uses TLA+ and TLC to explore selected transitions and invariants. Neither layer constitutes bytecode-level verification. Finally, the CARE model is conceptually independent of Solidity, but the empirical evidence in this paper is EVM-specific. Smart-contract platforms differ substantially in execution, state, and interaction semantics [19]. A realization on another platform would therefore have to map CARE’s responsibilities onto that platform rather than directly reproduce the Solidity implementation.

5

Table 1. Positioning of CARE Relative to Existing Smart-Contract Evolution and Modularity Approaches Approach

Primary concern

Main unit of change

CARE distinction

Implementation

Adds domain ownership of resolution Separates coordination from domain-scoped resolution Defines independent architectural-state ownership Focuses on runtime responsibility organization Defines one responsibilityownership model Characterizes trust boundaries rather than replacing security analysis Explicit ownership plus domain-scoped resolution

Proxy upgradeability [4, 23] Replaceable implementation EIP-2535 Modular dispatch

Selector / facet

State-oriented work [8]

Storage / data

Persistent state

LEAGAN / TRUST [5, 6]

Version and lifecycle man- Version / lifecycle agement Design-pattern research [9] Reusable design knowledge Pattern Security research [10–15]

Vulnerability analysis

Code / weakness

CARE

Responsibility-oriented runtime architecture

Capability / domain / responsibility

The research gap addressed here is therefore not the absence of upgradeability, modularity, state management, governance, security, or formal methods individually. It is the absence, within the studied approaches, of a runtime architectural model combining explicit responsibility ownership with domain-scoped capability resolution while separately representing coordination, resolution, behavior, architectural state, reusable services, and observation. Open-source artifacts. The CARE artifacts are publicly available at https://github.com /rajabinekoo/CARE-Architecture, including the reference implementation of the architecture, its formal TLA+ specification, and the TLC model-checking results reported in this paper.

3

CARE Architecture and Formal Model

3.1

Design Principles

CARE is based on six architectural requirements. R1 — Explicit responsibility ownership. Major architectural decisions should have identifiable owners rather than emerge implicitly from contract placement. R2 — Domain-scoped resolution. Execution resolution should occur inside an explicit functional domain rather than depend on one global capability namespace. R3 — Independent architectural-state ownership. Business modules may access architectural information without owning its lifecycle or mutation policy. R4 — Independent shared-service ownership. Reusable capabilities should remain independent of individual workflows that consume them. R5 — Explicit architectural observation. Observation should have an identifiable architectural owner rather than being implicitly distributed across business modules. R6 — Localized evolution. Replacing one capability implementation should primarily modify resolution state for its domain

6

rather than require unrelated modules or the central coordinator to change.

Fig. 1. High-level CARE architecture and responsibility boundaries across the Runtime Kernel, Resolution Authorities, Execution Modules, Shared Architectural State, Shared Architectural Services, and Observation Hub.

3.2

Architectural Components

CARE contains six component classes. 3.2.1

Runtime Kernel

The Runtime Kernel (RK) owns Execution Coordination. It receives an execution request, identifies the requested domain and capability, locates the responsible Resolution Authority, obtains the current target, and transfers control to the selected Execution Module. Its role is: Request → Coordination → Resolution → Execution

7

RK does not own business behavior and does not own the domain’s capability-to-module resolution policy. 3.2.2

Resolution Authority

A Resolution Authority (RA) owns Execution Resolution for one domain. Given a capability identifier c, an RA determines which Execution Module currently implements that capability inside its domain. Multiple RAs may exist simultaneously. Consequently, identical capability identifiers may resolve differently: Resolve(C1 , RA1 ) = EM1 Resolve(C1 , RA2 ) = EM3 without ambiguity. 3.2.3

Execution Module

An Execution Module (EM) owns Behavior Execution. An EM implements a business capability after resolution has selected it. It may consume architectural state or shared services, but use of those concerns does not transfer ownership to the module. 3.2.4

Shared Architectural State

Shared Architectural State (SS) owns Architectural State Management. SS represents a logical state-ownership boundary. This does not require all architectural information to be physically stored inside a single contract. A platform may distribute the representation while preserving an identifiable architectural owner. Operational business state is not automatically SS merely because several modules use it. SS refers specifically to architectural information whose lifecycle belongs to the architecture rather than to one business module. 3.2.5

Shared Architectural Service

A Shared Architectural Service (SA) owns Shared Capability Provision. An SA exposes reusable behavior to multiple EMs while preserving its own responsibility and lifecycle boundary. The relationship is usage: Use(EM, SA) rather than ownership. In the formal model evaluated here, SA does not depend on SS. This preserves an explicit separation between reusable behavior and architectural-state ownership.

8

3.2.6

Observation Hub

The Observation Hub (OH) owns Architectural Observation. RK, RA, EM, or SA may publish architectural observations through OH. The architecture specifies ownership of the observation concern, not a universal policy for observation failure. Table 2. CARE Architectural Components and Responsibility Ownership Component

Primary responsibility

Typical interaction

Does not own

RK

Execution coordination

RA, EM, SS, OH

RA

Domain-scoped resolution

RK, OH

EM SS

Behavior execution Architectural-state management Shared capability provision Architectural observation

RK, SS, SA, OH RK, EM

Resolution policy; business behavior Business behavior; architectural state Resolution; SS ownership Business behavior

SA OH

3.3

EM, OH Observation producers

Workflow ownership; resolution Coordination; resolution; execution

Domain-Scoped Execution

Every execution request identifies: 1. a capability c; 2. the domain whose Resolution Authority owns the resolution decision. The normal execution path is: Req → RK → RAd → EM → Result The Runtime Kernel therefore owns the execution path but not the resolution mapping itself. This becomes important during evolution. Suppose: Resolve(C1 , RA1 ) = EM1 and the implementation of C1 in domain RA1 is replaced by EM2 . The relevant transition is: Resolve(C1 , RA1 ) : EM1 → EM2 No corresponding change is implied for: Resolve(C1 , RA2 ) or any other unrelated binding. This is the structural basis of localized capability evolution.

9

Fig. 2. Domain-scoped capability execution in CARE, showing the separation of execution coordination, domain-specific resolution, behavior execution, shared architectural concerns, and observation.

3.4

Formal Definition

CARE is modeled as: A = (E, R, M, C) where: • E is the set of architectural entities; • R is the set of architectural responsibilities; • M contains architectural relations and mappings; • C contains architectural constraints. The entity set is partitioned into six pairwise-disjoint classes: E = RK ∪ RA ∪ EM ∪ SS ∪ SA ∪ OH such that, for any distinct component classes X and Y , X ∩Y =∅ The model contains one logical Runtime Kernel, architectural-state ownership boundary, and Observation Hub: 10

|RK| = 1,

|SS| = 1,

|OH| = 1

while allowing multiple Resolution Authorities and Execution Modules and optional Shared Architectural Services: |RA| ≥ 1,

|EM| ≥ 1,

|SA| ≥ 0

The singleton constraints describe architectural roles in the model rather than requiring every realization to use exactly one physical contract for those roles.

3.5

Responsibility Ownership

The fundamental responsibility set is:

R=

  ExecutionCoordination,      ExecutionResolution,     

BehaviorExecution,

           

  StateManagement,             SharedCapabilityProvision,        

ArchitecturalObservation

Responsibility types are assigned as follows: OwnerType(ExecutionCoordination) = RK, OwnerType(ExecutionResolution) = RA, OwnerType(BehaviorExecution) = EM, OwnerType(StateManagement) = SS, OwnerType(SharedCapabilityProvision) = SA, OwnerType(ArchitecturalObservation) = OH. Multiple instances may own independent instances of the same responsibility category. Multiple RAs, for example, each own resolution within their respective domains. The model prohibits ambiguity over ownership of one concrete architectural decision while permitting distributed ownership across independent domains.

3.6

Invocation Constraints

CARE does not permit arbitrary architectural dependencies. The legal relation is: InvokeRel ⊆ (RK × RA) ∪ (RK × EM) ∪ (RK × SS) ∪ (EM × SS) ∪ (EM × SA) ∪ (RK × OH) ∪ (RA × OH) ∪ (EM × OH) ∪ (SA × OH) These edges represent permitted architectural dependency directions. They do not require each implementation to exercise every edge. For example,

11

EM → SA is permitted, whereas SA → SS is not part of the CARE model evaluated in this paper. The architectural invocation graph satisfies: G(E, InvokeRel) is a DAG This is an architectural dependency constraint. It must not be confused with runtime reentrancy: EVM calls may still produce nested execution despite an acyclic architectural dependency model.

3.7

Domains and Resolution

Every Execution Module belongs to one resolution domain: Domain : EM → RA Requests are mapped to a capability and Resolution Authority: ReqTarget : Req → Cap × RA If: ReqTarget(req) = (c, ra) then ra owns resolution of capability c for that request. Resolution is defined as: Resolve : Cap × RA → EM and is single-valued for an active capability-domain binding: ∀c ∈ Cap, ∀ra ∈ RA : |{em | Resolve(c, ra) = em}| ≤ 1 When a module is resolved, its domain must match the resolving authority: Resolve(c, ra) = em ⇒ Domain(em) = ra This authority–module conformance condition became particularly important during machinechecked validation.

3.8

Architectural State, Services, and Observation

State access is distinct from state ownership. CARE defines: StateAccess ⊆ (RK ∪ EM ∪ AdminUser) × SS 12

and architectural reads as: StateRead : (RK ∪ EM) × SS × Ctx → State An Execution Module may therefore consume SS information without owning its lifecycle. Mutation is more restricted: StateWrite : Ω × SS × Ctx → new_State where the architectural model permits: Ω = RK ∪ AdminUser The Solidity reference implementation adopts a stricter policy and restricts SS mutation to its administrative authority. CARE therefore distinguishes: Read Access ̸= Write Authority ̸= State Ownership Shared-service use is represented by: Use : EM × SA → Cap with: Use(em, sa) ̸⇒ Own(em, sa) Observation is separately owned by OH. Execution components may produce observations, but producing an observation does not make them owners of the observation mechanism.

3.9

Derived Structural Properties

The preceding definitions produce five architectural properties. 3.9.1

DP1 — Unique Responsibility Ownership

Each fundamental architectural responsibility has an explicit owner type, while instance-level ownership is scoped to the relevant component or domain. The property eliminates ambiguity in the model over which architectural role owns a decision. It does not prove lower maintenance effort. 3.9.2

DP2 — Domain-Scoped Centralized Capability Resolution

Within one domain, capability resolution is owned by one Resolution Authority: (c, ra) → em Resolution is therefore centralized inside each domain while distributed across domains. It does not establish unrestricted scalability.

13

3.9.3

DP3 — Architectural State Ownership Independence

Access by an EM does not transfer state ownership: StateRead(em, ss, ctx) ̸⇒ OwnerType(StateManagement) = EM Behavior modules can therefore evolve independently from ownership of architectural state. This does not solve arbitrary data migration. 3.9.4

DP4 — Shared Service Ownership Independence

For: Use(em1 , sa) ∧ Use(em2 , sa) neither consumer becomes the architectural owner of sa. This creates an independent lifecycle boundary for reusable behavior. 3.9.5

DP5 — Structural Observation Separation

Architectural observation is owned independently from execution coordination, resolution, and business execution. This property is structural. It does not imply: ObservationFailure ⇒ NoEffectOnExecution for every implementation. Table 3. Derived CARE Structural Properties and Explicit Non-Claims Property

Architectural statement

Not claimed

DP1

Responsibilities have explicit owners Resolution is unique within a domain SS ownership is independent of EM access SA ownership is independent of consumers Observation is structurally separated

Proven maintainability

DP2 DP3 DP4 DP5

Universal scalability Automatic storage migration Automatic service quality/reuse Universal failure isolation

The formal model therefore defines architectural structure and ownership. It does not establish freedom from implementation bugs, reentrancy, storage collision, malicious code, or platformspecific failures. These concerns motivate the two additional evidence layers used below: machine-checked behavioral validation and executable evaluation.

14

4

Machine-Checked Behavioral Validation

4.1

Validation Model

The core behavioral semantics of CARE were encoded in TLA+ to examine whether selected architectural invariants remain preserved across sequences of configuration and execution operations. The specification follows: Spec = Init ∧ □[Next]vars where Init defines the valid initial configuration and Next defines allowed transitions. The modeled transitions include: • domain registration; • capability binding; • architectural-state mutation; • domain-scoped execution; • capability reconfiguration; • the handled observation-failure behavior used by the reference policy. TLC is used to exhaustively explore the reachable state space of a bounded finite instance. Intermediate TLC results were used during development to refine the architectural model and corresponding implementation constraints before the final validation run.

Fig. 3. Machine-checked validation workflow for CARE, from the formal architectural model to the bounded TLA+ behavioral specification, invariant checking with TLC, and model or implementation refinement.

15

4.2

Finite Bounds Table 4. Finite Bounds of the TLA+ Behavioral Validation Model

Model element

Bound

Domains Resolution Authorities Capabilities Execution Modules Actors Architectural-state keys Architectural-state values

D1, D2 RA1, RA2 C1, C2 EM1, EM2, EM3 admin, user, attacker K1, K2 0..1

RA1 is associated with D1 and RA2 with D2 through an explicit authority-domain relation. The model tracks domain registrations, capability bindings, architectural-state values, execution domain and capability, selected module, business status, observation status, selected previous configuration values, and the actor responsible for mutations. The finite bounds exist to make exhaustive exploration tractable. They do not constrain the number of entities permitted by the CARE architecture.

4.3

Architectural Invariants

Seven invariants were enabled in the final configuration. Table 5. Architectural Invariants Evaluated with TLC Invariant

Evaluated property

TypeOK AuthorizedArchitecturalWriters

Variables remain within their modeled domains Configuration and SS mutation are performed only by the modeled administrator Updating one capability leaves unrelated bindings unchanged Under the modeled handled-failure policy, an OH failure does not convert successful business execution into failure A successful execution target follows the active domain → RA → capability → EM chain Each domain-capability pair has at most one active execution target A registered RA matches its declared domain

LocalizedCapabilityReconfiguration ObservationFailureIsolation

ExecutionTargetWasResolved UniqueDomainScopedResolution RegisteredAuthorityMatchesDomain

ObservationFailureIsolation is intentionally implementation-policy-specific. It is included because the evaluated Solidity reference implementation uses handled observation failures. It is not elevated to a universal CARE invariant.

4.4

Exploration Results

The final model was evaluated using TLC 2.20 with breadth-first exploration and eight workers.

16

Table 6. Final TLC State-Space Exploration Results Metric

Result

Generated states Distinct reachable states States left on queue Complete graph depth Evaluated invariants Recorded runtime Outcome

1,805,161 360,980 0 12 7 9,872 ms No invariant violation found

Zero states remaining in the queue indicates that TLC completed exploration of the reachable state space for the selected finite bounds. The appropriate conclusion is therefore: No violation of the seven evaluated invariants was found in the explored bounded CARE model. This is machine-checked evidence for the modeled properties. It is not complete verification of Solidity source code, arbitrary EVM behavior, or unbounded CARE deployments. The three evidence layers used by this paper can therefore be summarized as: Formal Architecture → Machine-Checked Behavior → Executable Evaluation

5

Evaluation Methodology

5.1

Research Questions

The empirical evaluation examines the operational cost of the architectural decisions introduced by CARE. Four research questions are considered. RQ1 — Runtime Cost. What runtime cost does domain-scoped resolution introduce relative to the evaluated modular baselines? RQ2 — Architectural Growth. How do routing cardinality and finer domain partitioning affect dispatch cost and one-time architectural setup cost? RQ3 — Localized Evolution. What is the operational cost of replacing capability bindings, and how does it compare with a minimal routing update and the evaluated EIP-2535 reconfiguration path? RQ4 — Independent Architectural Concerns. What incremental cost is introduced by SS, SA, and OH? The purpose is not to select scenarios favorable to CARE. The experiments deliberately distinguish runtime execution, architectural construction, and evolution because the architecture may increase cost in one dimension while localizing it in another.

5.2

Reference Implementation and Baselines

The reference artifact implements the six CARE component classes in Solidity. 17

The Runtime Kernel receives a domain and capability, obtains the relevant Resolution Authority, resolves the corresponding Execution Module, and invokes it through delegated execution. Three execution levels are used. 5.2.1

Direct

The Direct path executes the benchmark workload without modular routing. It provides a lower-bound reference for workload cost and is not treated as an upgradeable competitor. 5.2.2

EIP-2535 Diamond

The practical Diamond baseline is a standards-oriented implementation. In benchmark v2.1, the evaluated Diamond stack contains: • a DiamondCutFacet, installed during Diamond deployment and recorded through a DiamondCut event; • a DiamondLoupeFacet, installed before measured workload registration, dispatch, and reconfiguration; • Add, Replace, and Remove selector-to-facet bookkeeping through diamondCut; • standardized facet and selector introspection through the loupe interface; • fallback-based delegated execution. The purpose of this baseline is to represent the management and dispatch mechanisms relevant to the evaluated EIP-2535 path rather than a selector-only proxy. 5.2.3

DiamondCore

DiamondCore is a deliberately minimal selector-to-target routing map. It is not an EIP-2535 implementation. Its purpose is to separate the cost of a simple mapping replacement from the additional facet-management work performed by the EIP-2535-oriented baseline. This distinction is particularly important for RQ3.

18

Fig. 4. Structure of the CARE Solidity reference implementation and the principal interaction paths among the Runtime Kernel, Resolution Authority, Execution Modules, Shared Architectural State, Shared Architectural Services, and Observation Hub.

19

Fig. 5. EIP-2535 Diamond baseline used in the empirical evaluation, including DiamondCutFacet, DiamondLoupeFacet, selector-to-facet bookkeeping, and fallback-based delegated execution to the benchmark facet.

5.3

Experimental Design

Five experiment groups are used. 5.3.1

E1 — Workload Ladder

The same benchmark behavior is exercised through Direct, EIP-2535, DiamondCore where applicable, and CARE paths.

20

Workload

Description

W0 W1 W2 W3 W4

Minimal computation Operational state write External read External state-changing call, state write, and event Marketplace-style ERC-20/ERC-721 workflow

The workload ladder distinguishes absolute routing overhead from its relative contribution to transactions of different base costs. 5.3.2

E2 — Routing Cardinality

Routing tables containing: 1, 10, 50, 100 entries are evaluated. This experiment asks only whether dispatch gas changes within the tested range. It does not test unrestricted scalability. 5.3.3

E3 — Domain Growth

A fixed total of 100 capabilities is partitioned across: 1, 2, 5, 10, 20 Resolution Authorities. Capabilities per RA therefore become: 100, 50, 20, 10, 5 respectively. Keeping total functionality fixed isolates the cost of architectural partitioning. 5.3.4

E4 — Evolution Sensitivity

The benchmark replaces: 1, 5, 10, 25 routing entries using: • EIP-2535; • DiamondCore; • CARE Resolution Authority bindings.

21

5.3.5

E5 — Architectural Concern Ablation

CARE-specific concerns are introduced incrementally. Scenario

Enabled behavior

A0 A1 A2 A3 A4 A5

RK + RA + EM A0 + SS read A0 + SA invocation A0 + SS + SA A3 + OH A3 + forced OH failure under reference handling policy

SS and SA are tested independently because they represent different architectural responsibilities.

5.4

Measurements and Environment

Gas consumption is the primary quantitative metric. Gas is deterministic for equivalent transactions under the same EVM state, calldata, compiler configuration, and execution environment. Repeated identical executions are therefore not treated as independent statistical samples. Selected opcode traces are additionally used to explain measured differences, particularly additional storage accesses, external calls, and delegated execution. The evaluation artifact uses: • benchmark version 2.0.0; • Solidity 0.8.28; • compiler optimization with 200 runs; • Cancun EVM target; • local Hardhat network; • Node.js v24.18.0; and • chain ID 31337. The environment is intended for deterministic architectural comparison rather than networklevel performance benchmarking.

22

6

Results

6.1

RQ1 — Runtime Cost Table 7. Runtime Gas Consumption Across the Workload Ladder

Workload

Direct

EIP-2535

DiamondCore CARE

CARE − EIP- Relative dif2535 ference

W0 W1 W2 W3 W4

21,621 43,656 25,221 70,619 66,180

26,564 48,599 30,167 75,565 71,153

26,667 48,702 30,270 75,668 71,256

7,750 7,762 7,762 7,762 7,687

34,314 56,361 37,929 83,327 78,840

29.17% 15.97% 25.73% 10.27% 10.80%

CARE consumed more gas than the EIP-2535 execution path in all five workloads. The absolute difference remained narrow: 7,687 ≤ ∆Gas ≤ 7,762 with an arithmetic mean of approximately 7,745 gas across the five workloads. The percentage difference changes because each workload has a different underlying execution cost. CARE’s 29.17% premium for W0 falls to 10.27% for W3 and 10.80% for W4. This does not mean that CARE becomes computationally faster as workload complexity increases; rather, the approximately fixed routing premium becomes a smaller fraction of a larger transaction. Opcode traces support this interpretation. CARE performs one additional SLOAD and one additional STATICCALL relative to the evaluated EIP-2535 path, while both paths use one DELEGATECALL. This pattern is consistent with the additional domain-to-authority resolution step. RQ1: the evaluated CARE implementation adds an approximately fixed 7.7k-gas runtime resolution premium.

Fig. 6. Runtime gas consumption across the workload ladder for Direct execution, EIP-2535, DiamondCore, and CARE.

6.2

RQ2 — Architectural Growth

Routing cardinality had little observable effect within the tested range.

23

At 1, 10, 50, and 100 entries, the evaluated EIP-2535 path remained at approximately 26.6k gas, while CARE remained approximately 34.4k gas. The domain-partitioning experiment produced a different effect. Table 8. CARE Domain Partitioning with 100 Total Capabilities CARE domains

Capabilities / domain

EIP-2535 dispatch

CARE dispatch

Runtime difference

CARE partitioning cost

1 2 5 10 20

100 50 20 10 5

26,629 26,629 26,629 26,629 26,629

34,391 34,391 34,391 34,391 34,391

7,762 7,762 7,762 7,762 7,762

2,956,705 3,356,418 4,555,557 6,554,098 10,550,868

Per-request dispatch remains unchanged as the number of configured RAs increases from one to twenty in this experiment. One-time architecture construction does not. CARE partitioning cost rises from approximately 2.96 million gas for one Resolution Authority to 10.55 million gas for twenty. The increase results from deploying and registering additional authorities while the total number of capabilities remains fixed. RQ2: finer domain decomposition did not increase measured request dispatch cost within the evaluated range, but it substantially increased one-time deployment and configuration cost.

Fig. 7. Effect of CARE domain partitioning on per-request dispatch gas and one-time deployment and configuration cost while holding the total capability count constant at 100.

6.3

RQ3 — Localized Evolution Table 9. Localized Capability Reconfiguration Gas Across Replacement Cardinalities

Replaced entries

EIP-2535

DiamondCore

CARE

CARE vs. DiamondCore

CARE vs. EIP2535

1 5 10 25

134,087 179,512 258,112 470,559

33,261 66,509 108,081 232,761

33,464 67,348 109,715 236,756

+0.61% +1.26% +1.51% +1.72%

−75.04% −62.48% −57.49% −49.69%

24

Fig. 8. Localized reconfiguration cost for CARE, DiamondCore, and the evaluated EIP-2535 implementation across increasing replacement cardinalities. CARE remains close to the routing-only control while the evaluated EIP-2535 path incurs additional selector and facet management cost.

CARE remains close to the routing-only control across all evaluated replacement sizes. The difference from DiamondCore ranges from 0.61% to 1.72%. The practical EIP-2535 path performs more management work and therefore exhibits a substantially different gas profile. For one replacement: CARE = 33,464 versus: EIP-2535 = 134,087 For 25 replacements: CARE = 236,756 versus: EIP-2535 = 470,559 Opcode traces explain much of the difference. For one replacement, CARE and DiamondCore each perform one SLOAD and one SSTORE, whereas the evaluated EIP-2535 path performs 24 SLOAD and 15 SSTORE operations and includes a DELEGATECALL. At 25 replacements, CARE and DiamondCore each perform 25 SLOAD and 25 SSTORE operations; the EIP-2535 path performs 312 SLOAD and 207 SSTORE operations. These measurements should not be interpreted as evidence that CARE is universally cheaper than Diamond. The operations perform different amounts of bookkeeping. 25

The more defensible result is that CARE’s localized capability update remains operationally close to a minimal routing-map update in the evaluated implementation. This empirical result aligns with the formal property tested by LocalizedCapabilityReconfiguration: changing one domain-capability binding leaves unrelated bindings unchanged. RQ3: localized CARE evolution remains near the minimal routing control while avoiding modification of unrelated resolution state.

6.4

RQ4 — Independent Architectural Concerns Table 10. Incremental Gas Cost of CARE Architectural Concerns

Scenario

Gas

Difference from relevant base

A0 — RK + RA + EM A1 — A0 + SS read A2 — A0 + SA call A3 — A0 + SS + SA A4 — A3 + OH A5 — A3 + forced OH failure

34,176 40,541 40,497 48,109 60,471 59,937

— +6,365 +6,321 +13,933 +12,362 +11,828

SS and SA introduce similar but independently measurable overheads: 6,365 and 6,321 gas respectively. The combined path consumes 48,109 gas, 13,933 above A0. Adding successful observation raises the path to 60,471 gas. In A5, the Observation Hub is forced to revert. Under the selected reference implementation policy, the observation failure is caught after successful business execution, and the transaction consumes 59,937 gas without changing the successful business result. This behavior demonstrates only the chosen reference policy. CARE does not require observation failures to be ignored. The result is architecturally useful because SS and SA are measured independently. Shared state ownership and shared service behavior remain separate both conceptually and operationally. RQ4: SS, SA, and OH have distinct measurable implementation costs; CARE does not make responsibility separation operationally free.

6.5

Empirical Summary

The experiments expose three principal cost dimensions. First, explicit domain-scoped resolution adds runtime indirection, measured at approximately 7.7k gas in the tested execution paths. Second, finer domain decomposition increases one-time architectural setup cost even though request dispatch remained stable within the tested domain counts. Third, localized capability replacement remains close to a minimal mapping update. CARE therefore does not eliminate architectural cost. Instead, it redistributes cost among: • Runtime Dispatch; • Architectural Construction; • Localized Evolution; 26

This cost structure is central to interpreting CARE as an architecture rather than as a gas-optimization technique.

7

Threat Model and Security Characterization

7.1

Trust Assumptions

The security analysis treats the integrity of the following as security-relevant: • RK configuration; • domain-to-RA registration; • RA capability bindings; • Shared Architectural State; • Observation Hub records; • execution through registered modules. The configured administrator is trusted and assumed not to be compromised. RK, RA, SS, and OH reference components are trusted. Ordinary callers, unauthorized contracts, external dependencies, adversarial calldata, and unregistered modules are potentially untrusted. The most consequential trust assumption concerns Execution Modules. The Runtime Kernel invokes an EM through delegatecall. The selected module therefore executes inside RK’s storage context. Consequently: A registered Execution Module is part of the Runtime Kernel’s trusted computing base. Responsibility separation is not a bytecode sandbox.

7.2

Configuration Integrity

The reference implementation restricts: • domain registration; • capability binding; • Shared Architectural State mutation; • observation emitter configuration to the configured administrative authority. Adversarial tests attempt these operations from unauthorized accounts and require failure. The reference implementation also validates domain–authority consistency during Resolution Authority registration. These controls protect the evaluated configuration surface from ordinary unauthorized mutation. They do not protect against malicious or compromised administration. 27

7.3

Shared-State Boundary

The Solidity realization applies a stricter SS write policy than the general architectural model: architectural-state mutation is administrator-only. An ordinary execution path through EM therefore cannot mutate SS through its public administrative interface. This property applies only to CARE Shared Architectural State. It does not imply that arbitrary business state used by an application is similarly protected.

7.4

Delegated Execution

delegatecall preserves the Runtime Kernel execution context but allows the delegated bytecode to access its storage. An adversarial Execution Module was therefore deliberately registered and executed through RK. The module directly overwrote a Runtime Kernel storage slot. The successful corruption demonstrates the boundary intentionally: Approved EM ̸⇒ Sandboxed EM CARE controls which module is selected. The evaluated architecture does not establish that administrator-approved bytecode is safe. A production system may introduce code-hash allowlists, formal audits, governance restrictions, code provenance requirements, or alternative execution boundaries. These are possible hardening mechanisms, not intrinsic CARE properties.

7.5

Reentrancy and Nested Execution

CARE does not inherently prevent synchronous reentrancy. A delegated EM can make an external call to RK and request another registered domaincapability pair. Adversarial testing demonstrates that execution initiated in one domain can synchronously trigger a second execution in another domain. This behavior is not necessarily malicious. Cross-domain composition may be legitimate. The important conclusion is instead: Domain-Scoped Resolution ̸= Runtime Isolation Reentrancy-sensitive workflows remain responsible for appropriate implementation-level protection. A global non-reentrancy constraint is intentionally not defined as a CARE invariant because it could prohibit valid nested capability composition.

7.6

Observation Integrity

The reference OH accepts records only from authorized emitters, and emitter configuration is administrator-controlled. Unauthorized observation attempts and unauthorized emitter configuration are rejected by the adversarial tests. The executeObserved reference path performs business execution before attempting the observation call and uses handled failure semantics. A normal OH revert therefore does not revert a completed business operation under this implementation policy. 28

This result should not be generalized to all observation failures or to all CARE implementations. Gas exhaustion, malicious dependencies, or compliance-sensitive observation may require different semantics.

7.7

Security Interpretation

The evaluated implementation therefore enforces several useful boundaries: • unauthorized RK configuration changes are rejected; • unauthorized RA remapping is rejected; • domain–authority conformance is checked; • SS administrative mutation is protected; • observation producers are authorized. Three important risks remain outside these controls: 1. registered EM bytecode is trusted under delegatecall; 2. CARE does not inherently isolate reentrant or nested execution; 3. administrator compromise remains outside the evaluated protection model. CARE’s security contribution is therefore explicit trust-boundary definition and adversarial characterization, not a claim of complete smart-contract security. The existing artifact explicitly reaches the same conclusion: unauthorized configuration mutations are rejected, while delegated EMs remain trusted and CARE provides no generic reentrancy isolation.

8

Discussion and Threats to Validity

8.1

Runtime Overhead and Architectural Justification

CARE deliberately introduces an additional resolution boundary. In the evaluated implementation, each request traverses the Runtime Kernel and the domain-specific Resolution Authority before delegated business execution. This structure produces an approximately fixed 7.7k-gas premium relative to the evaluated EIP-2535 path. Opcode traces help explain this premium. Across the evaluated workloads, CARE performs one additional SLOAD and one additional STATICCALL relative to the EIP-2535 execution path, while both paths perform one DELEGATECALL. The measured premium is therefore consistent with the additional domain-to-authority resolution step rather than with workload-specific business computation. This overhead should be interpreted as the operational cost of representing domain-scoped resolution ownership explicitly on the EVM. CARE does not attempt to minimize transaction gas in isolation; it exchanges an additional per-request indirection for explicit resolution ownership, independently evolvable domains, and localized capability reconfiguration.

29

8.2

Applicability: Runtime Cost versus Localized Evolution

CARE pays the domain-scoped resolution premium on every execution, whereas reconfiguration cost is incurred only when capability bindings change. The lower reconfiguration cost should therefore not be interpreted as automatically amortizing the recurring runtime overhead. CARE is most applicable to evolution-intensive modular systems in which functional domains or capabilities are expected to change independently over time. In such systems, explicit ownership of resolution and localized reconfiguration may justify the recurring dispatch cost. The case becomes stronger when independent capability evolution is a recurring architectural requirement rather than an exceptional maintenance event. Conversely, a simple contract with limited modularity, a small and stable execution surface, or little expectation of independent evolution may not benefit from this additional indirection. Such systems may reasonably prefer direct execution, a conventional proxy, or a simpler routing mechanism. The appropriate interpretation is therefore: Additional Runtime Indirection ←→ Localized Resolution Ownership CARE is a design option for systems that value controlled, domain-local evolution, not a default architecture for every smart contract.

8.3

Domain Granularity

CARE does not prescribe one ideal domain size. Coarse domains require fewer Resolution Authorities and therefore lower deployment and configuration cost. Finer domains provide more independent resolution boundaries but require more architectural setup. Domain selection is consequently an architectural design decision rather than a parameter that should always be maximized. The empirical evidence only shows that domain count did not affect per-request dispatch gas from one to twenty RAs in the evaluated mapping-based implementation. It does not prove unrestricted scalability.

8.4

CARE and EIP-2535

The empirical comparison with EIP-2535 requires careful interpretation. EIP-2535 addresses selector-to-facet organization and standardized facet management. CARE asks which architectural component owns each responsibility and which domain owns capability resolution. The two therefore operate at different abstraction levels. A Diamond implementation could potentially adopt CARE-like responsibility boundaries. Likewise, a CARE architecture need not necessarily be implemented using the Solidity routing strategy evaluated here. The EIP-2535 comparison is useful because it provides a mature modular execution baseline. It should not be interpreted as a claim that CARE replaces Diamond. In particular, the lower reconfiguration gas observed for CARE reflects differences in the tested management operations. DiamondCore was included precisely to expose the cost of a simple routing update separately from full EIP-2535 bookkeeping.

30

Table 11. Feature-Level Comparison of CARE and EIP-2535 Dimension

EIP-2535

CARE

Resolution unit Introspection

Function selector → facet Standardized IDiamondLoupe

Change recording

Required DiamondCut event for function changes

Batch reconfiguration

Capability + domain → EM Per-capability RA resolution; no standardized system-wide loupe equivalent CapabilityBound in the reference RA and optional architectural observation; no equivalent core-wide standardized history interface bindBatch atomically rebinds multiple capabilities within one RA; no standardized cross-domain upgrade transaction No core immutability/finalization mechanism is currently defined

diamondCut atomically adds/replaces/removes multiple selectors and may execute initialization Immutable functions and immutable Diamonds are supported Standardized Authorized domain-local Add/Replace/Remove validity rebinding with module validity rules checks Authentication design is explicitly Governance protocol is outside implementation-defined CARE core; evaluated implementation uses administrative authority Facets execute through EMs execute through delegatecall delegatecall in Diamond storage in RK storage context context Not defined as a Explicit ownership across RK, responsibility-oriented RA, EM, SS, SA, and OH architecture

Immutable functionality

Update validation

Ownership / governance

Delegated execution

Responsibility ownership

The comparison therefore involves partially overlapping but non-identical feature sets. EIP2535 standardizes operational mechanisms that are not currently part of the CARE core, particularly facet introspection, standardized change history, explicit Add/Replace/Remove semantics, and immutable functions. These mechanisms provide useful transparency, upgradesafety, and tooling properties. They should not, however, be interpreted as establishing that Diamond is inherently more secure. EIP-2535 explicitly leaves ownership and authentication design to individual implementations and notes that diamondCut can perform delegated initialization with access to Diamond storage and must therefore be carefully restricted. CARE similarly retains trusted administrative and delegated-execution boundaries. The security comparison is therefore featureand threat-specific rather than a claim of universal superiority by either architecture.

8.5

Construct and Internal Validity

Gas accurately measures EVM execution cost under controlled conditions but is not a direct measure of maintainability, security, reliability, developer productivity, latency, or throughput. Similarly, the five derived CARE properties describe architectural structure. They do not empirically prove higher-level software quality. The experiments reduce internal confounding by reusing the same underlying workload across

31

execution paths where possible. The domain-growth experiment keeps total capability count fixed. The concern-ablation experiment enables responsibilities incrementally, and DiamondCore separates mapping mutation from EIP-2535 management overhead. Nevertheless, the compared systems are not semantically identical in every management operation. Gas differences should therefore be understood as measurements of the evaluated mechanisms, not perfect instruction-for-instruction comparisons.

8.6

External Validity

The Solidity implementation is a controlled research artifact rather than a production migration. The W4 marketplace workload introduces a representative ERC-20/ERC-721 application flow, but it is intentionally kept identical across execution paths so that architectural overhead remains measurable without application-specific confounding. The workload ladder spans minimal execution, storage mutation, external access, statechanging interactions, and a marketplace-style ERC-20/ERC-721 workflow. This increases coverage but cannot represent every DeFi, DAO, gaming, identity, payment, or cross-chain system. No production-scale migration study is included. This choice improves isolation of the architectural variables studied here but limits claims about industrial adoption, migration effort, and long-term maintenance. A production or mature open-source case study is therefore an important next empirical step. The evaluation is also EVM-specific. CARE’s conceptual model is not defined in Solidity terms, but no experimental evidence is currently provided for Solana, Move-based systems, TON, Hyperledger Fabric, or other execution environments.

8.7

Formal-Validation Validity

TLC exhaustively explores the reachable states of the selected bounded model, not every possible CARE deployment. The absence of an invariant violation means no counterexample was found inside that explored state space. The behavioral specification abstracts from detailed Solidity semantics including arbitrary bytecode behavior, storage layout, gas exhaustion, and complete reentrancy behavior. The machine-checked results therefore complement rather than replace implementation-level testing.

8.8

Security Validity

The adversarial evaluation is not a comprehensive smart-contract audit. It targets architectural configuration mutation, state access, observation authenticity, delegated storage behavior, and nested execution. Economic attacks, arbitrary dependency behavior, denial-of-service strategies, malicious administration, and the full range of Solidity vulnerabilities remain outside the evaluated coverage. This distinction is particularly important because CARE deliberately leaves registered EM bytecode within the TCB.

32

8.9

Upgrade and State-Evolution Validity

Localized capability replacement is not equivalent to a complete upgrade lifecycle. CARE currently does not define: • version approval; • timelocks; • staged activation; • rollback; • recovery from failed upgrades; • compatibility negotiation; • schema migration; • historical-state transformation. Independent SS ownership provides an architectural boundary within which state evolution can be managed. It does not itself solve schema compatibility. The empirical evolution results should therefore be read narrowly: they measure localized resolution-map change, not all consequences of upgrading production smart-contract systems.

8.10

Overall Architectural Interpretation

Taken together, the formal and empirical evidence supports a specific conclusion. CARE introduces: • an additional runtime resolution step; • explicit architectural responsibility boundaries; • independent domain-resolution ownership; • independent state and service ownership; • explicit observation ownership; • localized capability replacement. The architecture does not minimize all costs. It makes several costs and ownership decisions separately identifiable. That distinction is central. A routing architecture may answer where execution goes. CARE attempts to additionally make explicit who owns the decision, which scope the decision belongs to, and which surrounding architectural responsibilities remain independently evolvable.

33

9

Conclusion

This paper presented CARE, a responsibility-oriented architecture for modular and upgradeable smart-contract systems. CARE starts from the observation that modular execution does not by itself establish modular architectural responsibility. A system may distribute executable code across replaceable components while leaving ownership of execution coordination, target resolution, shared state, reusable services, and observation implicit. CARE separates these responsibilities across six architectural roles: Runtime Kernel, Resolution Authority, Execution Module, Shared Architectural State, Shared Architectural Service, and Observation Hub. Its central mechanism is domain-scoped capability resolution: (Capability, Domain) → ExecutionModule with execution coordination owned independently by the Runtime Kernel. A formal architectural model defines entities, responsibility ownership, legal invocation relations, state-access rules, service use, and domain-scoped resolution. Five structural properties follow from the model: unique responsibility ownership, domain-scoped centralized resolution, architectural-state ownership independence, shared-service ownership independence, and structural observation separation. The behavioral model was additionally encoded in TLA+ and evaluated with TLC. Seven architectural invariants were checked over a bounded state space, with intermediate TLC results used to refine the architectural model before the final validation run. The final exploration generated 1,805,161 states, including 360,980 distinct reachable states, and completed without invariant violation in the evaluated model. The Solidity evaluation demonstrated that this architectural structure has a measurable operational cost. CARE introduced an approximately fixed 7.7k-gas runtime routing premium relative to the evaluated EIP-2535 path. Increasing domain count did not increase measured request dispatch cost within the tested bounds, but finer domain decomposition substantially increased one-time architectural setup cost. Localized evolution exhibited the opposite trade-off. Capability replacement remained within approximately 0.61–1.72% of the routing-only control across the tested replacement sizes and required less gas than the evaluated EIP-2535 reconfiguration path. The result should not be interpreted as universal superiority over Diamond; it shows that CARE’s domain-local update remains close to a minimal mapping mutation in the evaluated realization. These results also delimit CARE’s intended applicability. The architecture is most relevant to modular systems in which capabilities or functional domains are expected to evolve independently and where explicit resolution ownership is an architectural requirement. For simple or rarely evolving contracts, the recurring resolution premium may not be justified relative to a direct or simpler routing architecture. Concern ablation further showed that Shared Architectural State, Shared Architectural Services, and Observation Hub integration each have separately measurable costs. Responsibility separation therefore has an operational price rather than being an abstract property with no runtime consequence. Security evaluation exposed equally important boundaries. Unauthorized architectural mutation is rejected by the tested configuration controls, but registered Execution Modules remain trusted under delegatecall. Domain-scoped resolution does not provide runtime isolation, and CARE does not inherently prevent reentrancy. Administrator compromise also remains outside the evaluated protection model. 34

The contribution of CARE is therefore neither universally lower gas nor a universal security improvement. It is an architectural model in which responsibility ownership, resolution scope, evolution boundaries, and their operational costs can be reasoned about separately. Future work should investigate complete upgrade governance, capability and authority versioning, rollback, state and schema migration, stronger execution isolation, and realizations outside the EVM. A complementary empirical direction is a migration study using an existing productionscale or mature open-source smart-contract system to measure applicability, decomposition effort, and long-term evolution. CARE should consequently be understood as a foundation for responsibility-oriented smartcontract architecture rather than as a final replacement for every modularity or upgradeability mechanism.

References [1] W. Zou, D. Lo, P. S. Kochhar, X.-B. D. Le, X. Xia, Y. Feng, Z. Chen, and B. Xu, “Smart contract development: Challenges and opportunities,” IEEE Transactions on Software Engineering, vol. 47, no. 10, pp. 2084–2106, 2021. [2] N. Kannengießer, S. Lins, C. Sander, K. Winter, H. Frey, and A. Sunyaev, “Challenges and common solutions in smart contract development,” IEEE Transactions on Software Engineering, vol. 48, no. 11, pp. 4291–4318, 2022. [3] G. Rosa, S. Scalabrino, S. Mastrostefano, and R. Oliveto, “Why and how developers maintain smart contracts,” Empirical Software Engineering, vol. 30, no. 3, p. 84, 2025. [4] I. A. Qasse, M. Hamdaqa, and B. Þ. Jónsson, “Immutable in principle, upgradeable by design: exploratory study of smart contract upgradeability,” Empirical Software Engineering, vol. 31, no. 2, p. 39, 2026. [5] E. M. Cruz, Y. H. J. Souza, G. S. A. Alcantara, and M. L. M. Peixoto, “TRUST: A lifecycle-oriented system architecture for governed evolution of smart contract applications,” Information and Software Technology, vol. 198, p. 108210, 2026. [6] G. Kumar, R. Saha, M. Conti, and W. J. Buchanan, “LEAGAN: A decentralized versioncontrol framework for upgradeable smart contracts,” IEEE Transactions on Services Computing, vol. 18, no. 3, pp. 1529–1542, 2025. [7] A. Vacca, A. Di Sorbo, C. A. Visaggio, and G. Canfora, “A systematic literature review of blockchain and smart contract development: Techniques, tools, and open challenges,” Journal of Systems and Software, vol. 174, p. 110891, 2021. [8] M. Ayub, T. Saleem, M. Janjua, and T. Ahmad, “Storage state analysis and extraction of ethereum blockchain smart contracts,” ACM Transactions on Software Engineering and Methodology, vol. 32, no. 3, pp. 1–32, 2023. [9] S. Azimi, A. Golzari, N. Ivaki, and N. Laranjeiro, “A systematic review on smart contracts security design patterns,” Empirical Software Engineering, vol. 30, no. 3, p. 95, 2025. [10] J. Chen, X. Xia, D. Lo, J. Grundy, X. Luo, and T. Chen, “Defining smart contract defects on ethereum,” IEEE Transactions on Software Engineering, vol. 48, no. 1, pp. 327–345, 2022. [11] F. R. Vidal, N. Ivaki, and N. Laranjeiro, “OpenSCV: an open hierarchical taxonomy for smart contract vulnerabilities,” Empirical Software Engineering, vol. 29, p. 101, 2024. 35

[12] M. Soud, G. Liebel, and M. Hamdaqa, “A fly in the ointment: an empirical study on the characteristics of ethereum smart contract code weaknesses,” Empirical Software Engineering, vol. 29, no. 1, p. 13, 2024. [13] M. di Angelo, T. Durieux, J. F. Ferreira, and G. Salzer, “Evolution of automated weakness detection in ethereum bytecode: a comprehensive study,” Empirical Software Engineering, vol. 29, no. 2, p. 41, 2024. [14] H. Guo, Y. Chen, X. Chen, Y. Huang, and Z. Zheng, “Smart contract code repair recommendation based on reinforcement learning and multi-metric optimization,” ACM Transactions on Software Engineering and Methodology, vol. 33, no. 4, pp. 1–31, 2024. [15] F. R. Vidal, N. Ivaki, and N. Laranjeiro, “Vulnerability detection techniques for smart contracts: A systematic literature review,” Journal of Systems and Software, vol. 217, p. 112160, 2024. [16] H. Al Ghanmi, S. Ahmadjee, and R. Bahsoon, “A systematisation of transparency, accountability and understandability in blockchain smart contracts,” ACM Transactions on Software Engineering and Methodology, 2026, advance online publication. [17] P. Tolmach, Y. Li, S.-W. Lin, Y. Liu, and Z. Li, “A survey of smart contract formal specification and verification,” ACM Computing Surveys, vol. 54, no. 7, pp. 1–38, 2022. [18] J. Köpke, G. Meroni, and M. Salnitri, “Designing secure business processes for blockchains with SecBPMN2BC,” Future Generation Computer Systems, vol. 141, pp. 382–398, 2023. [19] G. Falazi, U. Breitenbücher, F. Leymann, and S. Schulte, “Cross-chain smart contract invocations: A systematic multi-vocal literature review,” ACM Computing Surveys, vol. 56, no. 6, pp. 1–38, 2024. [20] Y. Wang, X. Chen, Y. Huang, H.-N. Zhu, J. Bian, and Z. Zheng, “An empirical study on real bug fixes from solidity smart contract projects,” Journal of Systems and Software, vol. 204, p. 111787, 2023. [21] X. Chen, Z. Qian, P. Liao, Y. Huang, C. Yang, and Z. Zheng, “Characterizing smart contract evolution,” ACM Transactions on Software Engineering and Methodology, vol. 34, no. 7, pp. 1–22, 2025. [22] X. Chen, P. Liao, Q. Kong, Y. Huang, and X.-C. Zhou, “Studying differentiated code to support smart contract update,” Empirical Software Engineering, vol. 28, no. 5, p. 119, 2023. [23] Z. Zhong, J. Chen, J. Wang, Q. Xue, J. Wu, L. Liu, X. Ying, and Z. Zheng, “Towards exploring developers’ struggles in developing upgradeable smart contracts,” IEEE Transactions on Software Engineering, vol. 51, no. 11, pp. 3072–3087, 2025.

36

Related documents

• CARE: A Responsibility-Oriented Architecture for Domain-Scoped Resolution in Modular and Upgradeable Smart Contracts#1011378
• 42 U.S.C. § 19222 — National research and development strategy for distributed ledger technology#588297
• PROCESS AND SCOPE#250827
• State Without a Landlord: An Architecture Proposal for Peer-to-Peer Replication of Durable Workflow State#1011376
• State Without a Landlord: An Architecture Proposal for Peer-to-Peer Replication of Durable Workflow State#965395