PaperlayerView exact revision on arXiv

Source-linked AI summary

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

Ali Rajabi Nekoo, Laleh Rasoul, Azadeh Zamanifar

arXiv:2609.17647v1cs.SE

TL;DR

Modular dispatch can replace execution logic without defining who owns broader architectural responsibilities, and CARE addresses this gap with explicit responsibility boundaries and domain-scoped resolution. Its formal model and TLA+ checks specify and validate selected architectural properties. In the evaluated workloads, CARE adds runtime routing cost while keeping localized replacement close to a routing-only control.

  • Problem

    Existing approaches address upgradeability, modularity, and other concerns individually, but the paper identifies a gap in runtime models combining explicit responsibility ownership with domain-scoped capability resolution.

    Source: §2.3 · p. 6

  • Method

    CARE defines component responsibilities and domain-scoped resolution in a formal architectural model, with behavioral semantics encoded in TLA+ and checked against architectural invariants.

    Source: §9 · p. 34

  • Results

    CARE’s tested path adds an approximately fixed 7.7k-gas runtime routing premium over EIP-2535, while finer domain decomposition increases setup cost and localized replacement remains close to a minimal mapping update.

    Source: §6.5 · p. 26, §9 · p. 34

  • Takeaways & Limitations

    CARE is positioned for modular systems where capabilities or functional domains are expected to evolve independently, not as a universal lower-gas or security-improvement replacement.

    Source: §8.2 · p. 30, §9 · p. 35

    CARE does not provide runtime isolation or inherently prevent reentrancy, and delegated Execution Modules remain trusted under delegatecall.

    Source: §9 · p. 34

Abstract

from arXiv · show

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 routing only 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

1 Introduction

Modular dispatch and replaceable code do not, by themselves, make ownership of broader architectural responsibilities explicit. CARE separates those responsibilities and domain-scopes capability resolution, then evaluates the model formally, empirically, and through adversarial tests.

CARE contribution

  • CARE separates execution coordination, resolution, business behavior, architectural state, shared services, and observation into explicit responsibility owners.The Runtime Kernel coordinates execution but does not own capability binding; the selected domain’s Resolution Authority chooses the active Execution Module.Source: §1 · pp. 2–3

Scope

  • CARE defines runtime responsibility ownership, not a complete lifecycle framework for governance, versioning, rollback, storage migration, vulnerability detection, or implementation-specific security.These mechanisms may be composed with CARE; the model does not imply every implementation is automatically more maintainable, secure, reliable, or scalable.Source: §1 · pp. 2–3

Formal model and validation

  • CARE’s formal architectural model derives five structural properties, and its TLA+ model completed 360,980 reachable states without violating seven enabled invariants.Intermediate TLC results informed refinement before the final validation run.Source: §1 · p. 2

Empirical evaluation

  • CARE adds an approximately fixed 7.7k-gas runtime premium over the evaluated EIP-2535 path, while localized replacement remains within 0.61–1.72% of the routing-only control.The replacement path also required less gas than the evaluated EIP-2535 reconfiguration operation; finer domain decomposition increased one-time deployment and configuration cost.Source: §1 · p. 3

Security boundaries

  • Adversarial tests reject unauthorized architectural mutations, but delegated Execution Modules remain trusted under delegatecall and CARE does not inherently prevent reentrant or nested cross-domain execution.The paper cautions that the comparisons characterize tested implementations, not universal cost advantages over EIP-2535.Source: §1 · p. 3

2 Background and Related Work

Prior work addresses upgradeability, modular dispatch, state lifecycle, governance, security, observation, and formal methods, but CARE identifies a gap in combining these concerns under explicit runtime responsibility ownership and domain-scoped resolution.

2.1 Smart-Contract Evolution and Modular Execution

  • Upgradeable structures add indirection and are used in practice, while studies report complexity involving initialization, storage compatibility, and component interactions,.Smart-contract evolution also includes adaptation and internal improvement beyond corrective fixes,.Source: §2.1 · p. 4
  • EIP-2535 routes selectors to facets, whereas CARE assigns each domain’s capability resolution to an explicit authority; the approaches address overlapping but different questions.CARE’s distinction is not a claim that selector-based routing is deficient.Source: §2.1 · p. 4

2.2 State, Lifecycle, and Responsibility Boundaries

  • CARE separates architectural-state ownership from behavior: modules may access architectural information without owning its lifecycle, but the architecture does not add a storage-migration protocol.Version management and governance mechanisms such as LEAGAN and TRUST remain outside CARE.Source: §2.2 · pp. 4–5
  • CARE distinguishes components by the architectural decisions they own, not merely by separate deployment, and assigns observation to a dedicated Observation Hub.Observation ownership does not imply universal failure isolation; a telemetry failure may be ignored, while mandatory compliance recording may fail a transaction.Source: §2.2 · p. 5, §2.3 · p. 5

2.3 Security, Observation, and Formal Reasoning

  • CARE does not infer security from modularity: its architecture makes trust boundaries explicit, while the reference implementation is evaluated separately through adversarial tests.Formal layers explore selected transitions and invariants, but neither constitutes bytecode-level verification.Source: §2.3 · p. 5
  • The identified gap is a runtime model combining explicit responsibility ownership with domain-scoped capability resolution across coordination, resolution, behavior, state, services, and observation.The model is conceptually independent of Solidity, but the paper’s empirical evidence is EVM-specific; other platforms require a platform-specific mapping of responsibilities.Source: §2.3 · pp. 5–6

3 CARE Architecture and Formal Model

CARE defines explicit owners for architectural responsibilities and separates execution coordination from domain-specific target resolution. Its formal model specifies component relations and constraints, including localized capability evolution.

3.1 Design Principles

  • CARE’s six requirements call for explicit ownership, domain-scoped resolution, independent state and service ownership, explicit observation, and localized evolution.Replacing one implementation should primarily change resolution state for its domain rather than unrelated modules or the coordinator.Source: §3.1 · p. 6

3.2.1 Runtime Kernel

  • The Runtime Kernel receives a request, identifies its domain and capability, locates the responsible Resolution Authority, obtains the target, and transfers control to the selected Execution Module.The Kernel owns execution coordination, not business behavior or the domain’s capability-to-module policy.Source: §3.2.1 · pp. 7–8

3.2.2 Resolution Authority

  • A Resolution Authority determines which Execution Module implements a capability within its domain, allowing identical capability identifiers to resolve differently across authorities.The request identifies the domain whose authority owns the resolution decision.Source: §3.2.2 · p. 8, §3.3 · p. 9

3.2.3 Execution Module

  • An Execution Module implements business behavior after resolution; using architectural state or shared services does not transfer ownership of those concerns.Execution Modules may consume architectural state or shared services.Source: §3.2.3 · p. 8

3.2.4 Shared Architectural State

  • Shared Architectural State owns architectural information independently of individual modules, without requiring that information to reside in one contract.Business state is not automatically architectural state merely because multiple modules use it.Source: §3.2.4 · p. 8

3.2.5 Shared Architectural Service

  • A Shared Architectural Service provides reusable behavior to multiple modules while retaining its own responsibility and lifecycle boundary.In the evaluated formal model, the service does not depend on Shared Architectural State.Source: §3.2.5 · p. 8

3.2.6 Observation Hub

  • The Observation Hub owns architectural observation; the Kernel, authorities, modules, or services may publish observations through it.CARE specifies ownership of observation, not a universal policy for observation failure.Source: §3.2.6 · p. 9

3.3 Domain-Scoped Execution

  • Replacing one capability in one domain changes its resolution binding without implying changes to unrelated bindings.The Runtime Kernel owns the execution path but not the resolution mapping; this is the structural basis of localized capability evolution.Source: §3.3 · p. 9

3.4 Formal Definition

CARE is formally represented through architectural entities, responsibilities, relations and mappings, and constraints. Its model distinguishes component classes and allows responsibility ownership to be distributed across independent instances without ambiguity over an individual decision.

3.4 Formal Definition

  • CARE is modeled through sets of architectural entities and responsibilities, architectural relations and mappings, and architectural constraints.Source: §3.4 · p. 10
  • The entity set is partitioned into six pairwise-disjoint component classes.Source: §3.4 · p. 10
  • The model requires one logical Runtime Kernel, architectural-state ownership boundary, and Observation Hub, while allowing multiple Resolution Authorities and Execution Modules and optional Shared Architectural Services.These singleton constraints describe architectural roles, not a requirement for exactly one physical contract per role.Source: §3.4 · pp. 10–11

3.5 Responsibility Ownership

  • The fundamental responsibility set includes SharedCapabilityProvision and ArchitecturalObservation.Source: §3.5 · p. 11
  • Responsibility types are assigned within the model, while multiple instances may own independent instances of the same responsibility category.Source: §3.5 · p. 11
  • Multiple Resolution Authorities can own resolution in their respective domains, while the model prohibits ambiguity over ownership of any one concrete architectural decision.Source: §3.5 · p. 11

3.6 Invocation Constraints

CARE constrains architectural dependencies and scopes capability resolution to domains. It also separates architectural-state ownership, shared-service use, and observation from execution responsibilities.

3.6 Invocation Constraints

  • The architectural invocation graph is a DAG, but this constraint does not rule out nested runtime execution or reentrancy.Permitted dependency edges do not require each implementation to exercise every edge.Source: §3.6 · pp. 11–12

3.7 Domains and Resolution

  • A Resolution Authority owns resolution for a request's capability, and each active capability-domain binding is single-valued.A resolved module must belong to the same domain as the resolving authority.Source: §3.7 · p. 12

3.8 Architectural State, Services, and Observation

  • Execution Modules may consume shared-state information without owning its lifecycle, while the reference implementation restricts state mutation to its administrative authority.Source: §3.8 · p. 13
  • Observation is owned separately by the Observation Hub; producing an observation does not make an execution component the owner of that mechanism.Source: §3.8 · p. 13

3.9 Derived Structural Properties

CARE derives five structural properties from its architectural definitions: explicit responsibility ownership, domain-scoped resolution, independent state and shared-service ownership, and separated observation. These properties describe structure, not broader guarantees such as lower maintenance effort or freedom from implementation failures.

3.9 Derived Structural Properties

  • CARE derives five architectural properties from its preceding definitions.Source: §3.9 · p. 13

3.9.1 DP1 — Unique Responsibility Ownership

  • Each fundamental responsibility has an explicit owner type, with instance-level ownership scoped to the relevant component or domain.This removes ambiguity in the model over which architectural role owns a decision, but does not prove lower maintenance effort.Source: §3.9.1 · p. 13

3.9.2 DP2 — Domain-Scoped Centralized Capability Resolution

  • Within each domain, one Resolution Authority owns capability resolution, making resolution centralized per domain and distributed across domains.This property does not establish unrestricted scalability.Source: §3.9.2 · p. 13

3.9.3 DP3 — Architectural State Ownership Independence

  • An Execution Module's access to architectural state does not transfer ownership, allowing behavior modules to evolve independently of state ownership.This does not solve arbitrary data migration.Source: §3.9.3 · p. 14

3.9.4 DP4 — Shared Service Ownership Independence

  • Shared-service consumers do not become the architectural owner of the service, creating an independent lifecycle boundary for reusable behavior.Source: §3.9.4 · p. 14

3.9.5 DP5 — Structural Observation Separation

  • Architectural observation is owned independently from execution coordination, resolution, and business execution.This is a structural property, not a guarantee about every implementation.Source: §3.9.5 · p. 14
  • The formal model does not establish freedom from implementation bugs, reentrancy, storage collision, malicious code, or platform-specific failures.Source: §3.9.5 · p. 14

4 Machine-Checked Behavioral Validation

CARE's behavioral semantics are modeled in TLA+ and checked with TLC across bounded configurations, with intermediate results informing refinement. The final bounded exploration found no violation of the seven evaluated invariants, but does not verify Solidity source code or unbounded deployments.

4.1 Validation Model

  • The TLA+ behavioral model checks whether selected architectural invariants remain preserved across configuration and execution sequences.Modeled transitions include state mutation, domain-scoped execution, capability reconfiguration, and handled observation-failure behavior.Source: §4.1 · p. 15
  • Intermediate TLC results informed refinement of the architectural model and implementation constraints before the final validation run.Source: §4.1 · p. 15

4.2 Finite Bounds

  • The finite bounds make exhaustive exploration tractable and do not limit the number of entities permitted by the CARE architecture.The model tracks registrations, bindings, state, execution selections and outcomes, configuration values, and mutation actors.Source: §4.2 · p. 16

4.3 Architectural Invariants

  • Seven invariants were enabled in the final configuration, including an observation-failure property specific to the reference implementation policy rather than universal CARE.Source: §4.3 · p. 16

4.4 Exploration Results

  • 360,980 distinct reachable states were explored without violation of the seven enabled invariants in the final bounded model.TLC completed exploration of the reachable state space for the selected finite bounds.Source: §4.4 · p. 17, Table 6 · p. 17
  • The checked result is evidence for modeled properties, not complete verification of Solidity source code, arbitrary EVM behavior, or unbounded CARE deployments.Source: §4.4 · p. 17

5 Evaluation Methodology

The evaluation separates runtime execution, architectural construction, and evolution to measure CARE’s costs against modular baselines. It uses controlled workloads and concern ablations to distinguish routing overhead from setup and management costs.

5.1 Research Questions

  • Four research questions examine runtime cost, routing cardinality and domain growth, localized capability replacement, and the incremental costs of shared state, shared services, and observation.The design deliberately separates runtime execution, architectural construction, and evolution because CARE may increase cost in one dimension while localizing it in another.Source: §5.1 · p. 17

5.2 Reference Implementation and Baselines

  • The reference implementation realizes CARE’s six component classes in Solidity; its Runtime Kernel obtains a domain’s Resolution Authority, resolves a module, and invokes it through delegated execution.The Direct path supplies a lower-bound workload reference, while the modular baselines provide routing comparisons.Source: §5.2 · pp. 17–18, §5.2.1 · p. 18

5.2.2 EIP-2535 Diamond

  • The evaluated EIP-2535 baseline includes DiamondCut and DiamondLoupe facets, selector-to-facet management, introspection, and fallback-based delegated execution.It represents the evaluated management and dispatch mechanisms rather than a selector-only proxy.Source: §5.2.2 · p. 18

5.2.3 DiamondCore

  • DiamondCore is a minimal selector-to-target map used to separate simple mapping-replacement cost from the additional management work in the EIP-2535-oriented baseline.This distinction is particularly relevant to localized reconfiguration.Source: §5.2.3 · p. 18

5.3.1 E1 — Workload Ladder

  • The workload ladder compares the same behavior across execution paths, from minimal computation and state writes to external interactions and a marketplace-style ERC-20/ERC-721 workflow.The ladder distinguishes absolute routing overhead from its relative contribution to transactions with different base costs.Source: §5.3.1 · pp. 20–21

5.3.2 E2 — Routing Cardinality; 5.3.3 E3 — Domain Growth

  • Routing-cardinality tests ask whether dispatch gas changes over the tested table sizes, while domain-growth tests partition 100 capabilities across 1, 2, 5, 10, or 20 Resolution Authorities.Holding total functionality fixed isolates partitioning cost; the cardinality experiment does not test unrestricted scalability.Source: §5.3.2 · p. 21, §5.3.3 · p. 21

5.3.4 E4 — Evolution Sensitivity; 5.3.5 E5 — Architectural Concern Ablation

  • Evolution sensitivity measures CARE Resolution Authority binding changes, while concern ablations incrementally enable shared-state reads, shared-service invocation, observation, and a forced observation failure.Shared state and shared services are tested independently because they represent different responsibilities.Source: §5.3.4 · p. 21, §5.3.5 · p. 22

5.4 Measurements and Environment

  • Gas is the primary metric, with opcode traces used to explain differences; the controlled environment supports deterministic architectural comparisons rather than network-level performance benchmarking.Equivalent transactions under the same EVM state, calldata, compiler configuration, and environment are deterministic, so repeated executions are not treated as independent samples.Source: §5.4 · p. 22

6 Results

Across the evaluated workloads, CARE incurs an approximately fixed runtime routing premium, while finer domain partitioning raises one-time setup costs. Localized replacement remains close to a minimal routing update, and separately measured architectural concerns add gas.

6.1 RQ1 — Runtime Cost

  • Approximately 7.7k gas is CARE’s runtime premium over the evaluated EIP-2535 path across the five workloads.The mean difference is approximately 7,745 gas; the premium’s percentage falls from 29.17% for W0 to 10.27% for W3 and 10.80% for W4 as workload costs rise.Source: Table 7 · p. 23, §6.1 · p. 23, Figure 6 · p. 23

6.2 RQ2 — Architectural Growth

  • At 1, 10, 50, and 100 routing entries, EIP-2535 remained approximately 26.6k gas and CARE approximately 34.4k gas; finer domain partitioning left dispatch unchanged but raised setup cost.With 100 capabilities fixed, partitioning across one to twenty Resolution Authorities raised construction cost from approximately 2.96 million to 10.55 million gas.Source: §6.2 · p. 24, Table 8 · p. 24

6.3 RQ3 — Localized Evolution

  • Across all evaluated replacement sizes, CARE’s localized capability reconfiguration gas remained close to routing-only DiamondCore, with measured differences ranging from 0.61% to 1.72%.For one replacement, CARE and DiamondCore each performed one SLOAD and one SSTORE, versus 24 SLOAD and 15 SSTORE operations plus a DELEGATECALL for the evaluated EIP-2535 path. At 25 replacements, both CARE and DiamondCore performed 25 SLOAD and 25 SSTORE operations, while EIP-2535 performed 312 SLOAD and 207 SSTORE operations; these paths involve different amounts of bookkeeping.Source: §6.3 · p. 25

6.4 RQ4 — Independent Architectural Concerns

  • Shared-state reads and shared-service invocation added 6,365 and 6,321 gas respectively, while observation and its selected failure policy produced distinct additional costs.The combined path used 48,109 gas, successful observation raised it to 60,471, and a handled observation revert consumed 59,937 without changing the successful business result; this behavior reflects the reference policy only.Source: Table 10 · p. 26, §6.4 · p. 26

6.5 Empirical Summary

  • The results show costs redistributed across runtime resolution, architectural setup, and evolution rather than eliminated: dispatch has an approximately 7.7k-gas premium, finer partitioning raises setup cost, and localized replacement stays near a minimal mapping update.Responsibility separation has measurable implementation costs and is not a gas-optimization technique.Source: §6.5 · pp. 26–27

7 Threat Model and Security Characterization

The security characterization treats configuration integrity, state access, observation, delegated execution, and nested execution as security-relevant boundaries. Tests reject several unauthorized mutations, but delegated modules remain trusted and CARE does not inherently prevent reentrancy.

7.1 Trust Assumptions

  • The threat model trusts the configured administrator and reference components, while treating ordinary callers, unauthorized contracts, external dependencies, adversarial calldata, and unregistered modules as potentially untrusted.Registered Execution Modules execute through delegatecall in the Runtime Kernel’s storage context and therefore belong to its trusted computing base.Source: §7.1 · p. 27

7.2 Configuration Integrity

  • Adversarial tests reject unauthorized architectural mutations and validate domain–authority consistency, but the controls do not protect against malicious or compromised administration.The tested restrictions cover Shared Architectural State mutation and observation-emitter configuration.Source: §7.2 · p. 27

7.3 Shared-State Boundary

  • The Solidity reference implementation makes Shared Architectural State administrator-only, so ordinary execution through an Execution Module cannot mutate it through the public administrative interface.This boundary applies only to CARE Shared Architectural State, not arbitrary application business state.Source: §7.3 · p. 28

7.4 Delegated Execution

  • A deliberately registered adversarial module successfully overwrote a Runtime Kernel storage slot through delegatecall, showing that module selection does not establish bytecode safety.Code-hash allowlists, audits, governance restrictions, provenance requirements, and alternative execution boundaries are possible hardening measures, not intrinsic CARE properties.Source: §7.4 · p. 28

7.5 Reentrancy and Nested Execution

  • CARE does not inherently prevent synchronous reentrancy: a delegated module can call the Runtime Kernel and trigger execution of another registered domain-capability pair.Reentrancy-sensitive workflows remain responsible for implementation-level protection; a global non-reentrancy invariant is omitted because it could prohibit valid nested composition.Source: §7.5 · p. 28

7.6 Observation Integrity

  • The reference Observation Hub accepts records only from authorized emitters, and its observed-execution path handles a normal hub revert after successful business execution.That failure behavior is a reference-implementation policy, not a general CARE requirement; gas exhaustion, malicious dependencies, or compliance-sensitive observation may require different semantics.Source: §7.6 · pp. 28–29

7.7 Security Interpretation

  • The evaluated controls reject unauthorized configuration changes and protect several architectural boundaries, but registered delegated modules remain trusted, reentrant execution is not isolated, and administrator compromise is outside the protection model.CARE’s security contribution is explicit trust-boundary definition and adversarial characterization, not a claim of complete smart-contract security.Source: §7.7 · p. 29

8 Discussion and Threats to Validity

The discussion frames CARE’s runtime premium as the cost of explicit domain-scoped resolution ownership and localized evolution, not as a universal gas advantage. Its evidence is bounded by the evaluated implementation, workloads, formal model, and security tests.

8.1 Runtime Overhead and Architectural Justification

  • CARE’s approximately fixed 7.7k-gas premium is consistent with one additional SLOAD and STATICCALL for domain-to-authority resolution, exchanged for explicit resolution ownership and localized reconfiguration.The runtime premium recurs on every execution, whereas reconfiguration cost occurs only when bindings change, so lower update cost does not automatically amortize the runtime overhead.Source: §8.1 · p. 29, §8.2 · p. 30

8.2 Applicability: Runtime Cost versus Localized Evolution

  • CARE is most applicable when functional domains or capabilities are expected to evolve independently; a small, stable contract may not benefit from the added indirection.The paper presents CARE as an option for controlled domain-local evolution, not a default for every smart contract.Source: §8.2 · p. 30

8.3 Domain Granularity

  • Finer domains create more independent resolution boundaries but require more architectural setup, and measured dispatch stability from one to twenty Resolution Authorities does not establish unrestricted scalability.Domain selection is an architectural decision rather than a parameter to maximize.Source: §8.3 · p. 30

8.4 CARE and EIP-2535

  • CARE and EIP-2535 operate at different abstraction levels, and the lower CARE reconfiguration gas reflects different tested management operations rather than universal superiority over Diamond.The feature sets overlap only partially; the comparison separates simple routing-map updates from EIP-2535 facet management.Source: §8.4 · pp. 30–31

8.5 Construct and Internal Validity

  • Gas comparisons measure EVM execution cost, not maintainability, security, reliability, productivity, latency, or throughput, and the compared management operations are not semantically identical.Differences therefore describe the evaluated mechanisms, not perfect instruction-for-instruction comparisons.Source: §8.5 · pp. 31–32

8.6 External Validity

  • The controlled Solidity artifact and workload ladder cannot represent every application domain, and no production-scale migration study supports claims about industrial adoption, migration effort, or long-term maintenance.The evaluation is EVM-specific; no experimental evidence is provided for other execution environments.Source: §8.6 · p. 32

8.7 Formal-Validation Validity; 8.8 Security Validity

  • TLC explores only the selected bounded model, while adversarial tests are not a comprehensive audit and exclude economic attacks, arbitrary dependency behavior, denial of service, and malicious administration.The behavioral specification abstracts from arbitrary bytecode, storage layout, gas exhaustion, and complete reentrancy behavior; machine-checked results complement rather than replace implementation testing.Source: §8.7 · p. 32, §8.8 · p. 32

8.9 Upgrade and State-Evolution Validity; 8.10 Overall Architectural Interpretation

  • Localized replacement measures resolution-map change, not a complete upgrade lifecycle: CARE does not define failed-upgrade recovery, compatibility negotiation, or historical-state transformation.The architecture does not minimize every cost; it makes responsibility boundaries and ownership decisions separately identifiable, including independent domain, state, service, and observation ownership.Source: §8.9 · p. 33

9 Conclusion

CARE makes responsibility ownership explicit in modular smart contracts through six architectural roles and domain-scoped capability resolution. Its evaluation shows operational costs and boundaries, with applicability centered on systems where capabilities or domains evolve independently.

9 Conclusion

  • CARE separates responsibilities across six roles and uses domain-scoped capability resolution, with coordination independent of the authority selecting the execution target.The formal model specifies responsibility ownership, invocation relations, state access, service use, and resolution; five structural properties follow.Source: §9 · p. 34
  • TLA+ and TLC checked seven architectural invariants over a bounded state space, with intermediate results informing model refinement before final validation.The final exploration completed without invariant violation in the evaluated model.Source: §9 · p. 34
  • CARE adds an approximately fixed 7.7k-gas runtime routing premium over the evaluated EIP-2535 path, while localized replacement stays within 0.61–1.72% of routing-only and costs less than EIP-2535 reconfiguration.The intended fit is systems needing independently evolving capabilities or domains; simpler or rarely evolving contracts may not justify the recurring premium.Source: §9 · p. 34
  • Ablations found separately measurable costs for Shared Architectural State, Shared Architectural Services, and Observation Hub integration; security tests also identify trust and protection boundaries.Unauthorized architectural mutation was rejected by tested controls, but registered modules remain trusted under delegatecall; domain-scoped resolution does not provide runtime isolation or inherently prevent reentrancy.Source: §9 · p. 34
  • CARE is an architectural model for separating responsibility ownership, resolution scope, evolution boundaries, and operational costs, not a claim of universally lower gas or improved security.It is presented as a foundation rather than a final replacement for every modularity or upgradeability mechanism.Source: §9 · p. 35
  • CARE leaves complete upgrade governance, versioning, rollback, migration, stronger execution isolation, and non-EVM realizations for future work.A migration study on a production-scale or mature open-source system is also proposed to assess applicability, decomposition effort, and long-term evolution.Source: §9 · p. 35
Loading 2609.17647v1…