A Pattern-Oriented Ontology and Workflow Modeling Approach for the Sui Move Programming Language

Abstract

Smart contracts are vulnerable to critical, design-level Business Logic Flaws (BLFs) that conventional analysis tools often fail to detect. To address this semantic gap, this study introduces a novel ontological framework that formally models the link between high-level architectural intent and low-level Sui Move code. The methodology employs a rigorous Linked Open Terms (LOT) approach to construct a comprehensive ontology, integrated with a library of secure design patterns and process-aware Object-Centric Dynamic Condition Response (OC-DCR) graphs. Qualitative validation was conducted on four canonical security patterns (Access Control, Circuit Breaker, Time Incentivization, Escapability) drawn from the official Sui Framework, confirming the framework’s representational adequacy and logical consistency. Ultimately, this work contributes the first machine-readable semantic layer for Sui Move, decoupling reasoning from raw code availability, and providing the essential semantic foundation for the future development of pattern-aware auditing tools.

1. Introduction

The creation and wide spread of decentralized applications (dApps) and their ability to manage high-value digital assets has driven significant innovation in fields like decentralized finance (DeFi), governance, and supply chain management [1,2,3]. Smart contracts [4] are self-executing programs that automate credible transactions without intermediaries, forming the programmable backbone of the decentralized applications. This is achieved by executing predetermined business logic, while ensuring transactions adhere to specified, behavioral rules, hardcoded inside the contract. However, business logic vulnerabilities arise as well [5,6]. These originate from the discrepancy between a smart contract’s intended design and its on-chain implementation, allowing the attackers to manipulate the contract’s functionality for malicious gain. Once deployed, smart contracts are immutable and potential vulnerabilities and flaws can lead to catastrophic and irreversible financial losses [7,8,9], undermining users’ trust and preventing the mainstream adoption of blockchain technology [10,11].

Recent high-profile security incidents, such as the flash loan attack on the Cetus Protocol within the Sui network [12], underscore the threat landscape, in which attackers exploited not a code bug, but a flaw in the protocol’s economic logic. To combat these threats, a significant body of research has focused on developing automated analysis tools. However, such incidents highlight the challenge that these traditional automated security tools are facing [13,14,15,16], to detect higher-level, architectural-level flaws that arise from incorrect or incomplete implementation of the contract’s intended business process. Preventing such business vulnerabilities requires a proper formal modeling and verification of the intended business process within smart contracts, ensuring all possible interactions remain consistent with expected overall system behavior.

The Sui blockchain [17], with its object-centric data model and its underlying Sui Move language’s emphasis on object safety [18], represents a unique architectural formation that can be leveraged for addressing such types of vulnerabilities. Existing ontologies are Ethereum-centric and fail to capture Sui Move’s object-oriented semantics; this study fills that gap by designing and validating a dedicated formal ontology and Object-Centric Dynamic Condition Response (OC-DCR) framework. In this paper we introduce a comprehensive, multi-layered ontological framework for the security analysis of Sui Move smart contracts. The framework is composed of three integrated layers, with the ontology acting as the formal bridge between these layers, providing the object-centric semantics that elevate individual Dynamic Condition Response (DCR) process models into an Object-Centric Dynamic Condition Response (OC-DCR) framework:

• A formal ontology for the Sui Move language that systematically models its key components, including packages, modules, structs, functions, and access control mechanisms.
• A curated collection of secure design patterns, including Access Control, Circuit Breaker, Time Incentivization, and Escapability, formally defined as classes within the ontology.
• The mapping of each design pattern to a corresponding OC-DCR graph, which captures its expected dynamic behavior and logical dependencies in an executable format.

The foundation of our work rests on the premise that effective smart contract verification requires a semantically grounded approach capable of bridging the gap between high-level architectural intent and low-level code. Recent studies have begun to capture Sui Move’s object-oriented semantics, by developing static analysis tools like MoveScanner [19], or formally comparing its verification capabilities against Solidity [20], but these approaches largely focus on code-level flaws. Even state-of-the-art decompilers struggle to restore accurate function identification and semantic context, creating a “semantic gap” that hinders high-fidelity modeling [21,22]. Similarly, infrastructure improvements, like the Sui Source Verification Service that can be used online (https://suivision.xyz/, accessed on 1 October 2025), provide code equivalence checks, but they do not solve the problem of semantic opacity. As the creators of the above service explain [23], the verification ensures that the deployed bytecode matches the source, but (i) the service can be used on contracts for which their developers must submit their source code to be verified, (ii) until September 2024, over 75% of the top Sui Move projects had not provided their source code [24] and (iii) the verification service does not explain the architectural intent or detect business logic flaws within the contract. Thus, this paper represents a foundational research study, highlighting the need for higher-level abstractions that can formally capture a contract’s intended design logic. While extensive quantitative evaluation of diagnostic capabilities represents an important direction, such an evaluation first requires the validated semantic foundation that this paper aims to provide.

2. Background and Related Work

The foundation and motivation for the ontological modeling of the Sui Move programming language are established in this chapter. We explore the core principles of how blockchain networks operate, the critical role of smart contract security, the challenge of business logic vulnerabilities that can compromise decentralized applications, and the use of ontologies for formal reasoning. Through this analysis, the Sui Move programming language and its corresponding ontological model are placed within this research landscape, and how they can contribute to enhanced smart contract correctness.

2.1. Blockchain Networks

A blockchain network is a decentralized technology combining consensus algorithms and cryptographic methodologies to record transactions in an immutable ledger [25,26,27]. Two well-known data models define blockchain functionality:

• Account-based model (Ethereum-like): Balances are directly stored and updated with each transaction. The concept of accounts is used, with Externally Owned Accounts (EOAs) are controlled by private keys, while contract accounts are controlled by their associated code.
• Object-based model (Sui): All on-chain entities are represented as distinct objects, with explicit properties, ownership rights, and transfer rules. These objects are stored inside the Sui ledger, recognized by their globally unique identifier.

The above architectural differences fundamentally influence smart contract security, scalability, and design patterns, characteristics that are sought after from those who wish to use a network, due the network’s ability to execute and record everything securely and transparently.

2.2. Smart Contracts

Smart contracts were conceptualized by Nick Szabo [4], and form the backbone of a decentralized application as self-executing programs deployed on blockchain networks that automate credible transactions and enforce rules without intermediaries. Various programming languages for creating smart contracts have been developed, such as Solidity [28] (used on Ethereum and Polygon networks) and Move [18,29] (used on Aptos network, while Sui uses its Sui Move variation). These languages provide the environment for running complex business processes, while maintaining transparency and security. But the safety and reliability of smart contracts depends on language design, programming paradigms, and community-driven standards. Modern approaches emphasize formal verification, comprehensive testing frameworks, and systematic validation methodologies to mitigate the risks inherent in immutable code deployment [20,30,31,32,33].

However, a significant proportion of deployed smart contracts contain security flaws of varying severity [8,34,35,36,37,38]. Consequently, placing trust in the correctness of the code (which is created by humans and may contain exploitable flaws), creates doubts among potential adopters who wish to benefit from this technology [10,11,39]. This fundamental characteristic of smart contracts, in which the built-in mechanism for security also increases the risk for vulnerabilities, underlines the non-negotiable need for achieving formal correctness and security before a contract is deployed on the blockchain.

2.3. The Sui Blockchain and Sui Move Language

The Sui blockchain takes advantage of the object-centric model, in which each asset is treated as a discrete object, with explicit ownership and mutability [17]. Each object within the network is treated as an owned object (with a single owner) or as a shared object (multiple users can access it), with the Sui network using this distinction to bypass the consensus mechanism and process multiple, non-conflicting transactions simultaneously, when these transactions involve shared objects. When transactions involve shared objects, the consensus mechanism is activated to ensure consistency across the network [40,41].

Sui Move is an adaptation of the Move language, allowing the direct storage of data inside the objects, passing them between transactions, and safe mutation without affecting an unrelated state [18]. This architectural difference of Sui’s object-based model from Ethereum’s account-based model represents a fundamental paradigm shift: while Solidity treats digital assets as entries locked inside a mapping structure of a smart contract, Sui Move treats them as independent, distinct entities, with explicit ownership and transfer rules [42]. Additionally, through its linear type system, the language enforces these ownership and transfer rules through the usage of the Move Prover [20,43], ensuring that digital assets maintain scarcity properties similar to physical objects. This architectural philosophy of the language allows the object (digital asset) to be transferred, involving moving the entire object from one owner to another, changing both ownership and control in a single atomic operation.

2.4. Design Patterns in Account-Based vs. Object-Centric Models

Design patterns are established solutions for secure, efficient, and maintainable code in software engineering [44]. They promote secure, efficient, and maintainable code by providing predefined, reusable templates for solving recurring problems, something that is in use in smart contract development as well. Research has identified multiple categories of smart contract design patterns that are in use for managing blockchain-specific constraints, such as access control mechanisms, code immutability, and high gas costs for computation and storage [7,45,46,47,48].

The features of the account-based model have led to the creation and adoption of specific design patterns for enhancing the modularity and security requirements of the network (such as the Proxy pattern used for upgradeability, or the Check-Effects-Interactions pattern used to ensure a strict order of operations) [7,49]. But in most cases, a significant burden is placed on the developer to ensure the integrity of asset management, manually implement access control rules, using general-purpose programming constructs [7,20,42,50,51,52]. Since these patterns are dependent on the underlying data model, while they provide flexibility, they are also the root cause of several restrictions and vulnerabilities from the wrong implementation of their logic [8,53,54].

In contrast, platforms that have adopted an object-centric approach, are also using design patterns, but established on a different philosophy and functionality [18,55,56]. These patterns handle distinct digital objects, rather than elements of a contract’s storage layout, a feature that allows developers to manipulate on-chain assets more productively, constructing more expressive, reusable patterns that can lead to enhanced contract logic.

This architectural difference influences the entire smart contract development process [23,42,57], and represents more than just a change in syntax. Critical code implementation responsibilities, such as ownership and access control, are moved from the application layer (where the majority of developers’ errors are created), down to the platform layer, where rules can be enforced by the runtime itself. This not only enhances the security features of the language and consequently the blockchain network on which it operates. This shift also enables developers to focus on building more complex and composable applications, where the digital assets and not the contracts that manage them, are the primary focus.

2.5. The Rise in Business Logic Flaws

Business logic vulnerabilities (or flaws) represent weaknesses in how business rules are designed and implemented within software applications [6], and in the domain of blockchain applications specifically, weaknesses in the rules and processes that control how smart contract execution and blockchain transactions behave. These flaws, in contrast to low-level coding errors, are created from gaps in the application’s intended logic, such as an improper access control mechanism or an insufficiently defined order of state transitions. Recent studies highlight that business logic flaws (BLFs) happen when a smart contract’s implemented behavior fails to match its intended functionality and the business rules it is supposed to enforce [58,59,60]. Flawed assumptions made by the developers about how the users will interact with the system, or a fundamental misunderstanding of the protocol’s requirements, make business logic vulnerabilities difficult to detect. The reason for that is that they require a deep understanding of intended business rules rather than a code-level analysis [5,9,59,61,62]. Thus, a contract could be perfectly secure from a code-pattern perspective, but still contain a critical flaw in its core business logic.

The economic consequences of such vulnerabilities are considerable [63,64,65], including the attack on the Cetus Protocol on the Sui network [12], where attackers exploited business logic flaws that allowed them to manipulate price curves and reserve calculations. Detecting business logic flaws creates a significant challenge for automated security tools, with over 80% of bugs remaining undetected [63], and that is because they are fundamentally a problem of semantics. This represents a gap between the high-level, often informally specified, business requirements (the intent) and the precise, formal behavior of the code implementation (the how) [5,50,60]. And bridging this semantic gap cannot be achieved by using purely code-centric analysis, but through the usage of higher-level formalisms that can capture and reason about the intended business logic itself. This is the domain in which formal ontologies and Dynamic Condition Response (DCR) graphs become valuable tools to use, offering a structured methodology to model, analyze, and verify the behavioral intent behind smart contracts.

2.6. Ontologies for Formalizing Smart Contracts

In computer and information science, an ontology is a formal, structured representation of knowledge [66]. By defining a set of concepts (classes), their properties (attributes), and the relationships between them within a specific domain, offering the semantic foundation for supporting interoperability, reasoning, and automated validation [67,68]. In the context of general programming languages, ontologies have been used for encoding grammar, constructs, and relationships for educational or code analysis purposes [69,70,71]. A portion of research has also been conducted on applying ontologies to the smart contract domain, either focusing on the Ethereum ecosystem [72,73] or developing platform-agnostic models that aim to capture the core elements common to all smart contracts [74], facilitating smart contract development through code generation, data validation, and semantic interoperability capabilities [75].

However, this existing body of work is fundamentally insufficient for formally modeling the Sui Move language, with the ontologies that have been developed for the Ethereum being deeply interconnected with the concepts of the account-based model, such as global state mappings or asset ownership. The architectural formalisms that define Solidity’s language security and performance characteristics, the same characteristics that were built to perform in an account-based blockchain network, are not properly constructed and efficient for representing the characteristics of the Sui Move language.

With Sui network, and its native programming language representing a paradigm shift away from the account-based model [17,18], a formalization gap is created that requires a new, tailored formal specification to capture its unique semantics. Without a dedicated ontology, a significant barrier remains for developers, auditors, and researchers seeking a deep and precise understanding of the language’s semantics and safety guarantees, something essential for validating the behavior of smart contracts throughout their lifecycle.

Table 1. Comparison of Semantic Priorities in Account-Based vs. Object-Centric Ontologies.

Ontological Concept	Account-Based Ontologies (e.g., Solidity)	Object-Centric Ontologies (e.g., Sui Move)
Core Concept	Contract as the central actor	Object as the central data unit
Ownership Modeling	Modeled as a variable state (e.g., balances[user])	Modeled as a structural property (hasOwner)
Interaction Model	Message-passing between contracts	Direct passing of Objects (resources)
Security Focus	Reentrancy, Integer Overflow, State Logic	Object Capabilities, Double Spending, Typos
Semantic Gap	Does not express resource linearity or parallelism	Requires explicit ownership semantics unknown to Solidity

summarizes these differences that each ontology prioritizes:

Therefore, the purpose of this research is to address this gap by developing the first comprehensive, formal ontology specifically for the Sui Move programming language. And since there are no direct analogues in existing smart contract ontologies that can be used for the Sui Move language to be sufficiently represented, we aim to provide a semantic foundation that will accelerate the development lifecycle of this emerging, object-centric ecosystem.

2.7. Declarative Process Modeling

Dynamic Condition Response (DCR) graphs provide a declarative, event-based process modeling formalism, and can be used as an alternative to traditional state machines, explicitly defining the rules for when activities are allowed and required to be executed [56,76]. Through their workflow, they can capture behavioral logic of events, conditions, responses, and dynamic inclusion/exclusion relationships. Simultaneously, their visual nature provides a clear blueprint of how a smart contract’s intended operations should be arranged and executed in a specific order.

The research demonstrates that DCR graphs can be used for formalizing smart contract’s design patterns and business logic semantics into language-independent specifications, thereby reducing the potential uncertainty created by using informal descriptions [56,77,78]. Their declarative nature makes them particularly well-suited for modeling the stateful and event-driven logic of smart contracts and by using these graphs as a base, the Object-Centric DCR (OC-DCR) methodology allows this formalism of modeling processes and state relations to be extended across multiple interacting objects, a natural fit for object-centric, smart contract languages. With their research, Christfort et al. [79] extended the DCR graphs formalism, aiming to capture object-centric behavior from event logs, through three key features: (i) the creation of distinct DCR graphs, each modeling the lifecycle of an object; (ii) supporting the dynamic creation of new processes by using spawn relations; (iii) object-centric semantics connects process models to their respective data objects. Discovery-based methods analyze event logs to discover a process from data (what a system is doing or has done in the past), while our methodology starts with a formal specification of secure design patterns and uses this to define what a system should be doing. While discovery methods are useful for understanding and optimizing existing business processes, a specification-driven approach is essential for engineering verifiably correct and secure systems from the ground up, especially in an immutable blockchain environment.

In the context of Business Logic Flaws, DCR/OC-DCR graphs can be used to target the root cause of these vulnerabilities. This is accomplished by modeling a contract, not as a flat set of functions, but as a stateful workflow with explicit constraints of allowed, required, or forbidden activities. By making dependencies, such as “A must happen before B”, or “C is disabled once D occurs” first-class semantic relations, OC-DCR models expose incorrect or missing transitions that purely code-centric analyses are unable to capture. This makes DCR and OC-DCR a natural formalism for reasoning about the correctness of business processes encoded in smart contracts, rather than only for their low-level implementation details.

Importantly, the DCR, OC-DCR and Ontology methodologies are not competing approaches but complementary layers in a comprehensive formal specification stack, which developers can utilize by creating the required graphs for specifying a business rule, and an ontology to define the terms within that rule. For those reasons, the above methodologies can be used to support high-assurance patterns and compliance checks in blockchain applications, such as the decentralized finance or the supply chain domain, where business logic correctness is paramount [80,81].

3. Constructing the Ontological Framework

The construction of the proposed ontological framework requires a rigorous engineering approach to accurately represent the unique architectural and semantic features of the Sui Move language. This section details the systematic workflow employed to build the ontology, bridging the gap between the raw formal grammar of the language and the high-level design patterns used in secure smart contract development. By following established ontology engineering principles, we ensure that the resulting framework provides a robust semantic foundation, capable of bridging the critical semantic gap between high-level architectural intent and low-level code implementation.

3.1. Methodological Overview

The Sui Move language combines a specific object-centric type system, resource safety, and immutable on-chain semantics mechanisms. For that reason, the construction of our framework followed a specification-driven methodology aligned with the LOT (Linked Open Terms) industrial ontology engineering framework. The LOT methodology [82] provides a flexible approach to ontology development, explicitly recognizing that requirements can be specified through multiple techniques, including (i) competency questions, (ii) natural language statements, and (iii) formal patterns. Regarding the smart contract security-critical domain, where canonical implementations provide ground truth, our approach leverages LOT’s structured natural-language specification methods, by using formal pattern definitions that are validated against authoritative code, rather than use potentially flawed deployed code. Using this methodology, the ontology was developed by applying a grammar-driven approach for its language structures, a documentation-driven approach for the Sui platform architecture, and an evidence-based pattern integration for linking DCR/OC-DCR models to canonical code implementations, as showed in Figure 1.

A methodological consideration that we followed for validating our framework is the accessibility of source code. While recent infrastructure improvements, such as the Sui Explorer’s source verification feature, now provide verified source code for an expanding set of framework packages, two critical gaps remain: (i) a significant portion of the ecosystem still relies on opt-in developer submissions [23,24], and (ii) while bytecode verification confirms code authenticity, it does not explain architectural intent [83,84]. The semantic gap we address is fundamentally different, and it concerns the high-level business rules and expected state transitions that formal specifications can capture, but raw code cannot express. For that reasons, we chose to (i) ground our ontology in the verified Sui Framework in order to establish a clean semantic ground truth, rather than scraping arbitrary, user-deployed contracts that often contain vulnerable design patterns, inconsistencies and mislabeling errors and (ii) validated these ontological patterns to ensure that our theoretical models correspond one-to-one with the immutable, deployed bytecode on the Mainnet. By that, our ontology-driven approach is capable of reasoning about contract behavior via canonical patterns and specifications, regardless of whether the source is fully transparent or partially vague.

To ensure the scientific rigor of the constructed framework, we established three distinct criteria to assess its validity:

• The ontology must be free of internal contradictions and satisfy all defined axioms, verified through automated reasoning tools.
• The framework must be capable of accurately modeling canonical, secure implementations of established design patterns found in authoritative codebases.
• The behavioral OC-DCR graphs must match the expected pattern semantics (including “Happy Path” and “Attack Path” scenarios) when executed in a simulation environment.

All files regarding our developed framework are stored in a Github repo (https://github.com/Giatzis/Sui-Move-Ontological-Framework, accessed on 1 October 2025).

3.2. Structural Foundation via Grammar-Driven Modeling

The first phase focused on creating a foundational layer that formally represents the syntax and core components of the Sui Move language. This was accomplished by following a top-down, grammar-driven ontology engineering method (LOT’s specification-driven requirements phase), with the formal language grammar [85] being used as the primary source:

• Knowledge Source: We began building our ontology base with a systematic analysis of the official Sui Move formal grammar, which provides the ground truth for the language’s structure.
• Process: The syntactic rules and non-terminals from the grammar were systematically translated into a corresponding hierarchy of OWL classes, with their relationships being modeled as part of a taxonomy of object and datatype properties. All the recent updates from the Move 2024 edition were also included, including Enum types and their variants.
• Outcome: The structural layer of the ontology was the result of this phase, and specifically, the architectural modeling of the language’s components and their relationships.

3.3. Architectural Enrichment via Documentation Analysis

In the second phase, we used a documentation-driven architectural modeling methodology for security-critical platforms, aligning with LOT’s natural language statement requirement specification technique. The structural foundation was enriched with concepts that are critical to the Sui architecture but are not explicit in the language grammar alone, involving the analysis of documentation for the language and the network, in order to capture runtime and ownership semantics:

• Knowledge Source: The official Sui and Move developer documentation was used, and an analysis was performed of the Sui Framework’s source code [86,87,88,89].
• Process: We identified and formalized key architectural concepts that go beyond pure syntax (including the modeling of the Sui Object Model) by creating a specialized sui:Object class and formalizing its relationship with ownership types.
• Outcome: This phase produced the architectural layer, adding formal axioms to enforce rules of the Sui platform that cannot be violated or neglected (e.g., any sui:Object must have the key ability).

3.4. Behavioral Modeling via a Two-Phase, Evidence-Based Approach

The final phase of our model’s construction involves incorporating the behavioral dimension, following LOT’s formal pattern specification approach: we applied an evidence-based, pattern-integration methodology by curating abstract patterns, formalizing a library of security design patterns, and grounding them into an authoritative code. To mitigate selection bias, patterns were selected based on established academic taxonomies. For this foundational study, our main goal is to prioritize the high-fidelity modeling of smart contract design patterns, instead of attempting a wide-scale, automated discovery of them. By manually curating the design patterns and grounding them in authoritative sources like the Sui Framework, we ensure the resulting graphical models are conceptually sound, accurately reflecting secure, idiomatic implementations, and not a potentially flawed codebase found in the wild. This provides a validated baseline that is essential before even attempting to scale the approach through automated methods:

• Pattern Curation from the Literature: The process began with a systematic curation of high-level, language-agnostic security and business logic patterns from the academic literature and official language documentation. The objective was to identify and select a set of well-established patterns that represent the abstract security goals of decentralized applications and can be used for conceptual soundness, not statistical coverage. Thus, the ontology includes a library of four critical design patterns, adapting them to address the unique architectural characteristics of Sui’s object-centric data model: two of these (the Access Control and Circuit Breaker), are well-established design patterns, previously documented across the academic literature [7,48,54,90,91]. The other two patterns (the Time Incentivization and Escapability) were selected based on their formal introduction in recent research as design patterns worthy of systematic analysis [54,77] combined with their demonstrated prevalence in real-world smart contracts and empirical security taxonomies.
• Grounding in the Sui Framework: Once a conceptual pattern was identified, the next step was to analyze the official Sui Framework and established developer resources, in order to locate its idiomatic implementation within the Sui Move language (a direct, evidence-based mapping from the literature to implementation). Our decision to rely on manual curation of patterns from authoritative sources (like the Sui Framework) was a deliberate methodological choice. By manually validating these patterns against canonical code, we ensure the resulting models are conceptually sound and accurately reflect secure, idiomatic implementations, thus providing an essential validated baseline before attempting to scale the approach through automated methods. Furthermore, this approach enables analysis even when the source code is opaque or obscured (until September 2024, over 75% of the top Sui Move projects had not provided their source code) [23,24], as the ontology provides the semantic reasoning layer that raw bytecode lacks. After a pattern was identified and its implementation validated, it was then formally modeled as a DCR graph and integrated into the ontology.

3.5. Design Patterns and Framework

The proposed ontology includes a library of four design patterns, formally defined as individuals of the sui:BusinessLogicPattern class in the ontology’s architectural layer, and were selected as representative fundamental elements of a robust smart contract design. Together, they provide a representative sample for validating the framework’s ability to model a diverse range of security and logical issues:

• Access Control: Only authorized entities, typically the owner of a specific capability object, are allowed by this pattern to perform specific function executions, addressing the security concern of authorization, a topic frequently discussed across the literature.
• Circuit Breaker: In response to an emergency or detected threat, this pattern provides a fail-safe mechanism, allowing the temporary suspension of critical contract functions.
• Time Incentivization: A mechanism that uses temporal constraints to reward or penalize actions, commonly found in vesting contracts and other DeFi protocols.
• Escapability: This pattern moves beyond traditional security by modeling the complex, stateful business logic of a smart contract and how it behaves over time, addressing the primary source of modern business logic flaws and vulnerabilities.

Regarding the relationship between the DCR graphs created in this phase and the resulting OC-DCR model, the graphs formalized for each pattern are DCR graphs, modeling a single, self-contained process (similar to a blueprint for a single room). The ontology provides the object-centric layer that integrates these graphs into a unified OC-DCR model (the blueprint for the entire house). This integration is achieved through the usage of the ontological properties, such as the sui:definesLifecycleOf, linking a specific DCR graph (a room’s blueprint) to a specific sui:Struct (an object), thus formally defining that object’s lifecycle and establishing the required object-centric semantics. Through this procedure, these graphs form the required multi-graph structure for the OC-DCR formalism of our framework. The top-down, specification-driven approach was chosen in order to overcome the code opacity of Sui Move smart contracts, differentiated from bottom-up discovery methodologies [79], in which they mine OC-DCR models from on-chain event logs rather than constructing them from curated, evidence-based design patterns.

4. The Sui Move Ontology: A Detailed Model

This section provides an analytical breakdown of our ontology, published in our GitHub v.1.0 repository, explaining our design decisions and reasoning for each component.

4.1. The Structural and Architectural Layer

The core elements of the Sui Move language and the Sui-specific network architecture in which it operates are formalized in this foundational layer. The primary purpose of this layer, as visualized in

Table 2. Layered Architecture of the Sui Move Ontology.

Layer	Purpose	Key Inputs	Key Outputs	Relations
Architectural	Models runtime and storage rules.	Sui Documentation	Object, Address, OwnershipType	stores, hasVisibility
Behavioral	Models dynamic execution & lifecycles.	DCR Formalism	Process, Event	spawns, definesLifecycleOf
Semantic	Captures high-level security intent.	Design Patterns	BusinessLogic Pattern, Implementation Technique	implementsPattern
Verification	Models formal specification blocks.	Move Prover Syntax	Specification, SpecClause	specifies, hasClause

, is to capture the relationships between code artifacts, their runtime representations, and the lifecycle of on-chain transactions.

4.1.1. Code Organization and Deployment Hierarchy

A clear and formal hierarchy for the needs of proper code organization is established within the ontological model, closely aligned with the native development and deployment lifecycle of the Sui ecosystem. This layer consists of three primary classes, the sui:Package, the sui:Module, and the sui:Address, whose relationships are defined using object properties, distinguishing the logical composition from the physical deployment.

The fundamental unit of deployment is defined by the sui:Package, modeled as a container for one or more sui:Module instances, a relationship that is formally captured by the sui:contains object property (with its one-to-many cardinality). By such, the ontology models the pre-deployment state, in which the related modules are grouped into a single package. Once this package is published to the blockchain network, its modules are immutably stored at a specific on-chain location, with this deployed state being represented by the sui:stores property, linking a sui:Address to the sui:Module that is stored inside this address. Beyond being modeled as a container for one or more sui:Module instances, a sui:Module is also used as a container for the core components of a contract: (a) the sui:Functions, which provide its executable logic and (b) the sui:Structs, which define its data structures.

In order for our ontological model to differentiate between (i) a module’s role as a logical component of a software project and (ii) as a physical artifact on the blockchain, the design choice of separating the sui:contains and sui:stores properties was followed. By explicitly separating these two concepts (the logical composition versus the physical deployment), the ontology facilitates a broader spectrum of analytical tasks across the entire smart contract lifecycle, such as the unveiling of the overall structure of a package, through the usage of the sui:contains relationship.

The Structural Layer is rigorously grounded in the official Sui Move grammar to ensure representational accuracy. The framework’s semantic depth is established in the subsequent Architectural and Behavioral layers, which explicitly model the deployment lifecycle, visibility scoping rules, and ownership transfer semantics, relationships that are absent from the raw grammar. For instance, the distinction between sui:contains (logical composition) and sui:stores (physical deployment) captures the semantic gap between a static codebase and its immutable on-chain state, enabling queries about module reuse patterns, dependency analysis, and storage footprint, insights that are strictly non-derivable from the grammar alone.

4.1.2. Modeling Core Language Constructs and Advanced Semantics

Moving beyond the above high-level organization, the ontology provides a granular model of function-level semantics, essential to Sui Move’s security mechanisms:

• The sui:Function class is annotated with properties that capture its behavior and accessibility.
• The isEntry: boolean datatype property differentiates functions directly invoked in a transaction (where access control must be enforced) from internal helper functions, a safety measure as entry functions are the primary point of entry an attacker could try to exploit.
• Function visibility is modeled via the sui:hasVisibility object property, which links a sui:Function to an individual of the sui:Visibility class. The :public, :publicPackage, and :private instances are included inside the sui:Visibility class and correspond to the language’s specific visibility modifiers.

What distinguishes the representation of our ontological model from a simple Abstract Syntax Tree (AST) is its explicit modeling of advanced language semantics. The sui:BorrowingOperator is defined as a distinct class, linked to a sui:Function via the sui:usesBorrowingOperator property. The mutable reference (&mut) is used for explicitly marks references as mutable, enabling safe in-place modification of borrowed values without violating ownership rules. In a traditional AST, this reference would be represented as a syntactic token, but in our ontological framework, we model its use (between a function and an instance of the sui:BorrowingOperator class) as a formal relationship. With this implementation, our ontological model establishes the foundation for using possible formal queries, in order to identify semantic patterns.

4.1.3. The Transaction Lifecycle Model

The ontology provides a complete model of the on-chain execution flow, as detailed in the “Transaction Lifecycle” panel of Figure 2. The direction a transaction follows, from its creation to its on-chain deployment, is modeled with the sui:Transaction, sui:ProgrammableTransactionBlock (PTB), and sui:Event classes:

• A sui:Transaction is the unit of an execution, submitted by a user.
• The sui:ProgrammableTransactionBlock, which is a composable sequence of commands (e.g., function calls, object transfers), is modeled inside the ontology through the sui:hasPTB property, explicitly specifying that a sui:Transaction has exactly one sui:ProgrammableTransactionBlock.
• Finally, the sui:emits property is used for modeling the emission of events (the outcome of a transaction), linking a transaction to the sui:Event instances that form this outcome and is broadcasted to the blockchain network.

The ontology uses a dual-source schema to model that both sui:Function and sui:Transaction can be the source of sui:Event instances. This design choice directly reflects how the Sui runtime operates, and it is a critical element for enabling multi-level conformance checking. This two-tiered view is essential for detecting Business Logic Flaws (BLFs), such as the one exploited in the Cetus Protocol incident, in which the attacker bundled together individual operations within a single PTB and produced a malicious outcome. A simple process model might only check the transaction-level events, which might appear legitimate, but through our ontology, two distinct checks can be performed:

• Micro-verification: Does the sequence of events emitted by the individual sui:Function calls match to the low-level process model, specified for that contract?
• Macro-verification: Does the final set of events emitted by the sui:Transaction match the high-level business process rules?

With the modeled semantic hooks, the ontology provides the necessary granularity to perform two checks and detect exploits, where the logical flaw lies not in any single operation, but within their malicious composition.

4.2. Modeling Modules: Contracts vs. Libraries

Smart contract languages have the ability to separate their stateful contracts from stateless libraries. In contrast, Sui Move organizes all code into module blocks, regardless of its intended role; therefore, creating a separate sui:Library class is an incorrect representation of the language’s actual structure. Instead, our ontology’s semantic nature allows us to check if a module is a library or not: by simply analyzing its structure and connections, this approach provides us a more accurate model of real-world code than a syntactic classification would allow. The approach for evaluating whether a module is a library is by checking the following two conditions:

• Statelessness: Since a module does not define any sui:Object types (an ontological representation of a struct with the key ability), this condition recognizes those modules that do not introduce a new, on-chain, addressable state.
• Reusability: Other modules can target a module through numerous sui:imports relationships, suggesting that these particular modules’ functions are intended for shared, reusable logic.

This approach of checking a module’s architectural role (based on its semantic properties) allows for an analysis that can distinguish a pure, stateless library from a module that is primarily a library but may contain a small amount of configuration state. This distinction is critical for security auditing, enabling an analyst or developer to focus on the truly stateful components of an application while still receiving information about the dependency graph of its shared logic.

4.3. The Behavioral Layer: Formalizing Processes with OC-DCR Graphs

This layer addresses the core challenge of bridging the semantic gap between the static code of a smart contract and its intended dynamic behavior. It achieves this by employing the Object-Centric Dynamic Condition Response (OC-DCR) formalism to create explicit, verifiable process models. This behavioral layer is not an isolated abstraction, but formally interconnected with the structural layer through a set of properties that serve as semantic connectors. The role of these properties is to implement the three core features of the OC-DCR formalism, transforming a collection of individual DCR graphs into a unified OC-DCR model [79]. And through this procedure, the design intent and code implementation are linked in an explicit, machine-readable way, thus performing a form of semantic reification (the process of transforming an abstract concept as a concrete entity within formal ontologies) [92,93].

Within this context, the operational logic that is embedded inside the code of a sui:Function, is made explicit and analyzable by reifying it as a declarative dcr:Event, using a formal process graph. Similarly, the way a sui:Struct is used across different functions creates its lifecycle, with our model reifying this lifecycle as an explicit dcr:Process.

Figure 3 highlights the three object properties that establish the connection between the Process Models and the Code Constructs:

• sui:mapsToFunction: This property creates a direct link between an event in the process model (dcr:Event) and the specific sui:Function in the code that is responsible for implementing its logic.
• sui:definesLifecycleOf: This property connects an entire process model (dcr:Process) to the sui:Struct. This is the core element of our ontological model regarding its object-centric design, with the DCR graphs representing the entire set of valid state transitions an object can have.
• sui:spawns: The dynamic process instantiation is modeled through this property, in which the execution of one dcr:Event leads to the creation of a new instance of a dcr:Process (e.g., a new object with its own lifecycle).

Without these three object properties that provides the object-centric semantics and spawn relations, the created DCR graphs would remain an illustrative diagram, with no verifiable way to guarantee that the code faithfully implements the rules that the graphs enforce. By formally stating an axiom, we create a testable assertion that can be consumed by a static analysis tool designed to parse the body of the selected function and verify that the specified event semantics are correctly implemented.

Modeling Object Lifecycles

An OC-DCR graph can represent the entire lifecycle of an object type, between its creation and destruction, capturing all operations that are permitted to be executed in an ordered sequence. To model this, two distinct yet complementary representations of an object’s state are introduced inside the ontology:

• sui:OwnershipType: This class (the “what”) is created from the Sui Move language’s type system, fundamental for ensuring resource safety. Four primary instances are included (:AddressOwned, :Shared, :Immutable, and :Wrapped).
• sui:ObjectLifecycleState: This class (the “how”) is a process-oriented representation of the state, including instances that model an object’s status within a specific business process, such as :Created, :Owned, :Transferred, and :Deleted.

The following

Table 3. Object Lifecycles Representation.

Aspect	sui:OwnershipType	sui:ObjectLifecycleState
Models	Resource safety and memory management.	Object’s status within a business process
Scope	High-level	Application-specific
Examples	:AddressOwned, :Shared	:Created, :Transferred
Enforced By	Sui Move Compiler and Runtime	OC-DCR Process Model and Application Logic

summarizes this distinction:

This formal distinction is crucial for process-aware analysis: Throughout a series of transactions, an object’s ownership type may remain static as :AddressOwned, but its lifecycle state within the business process can change, progressing from :Created, to :Owned, to :Transferred. A process tool must be able to verify that these state transitions occur in the correct order and under the correct conditions, something that could not have been achieved if only the static sui:OwnershipType was taken into account.

The Cetus Protocol exploit [12] was not a violation of Sui Move’s type safety, but rather a bypass of its implicit process logic. In simpler terms, the code was correct, but the design was flawed. Our model, by linking a dcr:Process to a struct through the sui:definesLifecycleOf property, can formally specify this business logic, enabling the detection of BLFs that the type system has not captured.

4.4. The Semantic Layer: The Dual-Layer Pattern Library

Our framework introduces a two-layered model that distinguishes the abstract security goals from the specific code patterns that are used to achieve them. This separation allows a clear analysis, by separating the conceptual “why” (the architectural intent) from the platform-specific “how” (the implementation technique), thus creating a distinction between them (Figure 4).

Two new classes are modeled to implement this:

• sui:BusinessLogicPattern: This class represents the high-level, language-agnostic concept (the “why”). Instances of this class (e.g., :AccessControlPattern) represents established security design patterns.
• sui:SuiImplementationPattern: This class represents the low-level, idiomatic Sui Move technique used to realize an abstract goal (the “how”). Instances, such as the :CapabilityTechnique, are identified by analyzing authoritative codebases like the Sui Framework [86].

For connecting the above hierarchies to each other and to the implemented code, two properties are used, creating a complete semantic chain:

• First, the sui:isImplementedBy property links high-level patterns to the technique that is used for implementation. For example, to connect a high-level pattern to its low-level technique, the statement :CircuitBreakerPattern, sui:isImplementedBy, :AdminStateControlTechnique is used.
• Second, the sui:implementsPattern property links a specific code module to the implementation technique. The statement validator_module, sui:implementsPattern, :AdminStateControlTechnique for example, creates a direct link between the code and the pattern.

4.5. The Verification Layer

To support the smart contract development lifecycle, our ontology models vital components of the Move Prover [20,43]. Through its usage, developers can prove the correctness of their Move code against a set of formal specifications. For supporting the analysis of this verification process, the ontology provides a structured representation of these components, enabling a form of meta-analysis, focused on a project’s overall verification coverage and quality.

The core element of this layer (Figure 5) is the sui:Specification class, corresponding to a spec block in source code, with each block containing formal logical assertions about the code’s behavior. The sui:specifies object property creates the crucial link between an instance of sui:Specification and the code element it annotates. The range of this layer is the combination of the sui:Module, sui:Function, and sui:Struct classes, showing that specifications can be applied at different levels of granularity.

The ontology also models the internal structure of these specification blocks, with each sui:Specification linked (through the hasClause class) to one or more instances of sui:SpecClause. And this class serves as the parent for a detailed hierarchy of specific clause types, allowing the ontology to capture not just that a function is specified, but how it is specified. Each clause type represents a different kind of formal assertion, including:

• sui:RequiresClause for function preconditions,
• sui:EnsuresClause for postconditions,
• sui:AbortsIfClause for defining failure conditions,
• sui:ModifiesClause for specifying which memory locations a function is allowed to change,
• sui:Invariant for defining state properties that must hold true across all operations.

A key design decision within this layer concerns the modeling of the logical content within each clause. For the sui:SpecClause class, the ontology defines the hasCondition: property, a design decision within this layer concerning the modeling of the logical content for each clause. This means that the logical expression inside a clause (e.g., balance > 0) is stored as a literal string, a required and intentional level of abstraction to the layer’s purpose. And that, because the goal of this layer is not to replicate the complex functionality of the Move Prover itself, a difficult endeavor in itself, and out of the scope of this article.

By modeling the type and target of specification clauses, the ontology creates a foundation for a new form of automated auditing procedure, focused on “verification health” or “specification coverage”. An automated auditing tool, built upon this ontological foundation, that could execute queries against a contract’s design, could help developers build robust and verifiably secure smart contracts. And through this design, our approach shifts the focus from the question: “Is this formal proof correct?”, to a more equally important question, such as: “Is this code elements sufficiently specified to begin with?”.

5. Validating the Framework

Following LOT methodology and foundational research principles, we performed an intermediate validation step between logical consistency (Section 5.1) and behavioral validation (Section 5.2, Section 5.3, Section 5.4 and Section 5.5), prioritizing semantic correctness over empirical scale. We demonstrate the framework’s capability to accurately model canonical implementations of known secure design patterns rather than performing large-scale detection on arbitrary deployed contracts, which would introduce noise from potentially vulnerable or non-standard implementations.

5.1. Foundational Ontology Validation

The logical integrity of the proposed ontology (ensuring it is free of internal contradictions) was formally verified, using the integrated HermiT reasoner (version 1.4.3) of the Protégé Desktop environment (version 5.6.2). The reasoner successfully processed the entire ontology, computing all class, property, and instance inferences, reporting zero errors, thus no inconsistencies. To further confirm its logical integrity, the Protégé debugger was used as well, providing us with an extra confirmation that our ontology is both coherent and consistent. This formal verification ensures that the ontology’s axioms do not lead to logical contradictions and that all defined classes are satisfiable.

5.2. DCR Pattern Model Validation

The workflow we followed for validating each of the four patterns (as described in the Section 3.4), moving from formal specification to a visual model, is the following:

• Selection of a Canonical Implementation: The identification of an implementation for each pattern was made from the Sui ecosystem, a critical methodological choice for ensuring our models are based on a verified codebase that works as the ground truth. The used codebases are the exact versions used at the time of evaluation and stored within our Github project repo:
  • The Official Sui Framework: We used the transfer_policy.move (Access Control), coin.move (Circuit Breaker), and package.move (Escapability patterns) modules, representing core codebases that define the network’s foundational logic.
  • The Official Sui Developer Documentation: For the Time Incentivization pattern, we used the linear.move example, representing community-accepted best practices.
• Mapping to the Ontology: We manually mapped the selected Sui Move code to the corresponding classes and properties in our ontological model, by creating instances that represent the specific code elements and defining the relationships between them (e.g., the transfer policy module implements the Access Control Technique).
• Process Analysis: We analyzed the control flow and logic of the implementation to verify that the real-world code’s behavior aligns with the behavioral rules defined in the corresponding OC-DCR model.
• Executable Model Validation: The ontology utilizes four primary DCR relations, with each DCR relation being mapped to a unique and consistent visual symbol (e.g., color and style of an arrow) provided from the online tool (https://www.dcrgraphs.net/, accessed on 1 September 2025) that was found in the literature [56,76,77,94], and their semantics are defined in

  Table 4. Mapping of DCR Relations to Visual Notations and Semantics.

  Expression	Events Relations	Arrows Colors
  B dcr:condition A	A must happen before B	Orange
  A dcr:response B	If A happens, B becomes a required future action	Blue
  A dcr:exclusion B	If A happens, B is permanently disabled	Red
  A dcr:inclusion B	If A happens, it enables B and is available to happen	Green

  .
• Graphs Testing: The final step of the validation involves using an online simulation-assisted tool in order to test the created visual DCR graphs. By executing both the valid (“happy path”) and invalid (“attack path”) scenarios, we verify that the behavior of the executable visual model corresponds to the rules defined by the ontology.

5.3. Internal Validation

The internal validity of each DCR graph was confirmed through rigorous logical simulation, using the online tool, with the main objective to verify that the operational semantics of the created visual models are in alignment with the logical constraints that are defined in our ontology. The methodology involved executing events in the simulation engine to observe the state of the process model. This procedure was applied for validating all four patterns, and in each step, we verified that the set of enabled, disabled, and pending activities strictly followed our placed ontological rules, confirming a direct correspondence between the formal specifications and the executable graphs (

Table 5. Internal Validation Results for Security Patterns.

Scenario Type	Test Case	Expected Behavior	Simulated Behavior
1. Access Control Pattern
Happy Path	Execute AC_GrantRole → AC_ProtectedCall	AC_ProtectedCall becomes enabled	AC_ProtectedCall enabled
Attack Path	Execute AC_GrantRole → AC_RevokeRole	AC_ProtectedCall becomes disabled	AC_ProtectedCall permanently disabled
2. Circuit Breaker Pattern
Happy Path	Execute CB_Pause	CB_OperationalCall disabled; CB_Unpause enabled	CB_OperationalCall disabled; CB_Unpause enabled
Attack Path	Execute CB_OperationalCall during paused state	Operation blocked	Operation blocked
3. Time Incentivization Pattern
Happy Path	Execute TI_Start → TI_Proceed	TI_Proceed enabled and flagged as pending	TI_Proceed enabled as pending response
Attack Path	Execute TI_Proceed before TI_Start	Operation blocked	Operation blocked
4. Escapability Pattern
Happy Path	Execute ES_Authorize → ES_Escape	ES_Escape becomes enabled	ES_Escape enabled
Attack Path	Execute ES_Escape without ES_Authorize	Operation blocked	Operation blocked

):

5.4. Qualitative External Validation

The validation results for each of the four patterns (their mappings were formally encoded as instances and property assertions within the ontology) are presented in this section, demonstrating the ability of the framework to model them, using authoritative codebases from the Sui ecosystem. Consequently, this validation does not include quantitative metrics such as simulation error rates, execution overhead, or large-scale coverage statistics, which represent a distinct phase of evaluation reserved for future work once this semantic baseline is established:

• Access Control Pattern
  • Canonical Implementation: The pattern has been found to be implemented into the transfer_policy.move Sui Framework’s codebase, allowing the creation of rules that restrict how certain assets can be transferred.
  • Ontological Mapping: The TransferPolicy struct is mapped to the StateObject class, and the TransferPolicyCap struct (the one that grants administrative rights) is mapped to CapabilityObject. The pattern’s functions are then mapped to specific access control events:

    –

    The new() function maps to the AC_GrantRole event.

    –

    The protected withdraw() function maps to the AC_ProtectedCall event.

    –

    The destroy_and_withdraw() function maps to the AC_RevokeRole event.

  • Process Analysis: The implementation’s logic aligns with our DCR graph:

    –

    The AC_ProtectedCall (withdraw) requires the TransferPolicyCap to be created by AC_GrantRole (new), satisfying the dcr:condition.

    –

    The feature to destroy the capability via calling the destroy_and_withdraw() function (AC_RevokeRole), satisfies the dcr:exclusion rule and ensures that access, once granted, is also verifiably revocable.

• Circuit Breaker Pattern
  • Canonical Implementation: The pattern has been found to be implemented into the coin.move Sui Framework’s codebase, implementing the DenyCapV2 mechanism for providing built-in circuit breaker capabilities.
  • Ontological Mapping: This pattern’s capabilities inside the above codebase are defined by several key structs and functions:

    –

    The TreasuryCap<T> struct (for minting/burning) is mapped to CapabilityObject.

    –

    The DenyCapV2<T> struct (for pause operations) is mapped to the CircuitBreakerTechnique class.

    –

    The deny_list_v2_enable_global_pause() function maps to the CB_Pause event, while the deny_list_v2_disable_global_pause() maps to CB_Unpause.

    –

    Protected operations like mint() and burn() map to the CB_OperationalCall event.

  • Process Analysis: The implementation is a dual-layer control mechanism, aligning with our DCR graph. Initially, the CB_OperationalCall event is permitted, but with the execution of deny_list_v2_enable_global_pause() function (CB_Pause in our ontological mapping), the system transit to a paused state, thus satisfying two key conditions:

    –

    Implementing the dcr:exclusion rule disables the CB_OperationalCall.

    –

    The CB_Pause event enables the CB_Unpause event (similar to our dcr:inclusion), allowing the system to be restored.

• Time Incentivization Pattern
  • Canonical Implementation: The pattern has been found to be implemented into the linear.move codebase from the Sui Vesting Framework, which defines a linear token vesting schedule to incentivize long-term holding.
  • Ontological Mapping: The key components of the Time Incentivization pattern are mapped to our ontology as detailed below:

    –

    The state of the pattern that includes the vesting schedule is held in the Wallet struct, and mapped to the StateObject class.

    –

    The claimable() function, which calculates available tokens, is mapped to the TI_Start event.

    –

    The claim() function, which allows withdrawal, is mapped to the TI_Proceed event.

    –

    The vesting completion state is mapped to the TI_Timeout event.

  • Process Analysis:

    –

    The TI_Proceed (claim) event enforces the dcr:condition by yielding tokens proportional to the time elapsed since TI_Start.

    –

    The linear formula (self.balance.value() * elapsed)/self.duration) calculates a yield proportional to the holding period, thus rewarding long-term holding.

• Escapability Pattern
  • Canonical Implementation: The pattern has been found to be implemented into the package.move Sui Framework’s codebase.
  • Ontological Mapping: The UpgradeCap struct, which grants upgrade authority, is the CapabilityObject. The authorize_upgrade() function maps to the ES_Authorize event, and the commit_upgrade() function maps to the ES_Escape event.
  • Process Analysis: The control flow follows our DCR graph’s rules. The ES_Escape action (commit_upgrade) requires the prior completion of the ES_Authorize function call (authorize_upgrade). Thereby, the dcr:condition relationship is satisfied, ensuring that contract upgrades are deliberate and authorized.

5.5. Empirical Grounding via Verified Source Analysis

To mitigate selection bias and ensure that the canonical implementations used in our qualitative analysis correspond to the actual deployed bytecode on the Sui Mainnet, we also performed a empirical verification using the Sui Move Source Verification Service [23]. A critical distinction exists between the Sui Framework packages and arbitrary deployed contracts: the framework packages (0x1, 0x2, 0x3, and 0xdee9) are sourced from the official Mysten Labs repository (https://github.com/MystenLabs/sui, accessed on 1 December 2025), which maintains a well-known, publicly tracked source repository that the above service automatically monitors. These packages undergo continuous bytecode verification—their source code is recompiled and automatically verified against on-chain bytecode whenever the framework is updated. This differs fundamentally with other smart contracts, where verification is opt-in and requires developers to manually submit source code, something that a small percentage does [24].

As presented in

Table 6. Validation of Ontology Patterns against Verified Source Code.

Pattern Element	Ontology Entity (Class/Individual)	Ontology Relation (Property)	Verified Source Evidence
1. Access Control
Capability Token	sui:Struct (e.g., :TransferPolicyCap_struct)	sui:implementsPattern (:CapabilityTechnique)	0x2::transfer_policy:: TransferPolicyCap
Protected Call	sui:Function (e.g., :withdraw_func)	sui:mapsToFunction (:AC_ProtectedCall)	0x2::transfer_policy::withdraw
Grant Role	sui:Function (e.g., :new_func)	sui:mapsToFunction (:AC_GrantRole)	0x2::transfer_policy::new
2. Circuit Breaker
Emergency State	sui:Function (e.g., :enable_pause_func)	sui:mapsToFunction (:CB_Pause)	0x2::coin::deny_list_v2 _enable_global_pause
Operational Call	sui:Function (e.g., :mint_func)	sui:mapsToFunction (:CB_OperationalCall)	0x2::coin::mint
Admin Control	sui:Struct (e.g., :DenyCapV2_struct)	sui:implementsPattern (:AdminStateControlTechnique)	0x2::coin::DenyCapV2
3. Time Incentivization
Time Source	sui:Function (e.g., :claimable_func)	sui:mapsToFunction (:TI_Start)	0x3::staking_pool (Time-based reward logic)
Vesting Logic	sui:Struct (e.g., :Wallet_struct)	sui:implementsPattern (:LinearVestingTechnique)	0x3::staking_pool
4. Escapability
Authorization	sui:Function (e.g., :authorize_upgrade_func)	sui:mapsToFunction (:ES_Authorize)	0x2::package::authorize_upgrade
Escape Mechanism	sui:Function (e.g., :commit_upgrade_func)	sui:mapsToFunction (:ES_Escape)	0x2::package::commit_upgrade

, we identified the official on-chain packages for each design pattern, and utilized the service’s bytecode-matching feature to confirm that our source code samples were identical to the immutable smart contracts running on the main network. This verification procedure establishes a validated empirical baseline for our dataset, ensuring that the ontology is modeled upon real-world, verified, production-grade codebases, rather than unverified examples, containing potentially vulnerable design patterns.

6. Limitations and Future Work

The primary contribution of this paper is the design and validation of a foundational ontological framework for the Sui Move language. Given this foundational scope, our evaluation methodology deliberately prioritizes semantic correctness over empirical scale: we demonstrate the framework’s capability to accurately model canonical implementations of known security design patterns, rather than performing large-scale detection on arbitrary deployed contracts. The absence of quantitative simulation metrics (such as coverage percentages, simulation error rates, or comparative benchmarks against existing tools) reflects a deliberate research focus rather than a methodological oversight. This intentional limitation creates a significant direction for future work: evaluating the framework’s ability to detect faulty implementations. With that in mind, our main goal was to provide the semantic foundation for the development and empirical evaluation of a pattern-aware static analysis tool for such a task, a tool that represents a substantial research effort designated as the next phase of this research.

The design patterns that are included in the ontological framework, while justified as representative solutions that were found in the academic literature to address security vulnerabilities, are not exhaustive. Validating a sample of four patterns, while sufficient to demonstrate representational adequacy for this foundational study, still represents a small sample size, and future work should expand this library to cover a wider array of patterns. Similarly, the target language and platform that our model is based on are often upgraded, resulting in the need for possible upgrades into the core ontology, in order to reflect the new features or syntax changes, thus representing a standard maintenance consideration.

Regarding the application of the framework to arbitrary, user-deployed contracts, this study adopts a deliberate scoping strategy driven by three methodological factors: (i) until recently, a significant majority of Sui Move projects lacked verified source code [24], making reliable large-scale analysis infeasible without first establishing a verified semantic baseline; (ii) by grounding the validation in the canonical Sui Framework, we ensure the ontology captures correct semantic behavior, avoiding the noise and bias introduced by potentially vulnerable or non-standard implementations; (iii) adhering to ontology engineering principles [95], we prioritized establishing semantic correctness over empirical scalability. This verified semantic foundation is the prerequisite for our future research phase, which will utilize these validated models to detect anomalies in arbitrary deployed contracts, through a smart contract’s corpus, which we will create.

The modeling process we followed relies on manual curation of patterns from official sources. While manual curation can introduce selection bias, we mitigated this risk by rigorously cross-referencing our ontological models against the cryptographically verified source code of the Sui Framework (via the Sui’s explorer tool). This ensures that although our pattern selection was manual, the semantic representation of those patterns is empirically grounded in authoritative, verifiable code. However, we acknowledge that this approach does not yet scale to the automated discovery of patterns from arbitrary, unverified contracts, a limitation that future work will address by leveraging this ontology as a training set for an automated pattern detection tool.

Based on these findings, several opportunities are open for future research, in order to enhance the understanding and practice of secure and efficient smart contract development:

• This research does not address empirical detection metrics (e.g., coverage percentages, simulation error rates, or comparative benchmarks against existing tools). This is a deliberate scope choice for our foundational study that necessarily prioritizes semantic adequacy and ground-truth validation via verified source code and empirical grounding [95]. We ensured that our canonical implementations correspond to actual deployed bytecode via the Sui’s explorer functionality, over statistical testing. Future work will involve a large-scale study, in which a corpus of verified Mainnet contracts will be created for applying this framework to benchmark its performance.
• A promising future research direction is the formalization of “pattern compositions” as first-class concepts, allowing tools to reason about how patterns interfere with, or reinforce one another, within a single module-contract.
• The ontological framework could provide developers with real-time, semantically aware feedback through its integration into Integrated Development Environments (IDEs). For instance, an IDE could recognize when a developer is implementing a vesting schedule and guide them to ensure that its logic correctly matches the Time Incentivization pattern.
• The ontology’s Verification layer could be used and leveraged for building tools that (i) could perform an analysis of a project’s verification structure (e.g., automatic identification of functions that lack certain blocks) thus pinpoint unverified components or (ii) by upgrading it in order to create an automated procedure of auditing the formal specifications themselves, and not just checking the presence of a spec clause (moving from describing code and its specifications to analyzing and validating the relationship between them).
• A useful future direction involves empirical user studies to evaluate the practical utility of such ontology-driven tools, and validate that they can effectively improve developer understanding of patterns and enhance error detection.

7. Conclusions

A multi-layered ontological framework was created and validated in this paper for the Sui Move programming language. It is designed to bridge the semantic gap between high-level architectural intent and low-level code in Sui Move smart contracts, addressing the challenge of detecting Business Logic Flaws (BLFs) inside smart contracts, which are not often detected by code-centric analysis tools.

By creating and leveraging a formal ontology as an “object-centric layer,” we showed that it is possible to systematically integrate a collection of individual, pattern-specific DCR graphs into a single, connected OC-DCR model. A set of explicit ontological properties that formally link abstract behavioral models to concrete code artifacts were used in order to satisfy the defining features of the OC-DCR formalism. The framework’s representational adequacy was confirmed through a qualitative validation against canonical implementations of four security design patterns, used from authoritative Sui Framework and documentation sources. This process verified our model’s capacity to accurately capture a range of security, economic, and temporal logic, when shifting the focus from implementation details to architectural intent is needed.

This work provides more than just a theoretical model; it delivers a machine-readable, semantically grounded foundation as the first step toward a new generation of “pattern-aware” security tools that do not just look for bugs in the code, but verify the integrity of the design itself, resulting in potential real-world safety impact. For instance, these formal specifications can be directly integrated into the Move Prover to enable automated verification of architectural patterns, or embedded within IDEs to provide developers with real-time, semantic feedback on their business logic compliance before deployment.