Marko Marković*
Stevan Gostojić- Faculty of Technical Sciences, University of Novi Sad, Novi Sad, Serbia
The introduction of information and communication technologies in the legal domain has enabled the automation of some activities in the legal profession. With the advent of blockchain and smart contracts, new tools have emerged for lawyers and their clients, enhancing transparency and increasing trust compared to traditional legal instruments. Once deployed, smart contracts should be able to respond to various events that can occur during the contract’s lifecycle. However, this kind of automation in smart contracts requires them to embed necessary legal knowledge and implement support for legal reasoning. In this paper, we propose a legal reasoning method for smart contracts that incorporates defeasible logic, a key requirement for automated reasoning in the legal domain. The entire reasoning process in our approach is performed on the blockchain infrastructure, making the drawing of conclusions fully transparent and accessible to all interested parties. To demonstrate our concept, we illustrate how certain rights prescribed under labour law can be embedded within a smart contract and deployed on the blockchain as a legal reasoning service. Then, we show how an employment contract can use the reasoning contract to automatically apply legal norms to infer conclusions and determine legal consequences in particular cases. We analyse the benefits and potential issues of this method and discuss directions for future work. Optimisation of the reasoning engine is one of the challenges we identified that needs to be tackled in future.
1 Introduction
Modern information technologies offer various tools for automating tasks in numerous areas. Lawyers are often perceived as being dependent on traditional methods and less inclined to adopt these tools than some other professions (Rodgers et al., 2023). Although lawyers cautiously accept the latest innovations, these solutions benefit both the lawyers and their clients. These tools are designed to support lawyers in their daily practice by helping them deliver optimal solutions to clients and stay competitive by keeping pace with evolving industry trends.
Enabling computer software to take over some aspects of the data processing from lawyers requires legal knowledge to be embedded within the software. That way, the software can enhance lawyers’ performance and take on part of the legal workload. The legal knowledge may include legal norms, case law, the workflows of specific legal procedures, and tacit knowledge acquired through experience. It can be represented in a machine-readable and machine-understandable format, using a domain-specific language or even a pretrained machine learning model. However, the use of knowledge representation in software capable of producing reliable and explainable results plays a crucial role in fostering lawyers’ trust in automated legal reasoning tools (Gómez, 2022).
One of the technologies that has grown in popularity in recent years is blockchain. Besides its secure financial transactions and preservation of participants’ anonymity, blockchain technologies provide a concept of smart contracts as a method for creating self-executable code and building decentralised applications. Although its name suggests, smart contracts are not aimed at contracting in legal terms, but at the development of a computer program that is automatically executed when certain conditions are met. Furthermore, the decentralised nature of these programs reduces the risk of misuse by individuals while increasing trust.
Smart contracts in terms of legal principles are proposed by Szabo (1997), referring to formalised and secured relationships on computer networks. It also emphasises the principle of privity, ensuring that the smart contract is binding only for contracting parties, and it regulates their rights and responsibilities. It also suggests an application of cryptographic methods to ensure the security of smart contracts on public networks. This perspective on smart contracts differs to a certain extent from smart contracts on the blockchain, and indicates a gap between a method of concluding legal relationships and self-executing software in general.
With the growing popularity of blockchain technologies, the term smart contracts has come to refer to computer programs deployed on blockchain networks, while legal smart contracts is typically used to emphasise their legally binding nature. Codifying contract provisions within the smart contract implementations helps bridge the gap between smart contracts and their legal counterparts, positioning blockchain as a powerful tool for the automatic execution of contractual obligations. Nonetheless, it should be noted that the enforceability of smart contracts still depends on their recognition within the legal framework and the legal validity of blockchain-based transactions. Kasatkina (2021) argues that regulations governing smart contracts vary between jurisdictions and suggests the introduction of a unified legal framework to facilitate the global regulation of smart contracts. Cheong (2024) emphasises the importance of transparency and accountability in fostering public trust and understanding of how modern technologies affect individuals’ lives. He further highlights the significance of explainability and auditing in such systems, the advancement of regulatory frameworks, and greater engagement by stakeholders and the public. Cheong (2025) observes that the variability of regulations across jurisdictions presents challenges for the commercial application of modern technological solutions and suggests that, in the absence of adequate regulation, both users and developers may be required to bear responsibility for any harm caused by advanced technologies.
The relationship between smart contracts and legal contracts has been discussed by Governatori et al. (2018), with particular emphasis on the challenges involved in implementing legal agreements through smart contracts and ensuring their legal enforceability. Also, the applicability of imperative and declarative programming paradigms in smart contracts development is discussed in detail from a legal perspective. The authors identify execution of the smart contract as a stage in its lifecycle that raises issues related to complexity and interoperability. Thus, logic-based smart contracts, along with their inference algorithms, significantly increase computational complexity, which may impair the execution efficiency. The interoperability, however, places smart contracts in a broader context where they exchange information with one another and operate within environments that include normative constraints and legal rules. The LegalRuleML standard is proposed as a format for representing legal rules and to support the interoperability of smart contracts with other information systems. Nevertheless, disputes are identified as a potential risk, often arising from parties’ misunderstanding of the smart contract’s implementation, making dispute resolution a necessary component. Finally, the comparison of programming paradigms indicates that smart contracts benefit more from the declarative paradigm than from the imperative one.
Automatic execution of smart contracts’ provisions requires determining legal consequences for a given case and undertaking actions regulated by the contract. These actions are prescribed by contract provisions themselves and by legal norms they explicitly refer to. Furthermore, the legal validity of the contract depends on its compliance with the laws in force, causing the legal effects of the smart contract to be subject to the legal norms. Thus, to include legal reasoning in smart contracts, a method for the representation of legal norms should be designed along with a method for legal reasoning supporting that legal norm representation. Considering the defeasible properties of legal reasoning, the inference algorithm implemented by the smart contract should be able to support defeasible rules, whether these rules represent contract provisions or legal norms.
Defeasible logic as explained by Nute (2001) serves as a foundation for legal reasoning due to its non-monotonic nature, which enables inference based on available evidence. If new evidence appears it may alter previously drawn conclusions. Defeasible logic therefore distinguishes between strict rules, defeasible rules, and undercutting defeaters. In contrast to strict rules, where the conclusion necessarily follows from the premises, defeasible rules may have exceptions and may lead to mutually contradictory conclusions. Such contradictions are resolved through superiority relations whereby one rule is defeated by another of higher priority. Undercutting defeaters are rules that undermine the applicability of another defeasible rule without directly contradicting its conclusion.
Introduction of smart contracts capable of legal reasoning brings a significant effort in the legal domain, demanding transformation of legal norms in a machine-readable format and implementation of a reasoning engine. However, it implies that a single instance of a smart contract should embed relevant legal knowledge to enhance its ability to support a wider range of scenarios itself. This may lead to repetitive interpretation and transformation of the same legal norms for every smart contract implementation that depends on them.
Although defeasible reasoning in smart contracts is particularly beneficial for the legal domain, enabling more complex contractual provisions to be expressed and automatically executed, it is not the only area that can benefit from the application of this reasoning method. Financial applications on the blockchain within DeFi ecosystem (Schär, 2021) are also suitable candidates for this form of reasoning. For example, the automatic processing of legally regulated financial transactions may require such reasoning capabilities. Similarly, insurance policies defined as set of rules that potentially involve exceptions and conflicts can be handled using this inference method.
In this paper, we propose a method for legal reasoning on blockchain based on the smart contract, referred to as the reasoning contract, that acts as a legal reasoning service for other smart contracts. Once developed, the reasoning contract would eliminate the need for legal norms codification in individual smart contracts, and instead, the reasoning results could be obtained within a single transaction. To demonstrate the concept, we choose to deploy a reasoning contract equipped with legal norms from the labour law and to develop a smart contract that contains some provisions of an employment contract to determine if the termination of employment complies with the law in force.
Although legal systems are generally categorised into two main types, civil law and common law, both derive their authority from legal norms and case law, but with different emphases. Civil law systems are primarily governed by codified legal norms, while common law systems rely more heavily on judicial decisions and precedents. Since our research centers on legal reasoning based on legal norms, we concentrate on civil law legal systems.
While the method proposed in this paper aims to enhance the logical reasoning capabilities of smart contracts it also introduces certain improvements to the application of blockchain technologies within the legal domain. Its main contributions are: (1) support for defeasible reasoning within smart contracts, (2) the construction of smart contracts for legal reasoning based on formally represented legal rules, and (3) the provision of legal reasoning services to other smart contracts on the blockchain. Accordingly, we first present the implementation of the defeasible reasoner, followed by an introduction to the approach for its generation in compliance with applicable laws and regulations, and finally outline how it can be utilised by smart contracts to provide legal reasoning services.
We also identified several challenges associated with deploying the proposed approach on public blockchain networks. The computational complexity of the current implementation may incur substantial financial costs for reasoning transactions executed within the blockchain environment. In some cases, such transactions may even be canceled if their execution requires computational power that exceed the limits imposed by the network. Accordingly, we emphasise that the presented method serves primarily as a proof of concept, and we provide guidelines for addressing these issues. Moreover, the significance of the proposed method depends on the jurisdiction in which reasoning over specific legal norms is applicable, and its relevance may be limited to a particular group of stakeholders. Considering these circumstances, the execution of the legal reasoner may be more appropriately performed on a private blockchain network operating within a given jurisdiction until identified obstacles are resolved.
The rest of the paper is structured as follows. The next section discusses similar research that contributes to legal reasoning and inspired our research. The third section details the proposed methodology for defeasible reasoning on blockchain. The fourth section presents the prototype of the reasoning contract and demonstrates its use by an employment contract. The fifth section reports and discusses the results obtained. Finally, the sixth section gives concluding remarks and suggestions for future work.
2 Related work
In this section, we review previous research on legal reasoning and smart contracts. First, we examine key concepts of defeasible reasoning and their implementations. Then, we discuss several approaches aimed to enabling logical reasoning within smart contracts.
Antoniou and Bikakis (2005) consider two approaches for translating defeasible theories into logic programs. The first, described by Antoniou et al. (2000) and Maher et al. (2001), employs meta-programs to enable defeasible reasoning. The second approach, proposed by Antoniou and Maher (2002), uses control literals. However, Antoniou and Bikakis observe that the use of control literals can significantly increase the number of clauses, potentially leading to inefficiency. As a result, they choose to represent defeasible theory using the meta-program.
Bassiliades et al. (2004) presented the DR-DEVICE reasoner that supports defeasible logic and knowledge represented using semantic web standards. It uses a rulebase defined in the RuleML format and transforms it using an XSLT stylesheet to a CLIPS set of rules. Case facts can be loaded from the RDF file and forwarded to the reasoning engine. The reasoning is performed by CLIPS interpreter, and the results are exported to a custom format XML file. The source code of the reasoner is open, facilitating its integration into other software projects.
Chainlog is a language and logic interpreter for smart contracts presented in O’Sullivan (2022) to enable logic reasoning in smart contracts. A language that combines declarative and procedural paradigms is developed to facilitate the representation of logic clauses in a human-readable format. Authors also presented Chainlog Platform, a specially designed blockchain for executing smart contracts implemented using Chainlog language. The platform still lacks support for interaction between smart contracts, i.e., external calls initiated by one smart contract to another.
Idelberger et al. (2016) analyse various ways to enable defeasible reasoning on the blockchain and distinguish two types of approach, on-chain and off-chain. On-chain reasoning occurs on the blockchain and is performed by miners, while the off-chain approach requires communication with reasoning services that are not part of the blockchain. The main advantage of the on-chain approach is its high level of trust, but it may require a higher cost due to the computational complexities. Besides the fact that off-chain reasoning would require interaction with external services and therefore violate the security of the blockchain, the expenses of this approach would be negligible compared to the on-chain reasoning.
A logic-based smart contract for blockchain is proposed in Hu and Zhong (2018) to enable logic reasoning in smart contracts using an on-chain rule engine. The authors presented a reasoning model aimed at providing support for drawing conclusions based on rules, considering their temporal characteristics. The development of the model is motivated by the idea of incorporating logical formalisation of legal reasoning into smart contracts. However, a further development of a language for expressing contractual agreement is to come, and ways for the practical application of the model need to be explored.
Formal language for contract specification called Symboleo is presented in Sharifi (2020). The language is designed to represent provisions of contractual agreements that can be transformed into the smart contract code. The language is based on a contract ontology enabling formal representation of contract elements and their relations. The contract editor is also developed to facilitate contract specification using the Symboleo language. However, the language lacks a tool for automatic transformation of the contract specification to smart contract code.
In Van Woensel and Seneviratne (2025) the authors propose a method for data exchange in healthcare using smart contracts to enhance security and the protection of patients’ data. The approach employs knowledge graphs to represent the logic of smart contracts, which are then compiled it into smart contract code. To reduce execution costs, the method adopts a hybrid solution that combines an off-chain approach for generating the smart contract from the knowledge graph, with on-chain deployment for execution. The method is demonstrated through the transformation of a knowledge graph representing insurance policies into a smart contract for processing health insurance claims. This approach enables domain professionals who lacks technical skills to contribute to knowledge representation at a higher level of abstraction, rather than to the development of smart contracts.
Alt (2020) developed a Prolog (Colmerauer et al., 1973) interpreter fully implemented in Solidity (Reitwiessner et al., 2025) language. The reasoning is based on predicate logic and supports key Prolog concepts, including unification and substitution, to obtain conclusions. The interpreter’s API supports rule definitions using atoms, numbers, variables, anonymous variables, and lists, but lacks some Prolog language operators. The source code of the reasoner is equipped with test cases and an application example, making it easier for developers to comprehend the organisation of the project.
To the best of our knowledge, there are no published solutions for legal reasoning by smart contracts. Furthermore, the implementation of a reasoning engine capable of supporting defeasible logic on the blockchain remains necessary.
3 Methodology
This section outlines the methodology for legal reasoning in smart contracts based on a logic reasoner that supports defeasible logic. We adopt the on-chain approach, due to aforementioned reasons, aiming to achieve higher trust and security in the reasoning process. Moreover, the automation of legal reasoning requires trust both in the formal representation of legal norms and in the inference process itself. Our intention is to incorporate both components into the blockchain, thereby making them fully transparent to the contracting parties. In this way, the system outcomes become publicly verifiable and independent of external actors (Ebrahimi et al., 2025).
The reasoning is performed by a smart contract, called the reasoning contract, which consists of the reasoning engine and the rulebase. The reasoning engine is based on first-order logic and is complemented by a meta-program to support defeasible reasoning. The rulebase contains legal norms formalised as defeasible rules.
Figure 1 illustrates the architecture of the method for legal reasoning on the blockchain. The illustration shows smart contracts, depicted by rectangles, as a part of the blockchain. Arrows depict the invoking of a reasoning transaction and the return of its result.
Figure 1. Architecture of the legal reasoning on the blockchain.
The reasoning contract deployed on the blockchain network provides its application binary interface (ABI) to other smart contracts, enabling them to initiate reasoning transactions. In these transactions, the input facts are passed to the reasoning contract to obtain a reasoning result for a given query. The reasoning result indicating the provability of the query is then returned to the smart contract that initiated the transaction.
Our method also includes a mechanism for constructing the reasoning contract from its components. The reasoning contract needs to provide legal reasoning in accordance with established legal norms. Therefore, it should incorporate a set of legal rules in its rulebase and a reasoning engine for drawing conclusions. We intend to build the reasoning contract on the basis of well-known standards, improving the acceptance of the proposed method and relying on their existing support by modern tools.
To facilitate the creation of the rulebase from standardised legal norms representation, our method enables the import of legal norms stored in LegalRuleML format (OASIS, 2025a). This format is proposed by the organisation for standardisation OASIS (2025b), and is based on the XML format, making it readable for humans and computers. Its structure is defined by an XML Schema and supports two levels of detail: normalised and compact. Because the compact schema provides a more concise structure without loss of information, we choose to serialise legal norms using the compact schema.
Due to the lack of defeasible reasoners for the blockchain, we choose to build the reasoning engine on the basis of a first-order logic complemented by support for defeasible logic. Thus, we represent legal rules in predicate logic using the meta-program to enable defeasible reasoning. As a candidate for reasoning over logic programs in predicate logic, we choose the Prolog programming language.
For the implementation of the reasoning contract, we selected the Solidity programming language as it is one of the most widely used languages for the development of smart contracts (Rosa et al., 2025). Consequently, we also opted for EVM (Ethereum Virtual Machine) compatible environment for the deployment and execution of smart contracts, based on the fact that Ethereum is one of the most popular blockchain platforms for smart contract development (Singh et al., 2024).
The method presented in this paper considers the reasoning engine as an integral part of the reasoning contract, while legal norms depend on the chosen legal area and should be separately designed. Therefore, we propose building the reasoning contract from the reasoning contract template, containing the reasoning engine, by embedding a set of legal norms provided as a distinct document.
Figure 2 presents a diagram that illustrates how the legal norms and the reasoning contract template are used to build the reasoning contract. The diagram’s notation employs rectangles to represent units of code implemented in either XML or Solidity. Processing of these code units is depicted by a gear symbol. Arrows indicate the direction of data flow during the building of the reasoning contract.
Figure 2. Construction of the reasoning contract.
The smart contract template contains the reasoning engine consisting of a Prolog interpreter implemented in the Solidity language and the meta-program for defeasible reasoning. The legal norms are obtained in a machine-readable LegalRuleML format and transformed into a set of defeasible rules compatible with the reasoning engine. Construction of the reasoning contract is performed by embedding these rules in the smart contract template. After compiling the reasoning contract, it can be deployed to the blockchain to provide legal reasoning to other smart contracts.
We also created a utility tool that facilitates the construction of the smart contract reasoner and its deployment to the blockchain. The tool is developed in the Python programming language and fully automates the embedding of legal rules in the reasoning contract, its compilation and the deployment. More precisely, the tool performs a transformation of the legal norms provided in LegalRuleML format into a set of rules defined by statements implemented in the Solidity language. The tool then combines these statements with the reasoning contract template to generate the implementation of the reasoning contract. Further steps needed to run the reasoning contract on the blockchain, including compiling its source code and deploying the executable code to the blockchain, are also supported. In this way, it is easier to get a functional reasoning contract which can subsequently be utilised by other smart legal contracts.
3.1 Reasoning engine
The reasoning engine is based on a Prolog interpreter implemented in the Solidity language and published in Alt (2020). Consequently, the representation of rules and facts relies on object types defined by this interpreter. The Rule type serves as an object-based representation of a rule, while its head and body are represented by objects of the Term type. Each Term object can be assigned a value from the TermKind enumeration to distinguish between different term types, e.g., predicates (i.e., compound terms), atoms, variables, numbers, and lists.
We extended the interpreter to enable support for defeasible properties of legal rules by implementing a meta-program for defeasible reasoning. However, the original implementation of the interpreter has some limitations in terms of support for two types of negation, strong negation and negation as failure. The strong negation represents contradictory knowledge and is used to indicate contradictory conclusions. The negation as failure denotes incomplete knowledge, i.e., failure to derive a positive conclusion. To support negation as failure by the reasoning engine, we extended the implementation of the Prolog interpreter, modifying its reasoning algorithm. Support for strong negation is introduced as a part of legal rules representation, and its explanation is provided in the next subsections.
Negation as failure is represented with a special TermKind value, denoted by PredicateNot and used for negated predicates. To support reasoning based on this term type, we modify the algorithm implemented by the function query. This function enables the interpreter to draw conclusions on a given goal by consulting the rulebase. The function relies on the existing functions of the Prolog interpreter for handling unification and goal resolution, namely, unify and query, respectively. The substitution step, which is performed during unification, is called within the unify function, while all substitution data is stored in a single object and exchanged between function calls. By inspecting these functions, we identified that the scope for introducing support for negated predicates is within the query function.
The extended implementation of the function query is presented in the algorithm shown in Figure 3. At the beginning of this function, we insert the processing of negated terms. After that comes handling of other term types, as it was originally implemented by the query function. Due to the recursive nature of the query function, these changes enable support for negation as failure at all recursion levels.
Figure 3. Algorithm of the function query with support for negation as failure.
The function query receives an array of goals to be proved, the rulebase consisting of all rules and facts, and an object for storing substitution data. Processing of the goals in the array is performed from its beginning until the end of the array is reached. When the first goal from the array is obtained, its term type is examined. If the term is negated, an exhaustive search of the rulebase is performed, attempting to unify the non-negated goal with rules from the rulebase. If the unification of the non-negated goal with some rule succeeds, the algorithm takes the rule body and tries to prove it. If it succeeds, the function returns false.
In the case that no rule from the rulebase can be unified and proved, the negated term is considered to be true, and the execution continues by inferencing over the rest of the given goals in the array. For other term types, i.e., non-negated goals, the algorithm uses regular processing originally implemented by the query function.
3.2 Meta-program for defeasible reasoning
The reasoning engine draws conclusions from a set of rules defined in predicate logic. To support defeasible reasoning, we use a meta-program, i.e., a logic program that enables the processing of another logic program. In this case, we use the transformation of a defeasible theory presented in Antoniou and Bikakis (2005) into a meta-program to allow non-monotonic reasoning over the rules in the rulebase.
Therefore, we reuse the meta-program for defeasible reasoning, given as a set of rules in predicate logic, and make adaptations to support both types of negation. Support for negated predicates is implemented by extending the implementation of the Prolog interpreter as already explained. In the meta-program, we denote negation of a predicate by wrapping it with the predicate neg/1. For the strong negation, we introduce a custom predicate negation/2. This predicate has two arguments that correspond to two mutually contradictory conclusions. For example, if guilty and not_guilty are two complementary conclusions, the strong negation between them is declared by negation (guilty (X), not_guilty (X)) and vice versa negation (not_guilty (X), guilty (X)).
After these modifications, the meta-program for defeasible reasoning has the form as follows. The rule classes are defined by the following rules:
supportive_rule (Name, Head, Body):- strict (Name, Head, Body).
supportive_rule (Name, Head, Body):- defeasible (Name, Head, Body).
rule (Name, Head, Body):- supportive_rule (Name, Head, Body).
Definite provability of a term is defined using the following clauses:
definitely (X):- fact (X).
definitely (X):- strict (R, X, L), definitely_provable (L).
definitely_provable ([]).
definitely_provable (X):- definitely (X).
definitely_provable ([X1|X2]):- definitely_provable (X1), definitely_provable (X2).
Similarly, defeasible provability of a term is defined as follows:
defeasibly (X):- definitely (X).
defeasibly (X):- negation (X, X1), supportive_rule (R, X, L), defeasibly_provable (L), not (definitely (X1)), not (overruled (R, X)).
defeasibly_provable ([]).
defeasibly_provable (X):- defeasibly (X).
defeasibly_provable ([X1|X2]):- defeasibly_provable (X1), defeasibly_provable (X2).
The next clause determines if a rule is overruled:
overruled (R, X):- negation (X, X1), supportive_rule (S, X1, U), defeasibly_provable (U), not (defeated (S, X1)).
Similarly, the following clause determines if a rule is defeated:
defeated (S, X):- sup (T, S), negation (X, X1), supportive_rule (T, X1, V), defeasibly_provable (V).
The logic program listed above implements ambiguity blocking behaviour, meaning that in the absence of an applicable superiority relation, the ambiguity arising from conflicting conclusions is restricted to those conflicting conclusions only. By contrast, ambiguity propagation behaviour is achieved by propagating the ambiguity through the reasoning chain to the dependent predicates. In this case, the following clauses are used to determine if some rule is overruled:
overruled (R, X):- negation (X, X1), supportive_rule (S, X1, U), supported_list (U), not (defeated (S, X1)).
supported (X):- definitely (X).
supported (X):- supportive_rule (R, X, L), supported_list (L), not (defeated (R, X)).
supported_list ([]).
supported_list (X):- supported (X).
supported_list ([X1|X2]):- supported_list (X1), supported_list (X2).
Our method supports both ways to handle ambiguities, but the ambiguity propagation is chosen as the default mode. Optionally, by setting up the configuration parameters within the reasoning contract, it is possible to select ambiguity blocking behaviour.
The usage of the meta-program for establishing the rulebase is explained by the common example of defeasible reasoning. The following clauses express the defeasible rule defining that all birds fly and the defeasible rule defining that penguins do not fly:
defeasible (r1, fly (X), bird (X)).
defeasible (r2, neg_fly (X), penguin (X)).
According to the adopted style for denoting strong negation, the relation between mutually exclusive predicates fly and neg_fly is established using the next two clauses:
negation (fly (X), neg_fly (X)).
negation (neg_fly (X), fly (X)).
The superiority relation between rules r1 and r2 is defined by the following clause:
sup (r2, r1).
To define a fact that Tweety is a bird, we use the clause as follows:
fact (bird (tweety)).
To claim that Tweety is also a penguin can be expressed by the following clause:
fact (penguin (tweety)).
To determine if Tweety flies, a query can be defined using the clause as follows:
defeasibly (flies (tweety)).
3.3 Reasoning contract and its template
The reasoning contract providing legal reasoning on the blockchain is implemented as a smart contract whose interface is illustrated by UML notation shown in Figure 4.
Figure 4. Interface of the reasoning contract in UML.
Besides the fact that the reasoning contract aims to provide drawing conclusions based on its rulebase and input data, it also facilitates the instantiation of data objects exchanged with it. The interface of the reasoning contract defines the type ReasoningTerm to support the representation of logic terms passed to the reasoner. This data structure is used for representing both the input facts and the query. We created this data type instead of using the existing Term data type of the Prolog interpreter to overcome Solidity limitations regarding the usage of recursive data types in external functions. The structure of the ReasoningTerm type is illustrated in Figure 5 using UML notation.
Figure 5. Structure of the ReasoningTerm type in UML.
The ReasoningTerm type provides a basic structure sufficient for the transport of relevant data within the reasoning transactions. The field name represents the term’s name, and the field arguments represent an array of the term’s arguments.
The interface also defines two reasoning functions, concludeDefeasibly and concludeDefinitely, to determine if a given query can be proved either defeasibly or definitely, respectively. To facilitate instantiations of ReasoningTerm objects, three more functions are defined depending on the number of arguments in a term. However, functions supporting an even greater number of term arguments can be added similarly.
For the development of the reasoning contract template and its interface, we use Remix IDE (Remix Team, 2025), one of the most popular tools for the development of smart contracts. To facilitate testing and debugging of the reasoning contract, we use a Hardhat console (Nomic Foundation, 2025) that enables printing of debugging messages during the contract execution.
As the implementation of smart contracts should consider gas consumption during their execution, we take into account the guidelines given in Khanzadeh et al. (2023) during the development of the reasoning contract. It is expected that the reasoning contract is to be demanding in terms of gas burned for its reasoning algorithm, and therefore a special attention is paid to optimisation of its source code. We therefore adopted some recommendations regarding the use of calldata and memory modifiers for input data and a given query because these data are relevant only during the execution of the reasoning transaction, and none of them should be stored within the reasoning contract. Additionally, fixed-size arrays are chosen as the preferred representation for data collections as they consume less gas than variable-sized arrays.
The interface of the reasoning contract is important for other smart contracts because it specifies how the data should be exchanged with the reasoning contract when reasoning transactions are initiated. We therefore construct the reasoning contract template by inheriting the interface and implementing its methods. The source code of the reasoning contract template has a structure as shown in Figure 6.
Figure 6. Structure of the reasoning contract template.
The listing shows a simplified implementation of the reasoning contract template, emphasising its key elements. The contract uses the library RuleBuilder defined by the Prolog interpreter to facilitate the representation of the rulebase using the type Rule[]. This type is then used for the definition of the variable rulebase.
Within the constructor, the function loadMetaProgram is called to equip the reasoner with the meta-program required for defeasible reasoning, and the function loadLegalRules is called to initiate loading of the legal rules into the rulebase. Both function calls are executed when the contract is deployed, making the reasoner and its rulebase ready for upcoming reasoning requests.
The contract template implements a reasoning function concludeDefeasibly, that allows other smart contracts to obtain a conclusion based on given data and a query. This function returns a boolean type indicating whether the query can be proved defeasibly or not. Similarly, the function concludeDefinitely obtains a conclusion whether the query can be proved definitely.
The function loadLegalRules builds the rulebase with definitions of legal rules. Initially, the implementation of this function in the reasoning contract template contains only a comment that serves as a placeholder, indicating the position in the contract where statements for building the legal rules should be inserted. This way, the proposed template is independent of particular legal norms, and enables building of the reasoning contract for an arbitrary selection of legal rules.
Considering costs and limitations of computing power on the blockchain, we arrange the rulebase in a way that contributes to the better optimisation of the reasoning engine. The Prolog language performs its inference by searching through the rulebase in the order the rules appear in the rulebase (Clocksin and Mellish, 2003). Analysing the implementation of the Prolog interpreter, we confirmed this behaviour. Based on the fact that the Prolog interpreter sequentially loops through the array of rules when searching for a rule that unifies with the given goal, we intentionally arrange the rulebase, placing groups of rules in the rulebase by their anticipated frequency of unification. Therefore, the input facts are placed at the beginning of the rulebase, as we expect all of them should be unified at least once. Although the rulebase is part of the contract’s storage and the input facts are passed to the reasoning contract within the reasoning transactions, the query function is adapted to loop first through the facts array and then through the rest of the rulebase. On the other hand, because the rulebase may contain a broader range of legal rules than is required for a given reasoning transaction, the legal rules are positioned at the end of the rulebase array. The meta-program for defeasible reasoning is placed in the middle of the rulebase, i.e., between the input facts and the legal rules, since its use by the inference algorithm depends on the specific case and involves various criteria. However, these optimisations of the reasoning contract cannot be generalised, as their effectiveness depends on numerous factors, including the size of the rulebase, the variety of legal rules, the number of input facts, and the type of query.
4 Results
In this section, we show how a set of legal norms is transformed into a logic program and then embedded into the smart contract deployed to the blockchain, providing the legal reasoning to other smart contracts. To facilitate these steps, we use the utility tool that automates the building of the reasoning contract. We then demonstrate how the smart contract responds to the transaction initiated by other smart contracts. The source code of these smart contracts and the utility tool is available in an online repository (Marković and Gostojić, 2025).
A sample of legal norms is extracted from the Labour Law of the Republic of Serbia (National Assembly RS, 2005). In this document, Article 179, paragraph 5, point 1 prescribes that cessation of the need for the employer is a valid reason for the termination of employment. However, Article 187, paragraph 1, prevents the termination of employment during a pregnancy leave. These legal norms can be represented as follows:
r1: employmentTerminated (Employee):- noLongerNeeded (Employee)
r2: ∼employmentTerminated (Employee):- pregnant (Employee)
r2 > r1
Furthermore, these legal norms can be modelled by LegalRuleML to become machine-readable. Its serialisation is implemented manually, using an XML editor, as given in Figure 7. Since the LegalRuleML standard is based on the RuleML format, we use prefixes for both namespaces. The prefix lrml stands for LegalRuleML, and ruleml is for RuleML grammar.
Figure 7. Legal norms from labour law in LegalRuleML.
We represent legal rules using <lrml:PrescriptiveStatement> elements, as it reflects a legal statement that prescribes how something should be. These elements are wrappers for the <ruleml:Rule> element that defines a particular legal rule. We choose to name prescriptive statements after the abbreviation of legal citation referencing the corresponding legal norm. The similar convention we use for naming rule definitions. The element <ruleml:then> represents the head of a rule, and the element <rule:if> represents the rule’s body. Single predicates are represented by atoms, i.e., <ruleml:Atom> elements. If the predicate is negated, it is wrapped by <ruleml:Neg> element.
Superiority relations between rules are represented with <lrml:OverrideStatement> elements defined by LegalRuleML grammar. Therefore, we define the superiority relation between two prescriptive statements, declaring that one rule (referenced by its identifier within the attribute over) has superiority over the other rule (referenced within the attribute under).
To completely support the representation of legal norms by a machine-readable format, the LegalRuleML standard provides a grammar for representing sanctions where the definition of a sanction consists of atoms that follow from a violation of a rule. Besides the fact that sanctions can also be included in the rulebase, imposing sanctions is within the jurisdiction of judicial power and is beyond the authority of a smart contract. Therefore, we decide not to include sanctions in the rulebase.
By using the utility tool for constructing the reasoning contract, an XSLT transformation is applied to the legal norms, resulting in a set of rules defined in the Solidity language. Prescriptive statements are transformed into definitions of defeasible rules, while override statements are converted into definitions of superiority relations. During the transformation process, when a negation appears in the head of a rule, two additional rules are generated to represent the relation between the negated and non-negated terms. The outcome of the transformation is presented in Figure 8.
Figure 8. Legal rules from labour law defined in solidity language.
The utility tool automatically inserts these statements in the source code of the reasoning contract template instead of the placeholder for legal rules. The tool then compiles the contract, generating bytecode of the contract and its ABI. After compiling and deploying the reasoning contract on the blockchain, the tool displays its address. Using this address, other smart contracts are able to use the reasoning contract and to initiate transactions following the ABI.
Evaluation of the reasoning contract is performed using Anvil (Foundry, 2025). Anvil is an Ethereum node suitable for smart contract developers. Initially, it has ten predefined accounts preloaded with 10,000 ETH each, making the testing of smart contracts easier. For evaluation of the reasoning contract, the Anvil node is run on a personal computer with an Intel® Core™ i7-1355U processor with 10 cores and 32 GB of RAM.
If the ambiguity propagation mode is selected, the reasoning contract we deploy to the blockchain contains 25 rules in the rulebase, of which 20 rules form the meta-program for defeasible reasoning, and five rules represent regulations from the Labour law. Its deployment to the local Ethereum node costs 11,860,104 gas.
When the reasoning mode of the smart contract is set to the ambiguity blocking behaviour, the rulebase contains 20 rules, where 15 of them constitute the meta-program, and five rules are the legal rules. In this case, the reasoning contract deployment consumes 10,143,495 gas units.
To demonstrate the use of the reasoning contract, an employment contract is implemented to represent a legal relationship that requires legal reasoning in the context of employment termination. Employment contract is designed only for evaluation of the reasoning contract, and therefore, it contains only two variables to represent its state, i.e., whether the employee is no longer needed and whether the employee is pregnant. The contract also provides three public functions, i.e., two setters for the variables and the function to invoke a call to the reasoning contract and to obtain drawn conclusions. The mechanism of proving the facts related to the employment status by providing some legal evidence is outside the scope of this paper and has not been fully implemented. The employment contract implements the function isEmploymentTerminated for initiating a reasoning transaction to determine if the employment is terminated. This function performs an external call to the reasoning contract, passing facts related to the employee and the query about the employment status. Since the input data should be transferred to the reasoning contract as an array, we choose to use a fixed-size array to optimise gas consumption. Therefore, the function begins by counting the number of facts that need to be transferred, then instantiates the array and inserts the data into it. Deployment of the employment contract burns 575,648 gas units.
We evaluate the reasoning contract by changing the states of the employment contract and initiating the reasoning about employment termination. Execution of transactions to determine if the employment is terminated yields the results shown in Table 1.
Table 1. Reasoning results and gas consumption.
A smaller part of the gas burned by the employment contract is used for the instantiation of input data passed to the reasoning contract, and the reasoning contract itself consumes the rest. Omitting the invocation of the reasoning transaction from the implementation of the employment contract shows that the employment contract alone consumes between 34,397 and 44,004 gas units in reasoning transactions.
5 Discussion
In this section, we analyse results obtained by demonstrating the method for legal reasoning on the blockchain. It should be noted that the method is applied to a relatively simple use case, selected as a proof of concept. The application of the reasoning engine to real-world contractual agreements would inevitably introduce greater complexity into the rulebase. For example, it would need to incorporate legal norms relevant to contractual agreements, as determined by contract law, as well as legal norms for other areas of regulation depending on the subject matter of the agreement. Furthermore, some legal and technological challenges commonly associated with the automation of legal agreements using smart contracts remain. These include integration with the physical world (e.g., detecting off-chain events and communicating with off-chain systems) and the recognition of smart contracts as legally binding agreements within the legal framework (Mik, 2017). Consequently, some contractual provisions may not be implementable by smart contracts, thereby limiting the rulebase to legal rules that are executable within an on-chain environment.
In the use case presented in this paper, the rulebase contains three legal rules: two defeasible rules and one rule establishing a superiority relation between them. To evaluate how the number of legal rules in our rulebase compares with some of the available examples of smart legal contracts, we examine the respective rulebases used in those cases. O’Sullivan (2022) considers several types of smart contracts, providing their implementations based on sets of first-order logic rules. For instance, an insurance contract comprises 12 rules in its knowledge base, a smart contract for product evaluation licensing uses 11 rules, and a crowdfunding contract operates on the basis of seven logic rules. Although the number of legal rules utilised in this paper is smaller than in these examples, it nonetheless serves as a demonstrative case which may be extended and similarly supplemented with additional rules.
Considering the results and performance of the reasoning contract used within the employment contract, we discuss our key findings. The reasoning outcomes for the given data align with the principles of defeasible logic in both reasoning modes. Both modes share the same conclusions due to a relatively small set of rules where no uncertainty occurs between these rules. However, the efficiency of the reasoning process should be discussed in detail.
The amount of gas consumed by the employment contract during the reasoning process varies significantly. As expected, the ambiguity blocking behaviour consumes noticeably less gas than the ambiguity propagating behaviour, due to the smaller set of rules within the rulebase. More specifically, in the ambiguity propagation mode the reasoner must determine for each potential conclusion whether ambiguity arising from its antecedents should be propagated, which results in additional unification attempts within the Prolog interpreter. By contrast, such additional attempts do not occur in ambiguity blocking mode, as ambiguity is restricted to the conflicting conclusions themselves. However, since the rulebase contains a superiority relation for every pair of contradictory conclusions, both modes yield the same reasoning outcome. Given that the most substantial differences in gas consumption arise from reasoning over different states of the employment contract variables, the analysis is conducted with respect to the values of these variables, making the observations applicable to both operating modes of the reasoning contract.
The lowest gas consumption occurs when no input facts are provided to the reasoning contract, resulting in a smaller set of data provided to the reasoner. This thereby reduces the number of cycles required by the Prolog interpreter to unify rule heads with the specified goal. Moreover, the absence of input data prevents the application of legal rules, which in turn leads to fewer term unifications.
The reasoning process requires more gas when the reasoner is informed that the employee is pregnant. This fact increases the rulebase by one and supports the reasoning against the given goal. However, the rule that confirms the goal cannot be fired due to the absence of other facts, and therefore prevents a positive conclusion and also eliminates any conflicts between rules.
A significantly greater amount of gas is required when the fact that the employee is no longer needed is supplied to the reasoning engine. Although only a single input fact is added to the rulebase, supporting the positive conclusion, the gas consumption is more than three times higher compared to the previous scenario. This behaviour can be attributed to the structure of the meta-program used for defeasible reasoning. A goal can be defeasibly proven if there is a supportive rule applicable to the goal that can be confirmed, provided that no conflicting rule can also be confirmed, and any other rule in the rulebase does not overrule the supportive rule. Consequently, in the previous case, the Prolog interpreter is able to terminate the reasoning process earlier due to the absence of a fact confirming a supportive rule for the goal. In contrast, the presence of the single fact that the employee is no longer needed confirms the supportive rule for the given goal and therefore requires the Prolog interpreter to carry out further unification iterations in order to eliminate potential conflicts and instances of overruling.
In the last scenario, where the two input facts are passed to the reasoner, the most gas is spent. Based on these facts, two contradictory legal rules are confirmed: the first saying that employment should be terminated because the employee is no longer needed, and the second that negates employment termination due to the employee’s pregnancy. For resolving the conflict, the interpreter must also include the superiority relation in the reasoning, causing the additional gas to be burned compared to the previous case.
By analysing the execution of the reasoning transactions, we identified several factors that contribute to the majority of gas consumption, in accordance with the guidelines provided by Khanzadeh et al. (2023) and the Solidity documentation (Reitwiessner et al., 2025). Iterating through an array of rules to locate a unifiable rule is considered less efficient than using mappings composed of key-value pairs. In addition, the use of dynamically sized arrays to store temporary data during the inference process incurs further costs, as such data must be allocated in storage, which is the most expensive data location in terms of gas consumption. Furthermore, the recursive structure of query evaluation increases gas consumption, because each recursive call generates additional computational steps and storage-related operations within the EVM. Using the meta-program to support defeasible logic exacerbates these issues by introducing an additional layer of rules that must be applied by the interpreter. This meta-level reasoning mechanism increases the depth of recursive calls and simultaneously expands the search space of the inference algorithm. Therefore, efforts to reduce the computational complexity of the reasoning contract should focus on optimising the underlying reasoning algorithm and its implementation, or even on extending the built-in support of the logic interpreter for non-monotonic constructs.
Regardless of the fact that the reasoning contract is run on the local EVM and thus does not require additional costs, the expenses needed to run it on the Ethereum mainnet are predictable and can be calculated. Interactions with the smart contract are executed through transactions, and the formula for determining transaction costs is as follows: amount of gas spent multiplied by the gas price per unit (Ethereum, 2025). Assuming the current ETH price of $2,546.20 and the average gas price of 0.74 gwei (Etherscan, 2025), the deployment of the reasoning contract operating in ambiguity propagation mode would cost approximately $22.35, while the cost of reasoning transactions would range from $396.31 to $1689.94. In ambiguity blocking mode, the deployment would cost $19.11, with reasoning transactions ranging from $315.99 to $1346.30. Although the most expensive transaction in the employee contract consumes 896,907,170 gas units and costs $1689.94, there are EVM-compatible blockchain networks with significantly lower gas prices. For example, the BNB Smart Chain uses BNB cryptocurrency, priced at $909.66 (Binance, 2025), while a gas price of 0.05 gwei (BscScan, 2025) results in cost of approximately $40.79 for the most expensive transaction of the employment contract. The cost may be even lower on certain blockchain networks, for example,: Cronos at approximately $38 (Crypto.com, 2025; Cronos Labs, 2025), Polygon PoS at around $23 (PolygonScan, 2025; CoinMarketCap, 2025), and Avalanche C-Chain at approximately $2 (Avascan, 2025). However, even when opting for a more affordable blockchain, the limitations concerning the amount of computational power allocated to appending a new block may pose an obstacle for computationally demanding transactions. Moreover, the amount of gas spent by the reasoning transactions exceeds the limits defined by the Ethereum mainnet. Currently, it is set to 45 million gas units per entire block (Chawla, 2025), implying that gas spent by a single transaction cannot exceed that threshold. In the case of the employment contract and the reasoning contract, both can be deployed on the Ethereum mainnet, and transactions for setting the employment contract variables can be executed as their gas consumption is less than the limit. However, regardless of the states of the variables in the employment contract, the reasoning transactions require a greater amount of gas than the limits imposed by the Ethereum mainnet allow, which makes the choice of the target platform incline towards other, less constrained blockchains.
The gas limit per block on Ethereum mainnet has been gradually increasing over time and there are some initiatives proposed by experts in the field suggesting that the limit should still be raised (Buterin, 2025; Rebuffo, 2025), while some experts propose even a hundred times higher gas limits per block (Feist, 2025). Thus, taking these actions would accommodate the growing needs of smart contracts and decentralised applications, enabling the emergence of innovations in fields demanding more complex solutions (Gate, 2025).
While the amount of gas spent on the reasoning transactions is significantly above the average on the Ethereum network, it also reflects the complexity of defeasible reasoning. While the deployment transaction of the reasoning contract fits the limitations of Ethereum, the set of legal rules used for demonstrating the reasoning contract is relatively small. In a real-world scenario, the rulebase should be significantly larger, increasing deployment fees.
Apart from Ethereum, the gas limits of other public blockchain networks are currently also insufficient for running inference transactions of the reasoning contract (Binance, 2024; Moonbeam, 2025). Analysing public EVM-compatible blockchain networks, we found that Sonic (2025) has the gas limit per block as high as 1 billion gas units, making it a candidate for enabling public access to the reasoning contract with inevitable work on the reasoning algorithm optimisation. Nevertheless, the reasoning contract in this form could still be run in a custom-configured environment.
In comparison to some real-world examples of smart contracts, the reasoning contract presented in this paper requires significantly higher fees. In Omar et al. (2021), the auction system is implemented using a smart contract whose transactions spend gas in the range between 30,195 and 889,234, where the former is for a single bid, while the latter is for the smart contract deployment. Another example is the Uniswap V2 smart contract designed to enable a decentralised cryptocurrency exchange (Uniswap, 2025). Its deployment burns 3,049,335 gas (Etherscan, 2020), while the gas used by single transactions can range from 132,806 to 2,011,234 gas units (Github, 2023).
6 Conclusion
In this paper, we present a solution for legal reasoning on the blockchain. A smart contract implements the reasoning engine and fully provides on-chain reasoning supporting defeasible logic. We utilise the reasoner to facilitate legal reasoning in smart contracts, thereby enabling a separation between the implementation of the contract provisions and the application of legal norms.
The approach used for legal reasoning is a proof of concept that examines the feasibility of performing the entire inference process on-chain. In this way, the algorithm and all associated data reside on the blockchain, thereby ensuring transparency of the reasoning process and public verifiability with the aim of enhancing the trust of the contracting parties. Due to the limitations on the applicability of embedded legal norms to a particular jurisdiction and legal area, the solution presented in this paper should be deployed on a private blockchain maintained by the relevant stakeholders, rather than on a public blockchain.
The method presented in this paper relies on the legal rules in LegalRuleML format. To ensure their availability in this format, it should be created either manually or by using some of the software tools. For the purpose of this research, this document is created manually using an XML editor due to a relatively small set of legal rules. However, for further exploitation of this method for defeasible reasoning on the blockchain, a LegalRuleML editor should be considered (e.g., Palmirani et al., 2013; CIRSFID, 2025) or tools supporting the transformation of legal texts into LegalRuleML format (e.g., Fuchs et al., 2023; Srivastava, 2025).
Currently, the reasoning contract encompasses both the representation of legal norms and the implementation of legal reasoning. However, in the future, these two components should be decoupled and managed by their respective competent authorities. In democratic systems that follow the principle of separation of powers, the enactment of legal norms is in the jurisdiction of legislative power, while the interpretation and application of law is typically in the jurisdiction of judicial power. If we transfer this model to the blockchain, legislative power should be responsible for managing the rulebase, and the judicial power should provide legal reasoning on the blockchain.
Maintaining the reasoning contract brings some challenges due to the immutability of the blockchain ledger. Therefore, any improvements to the reasoning engine or a bugfix would require redeployment of the contract with a new address assigned. This entails other consequences as well, because all smart contracts relying on the reasoning contract should be updated to send transactions to the new address. A solution to this problem could be using a proxy contract (Van Vulpen et al., 2024). This way, only the proxy contract needs to be updated to the latest address of the reasoning contract, while other smart contracts would be configured to call functions of the proxy contract.
Another issue concerning the maintenance of the reasoning contract arises from amendments to the law. It is a common occurrence in the lifecycle of legal acts, which may introduce new legal rules or require modification or removal of existing ones. This would require updating the affected rules within the reasoning contract’s rulebase. However, to ensure application of the law that was in force at the moment when some action occurred, the reasoner must support the temporal characteristics of the law. Therefore, the reasoner contract should encompass all versions of the rulebase over time, enabling the application of those legal norms that were in force at a specific point in time.
6.1 Architectural optimisation for cost reduction
One of the most critical tasks that should be tackled before bringing the presented method into public use is overcoming issues between computational complexity (and computational costs) of the reasoning contract and the limitations imposed by blockchain networks. Nevertheless, recent raising of gas limits adopted by some of popular blockchains is promising and reflects willingness of public blockchain networks to support increasing complexity of smart contracts. This trend is also announced to continue on some networks as a part of plans for further upgrade bringing the maximum gas limit per block to billion gas units in the following months (Rozyuk, 2025). Challenges posed by gas limits are well-recognised by smart contract developers, and such contracts are referred to as Computation Intensive smart Contracts (CICs) (Wu et al., 2022). Efforts to address this issue have been documented in Sariboz et al. (2021) and Das et al. (2018) and include off-chain processing of computationally demanding tasks.
We therefore identify several directions for adapting the current architecture according to the limitations and the nature of the blockchain. It includes reducing the computational complexity of the reasoning algorithm and using off-chain computations by moving reasoning engine outside the blockchain or by employing Layer 2 networks.
As the costs of deployment and reasoning should be decreased, one approach to achieve this could be through the optimisation of the reasoning contract’s source code. Considering that the role of the reasoning contract does not require storing any data, but only processing the input data, its implementation should be altered accordingly. Some of the optimisation steps are discussed in this paper and include the use of the mapping data type instead of arrays, the use of fixed-size arrays, and the avoidance of recursive calls.
However, the limitations of blockchain can be overcome by performing legal reasoning off-chain, and verifying the obtained results on-chain. This way, combining on-chain and off-chain processing allows the most complex computations to be executed outside the blockchain, enabling the smart contracts to focus on storing relevant data and executing verification procedures to ensure the correctness and integrity of off-chain computations. This approach preserves integrity of the reasoning transactions, while significantly reducing gas consumption.
Another way could be the adoption of modern off-chain scaling solutions and Layer 2 (L2) networks, e.g., ZKsync (2025), MegaETH (2025). These L2 networks provide greater flexibility regarding the permitted computational complexity and incur lower gas fees, while maintaining the security guarantees of the underlying Layer 1 blockchain. However, using the RPC method eth_call (Klappp, 2025) by off-chain applications to initiate the reasoning process is sufficient to obtain the reasoning results without incurring any gas costs and without creating a transaction on the blockchain.
Data availability statement
The datasets presented in this study can be found in online repositories. The names of the repository/repositories and accession number(s) can be found in the article/supplementary material.
Author contributions
MM: Validation, Conceptualization, Methodology, Writing – review and editing, Investigation, Writing – original draft, Visualization, Software. SG: Writing – review and editing, Methodology, Conceptualization, Validation.
Funding
The author(s) declared that financial support was received for this work and/or its publication. This research has been supported by the Ministry of Science, Technological Development and Innovation (Contract No. 451-03-137/2025-03/200156) and the Faculty of Technical Sciences, University of Novi Sad through project “Scientific and Artistic Research Work of Researchers in Teaching and Associate Positions at the Faculty of Technical Sciences, University of Novi Sad 2025” (No. 01-50/295).
Conflict of interest
The author(s) declared that this work was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.
Generative AI statement
The author(s) declared that generative AI was not used in the creation of this manuscript.
Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.
Publisher’s note
All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.
References
Alt, L. (2020). A prolog engine written in solidity. Available online at: https://github.com/leonardoalt/SolPrologV2 (Accessed September 19, 2025).
Antoniou, G., and Bikakis, A. (2005). “DR-Prolog: a system for reasoning with rules and ontologies on the semantic web,” in Proc. 7th int. Symp. Logical formalizations of commonsense reasoning. Corfu, 22–24.
Antoniou, G., and Maher, M. J. (2002). “Embedding defeasible logic into logic programs,” in Proc. 18th int. conf. logic program. (ICLP 2002). (Berlin Heidelberg: Springer), 393–404. doi:10.1007/3-540-45619-8_27
Antoniou, G., Billington, D., Governatori, G., and Maher, M. J. (2000). “A flexible framework for defeasible logics,” in Proc. 17th Natl. Conf. Artif. Intell. and 12th Conf. Innov. Appl. Artif. Intell, 405–410.
Avascan (2025). Avalanche blockchain explorer. Available online at: https://avascan.info/ (Accessed November 19, 2025).
Bassiliades, N., Antoniou, G., and Vlahavas, I. (2004). “DR-DEVICE: a defeasible logic system for the semantic web,” in Principles Pract. Semantic web reasoning: 2nd Int. Workshop (PPSWR 2004) (Berlin Heidelberg: Springer), 134–148. doi:10.1007/978-3-540-30122-6_10
Binance (2024). BNB chain releases Web3 blueprint: integrating BSC, opBNB and greenfield through one BNB strategy. Binance Sq. Available online at: https://www.binance.com/en/square/post/4457871582674 (Accessed September 19, 2025).
Binance (2025). BNB price (BNB). Available online at: https://www.binance.com/en/price/bnb (Accessed November 19, 2025).
BscScan (2025). BNB smart chain gas tracker. Available online at: https://bscscan.com/gastracker (Accessed November 19, 2025).
Buterin, V. (2025). Reasons to have higher L1 gas limits even in an L2-heavy Ethereum. Available online at: https://vitalik.eth.limo/general/2025/02/14/l1scaling.html (Accessed September 19, 2025).
Chawla, V. (2025). Ethereum hits 45 million block gas limit in latest scaling move. Block. Available online at: https://www.theblock.co/post/363763/ethereum-hits-45-million-block-gas-limit (Accessed September 30, 2025).
Cheong, B. C. (2024). Transparency and accountability in AI systems: safeguarding wellbeing in the age of algorithmic decision-making. Front. Hum. Dyn. 6, 1421273. doi:10.3389/fhumd.2024.1421273
Cheong, B. C. (2025). “Different regulatory treatment of generative AI blockchain, cryptocurrency, and NFT,” In Handbook of blockchain, digital finance, and inclusion. Academic Press. doi:10.1016/b978-0-443-34717-7.00012-x
CIRSFID (2025). Lime - demo. Available online at: http://lime.cirsfid.unibo.it/?page_id=2 (Accessed September 19, 2025).
Clocksin, W. F., and Mellish, C. S. (2003). Programming in PROLOG. Springer Science and Business Media.
CoinMarketCap (2025). Polygon (prev. MATIC) price today. Available online at: https://coinmarketcap.com/currencies/polygon-ecosystem-token/ (Accessed November 19, 2025).
Colmerauer, A., Kanoui, H., Pasero, R., and Roussel, P. (1973). Un systeme de communication homme-machine en francais. Rapp. Prelim. Groupe Res. Intell. Artif.
Cronos Labs (2025). Cronos gas price. Available online at: https://cronos.org/gastracker (Accessed November 19, 2025).
Crypto.com (2025). Cronos (CRO) price today. Available online at: https://crypto.com/en/price/cronos (Accessed November 19, 2025).
Das, S., Ribeiro, V. J., and Anand, A. (2018). Yoda: enabling computationally intensive contracts on blockchains with byzantine and selfish nodes. arXiv. doi:10.48550/arXiv.1811.03265
Ebrahimi, S., Habibi, H., Hassanizadeh, P., Toolabi, P., Botta, V., and Dziembowski, S. (2025). Burn your vote: decentralized and publicly verifiable anonymous voting at scale. Cryptology ePrint Archive.
Ethereum (2025). Gas and fees. Available online at: https://ethereum.org/en/developers/docs/gas/ (Accessed September 19, 2025).
Etherscan (2020). Ethereum transaction details. Available online at: https://etherscan.io/tx/0xc31d7e7e85cab1d38ce1b8ac17e821ccd47dbde00f9d57f2bd8613bff9428396 (Accessed September 19, 2025).
Etherscan (2025). Ethereum gas tracker. Available online at: https://etherscan.io/gastracker (Accessed September 20, 2025).
Feist, D. (2025). EIP-7938: exponential gas limit increase. EIPs Insight. Available online at: https://eipsinsight.com/eips/eip-7938 (Accessed September 19, 2025).
Foundry (2025). Foundry book. Available online at: https://book.getfoundry.sh/anvil/ (Accessed September 19, 2025).
Fuchs, S., Dimyadi, J., Ronee, A. S., Gupta, R., Witbrock, M., and Amor, R. (2023). “A LegalRuleML editor with transformer-based autocompletion,” in Proceedings of the 2023 European Conference on Computing in Construction and the 40th International CIB W78 Conference, Heraklion, Crete, Greece. doi:10.35490/EC3.2023.233
Gate (2025). To pump the gas or not: analyzing the ethereum gas limit debate. Available online at: https://www.gate.io/learn/articles/to-pump-the-gas-or-not-analyzing-the-ethereum-gas-limit-debate/6197 (Accessed September 19, 2025).
Github (2023). Uniswap gas comparison. Available online at: https://github.com/0xClandestine/uniswap-gas (Accessed September 19, 2025).
Gómez, A. P. (2022). Rule-based expert systems for automated legal reasoning and contract analysis: a case study in knowledge representation. Adv. Comput. Syst. Algorithms Emerg. Technol. 7 (1), 19–34.
Governatori, G., Idelberger, F., Milosevic, Z., Riveret, R., Sartor, G., and Xu, X. (2018). On legal contracts, imperative and declarative smart contracts, and blockchain systems. Artif. Intell. Law 26, 377–409. doi:10.1007/s10506-018-9223-3
Hu, J., and Zhong, Y. (2018). “A method of logic-based smart contracts for blockchain system,” in Proc. Int. Conf. Data process, 58–61. doi:10.1145/3224207.3224218
Idelberger, F., Governatori, G., Riveret, R., and Sartor, G. (2016). “Evaluation of logic-based smart contracts for blockchain systems,” in Rule Technol. Res. Tools Appl., 10th Int. Symp. RuleML 2016 (Springer Int. Publ), 167–183. doi:10.1007/978-3-319-42019-6_11
Kasatkina, M. (2021). The interpretation of smart contracts in the EU and the USA. Int. Comp. Jurisprud. 7 (2), 202–217. doi:10.13165/j.icj.2021.12.007
Khanzadeh, S., Samreen, N., and Alalfi, M. H. (2023). “Optimizing gas consumption in Ethereum smart contracts: best practices and techniques,” in Proc. IEEE 23rd Int. Conf. Softw. Qual. Reliab. Secur. Companion (QRS-C). doi:10.1109/QRS-C60940.2023.00056
Klappp (2025). Eth_call RPC Method - Ethereum RPC method documentation - chainnodes. Available online at: https://www.chainnodes.org/docs/ethereum/eth_call (Accessed September 19, 2025).
Maher, M. J., Rock, A., Antoniou, G., Billington, D., and Miller, T. (2001). Efficient defeasible reasoning systems. Int. J. Artif. Intell. Tools 10 (04), 483–501. doi:10.1142/S0218213001000623
Marković, M., and Gostojić, S. (2025). Defeasible reasoner for smart contracts. Available online at: https://github.com/legal-informatics/defeasible-reasoner-for-smart-contracts (Accessed September 22, 2025).
MegaETH (2025). MegaETH docs. Available online at: https://docs.megaeth.com/faq (Accessed November 19, 2025).
Mik, E. (2017). Smart contracts: terminology, technical limitations and real world complexity. Law Innov. Technol 9 (2), 269–300. doi:10.1080/17579961.2017.1378468
Moonbeam (2025). Moonbeam docs: moonbeam network overview. Available online at: https://docs.moonbeam.network/learn/platform/networks/moonbeam/ (Accessed September 19, 2025).
Nomic Foundation (2025). Hardhat network | Ethereum development environment for professionals. Available online at: https://hardhat.org/hardhat-network/docs/overview#console.log (Accessed September 19, 2025).
Nute, D. (2001). “Defeasible logic,” in Proc. Int. Conf. Appl. Prolog (Berlin, Heidelberg: Springer), 151–169.
OASIS (2025a). OASIS LegalRuleML technical commitee. Available online at: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=legalruleml (Accessed September 19, 2025).
OASIS (2025b). Setting the standard for open collaboration. Available online at: https://www.oasis-open.org/ (Accessed September 19, 2025).
Omar, I. A., Hasan, H. R., Jayaraman, R., Salah, K., and Omar, M. (2021). Implementing decentralized auctions using blockchain smart contracts. Technol. Forecast. Soc. Change 168, 120786. doi:10.1016/j.techfore.2021.120786
O’Sullivan, A. (2022). Chainlog: a logic-based smart contract language [undergraduate thesis], department of computing undergraduate archive. London, United Kingdom: Imperial College London.
Palmirani, M., Cervone, L., Bujor, O., and Chiappetta, M. (2013). “RAWE: a web editor for rule markup in LegalRuleML,” in CEUR Workshop Proc.
PolygonScan (2025). Polygon PoS chain gas tracker. Available online at: https://polygonscan.com/gastracker (Accessed November 19, 2025).
Rebuffo, G. (2025). EIP-7783: add controlled gas limit increase strategy. Ethereum Improv. Propos. Available online at: https://eips.ethereum.org/EIPS/eip-7783 (Accessed September 19, 2025).
Reitwiessner, C., Wood, G., and Beregszaszi, A. (2025). Solidity documentation. Available online at: https://docs.soliditylang.org/en/latest/ (Accessed September 19, 2025).
Remix Team (2025). Remix - Ethereum IDE. Available online at: https://remix.ethereum.org/ (Accessed September 19, 2025).
Rodgers, I., Armour, J., and Sako, M. (2023). How technology is (or is not) transforming law firms. Annu. Rev. Law Soc. Sci. 19 (1), 299–317. doi:10.1146/annurev-lawsocsci-111522-074716
Rosa, G., Scalabrino, S., Mastrostefano, S., and Oliveto, R. (2025). Why and how developers maintain smart contracts. Empir. Softw. Eng. 30 (3), 84. doi:10.1007/s10664-025-10639-9
Rozyuk (2025). BNB plans to increase the gas limit by 10 times. Binance Sq. Available online at: https://www.binance.com/en/square/post/27449519488682 (Accessed September 19, 2025).
Sariboz, E., Kolachala, K., Panwar, G., Vishwanathan, R., and Misra, S. (2021). “Off-chain execution and verification of computationally intensive smart contracts,” in Proc. IEEE Int. Conf. Blockchain Cryptocurr. (ICBC) (IEEE), 1–3.
Schär, F. (2021). Decentralized finance: on blockchain- and smart contract-based financial markets. Fed. Reserve Bank. St. Louis Rev. 103 (2), 153–174. doi:10.20955/r.103.153-74
Sharifi, S. S. (2020). Smart contracts: from formal specification to blockchain code [Dissertation]. Ottawa, Canada: University of Ottawa.
Singh, R., Gupta, A., and Mittal, P. (2024). A systematic literature review on blockchain-based smart contracts: platforms, applications, and challenges. Distrib. Ledger Technol. Res. Pract. 5, 1–36. doi:10.1145/3704741
Sonic (2025). Sonic documentation: network parameters. Available online at: https://docs.soniclabs.com/sonic/build-on-sonic/network-parameters (Accessed September 19, 2025).
Srivastava, S. (2025). An LLM enabled XML generator for Indian laws in the LegalDocML and LegalRuleML formats. Available online at: https://github.com/sankalpsrv/Schematise (Accessed September 19, 2025).
Szabo, N. (1997). Formalizing and securing relationships on public networks. First Monday 2 (9). doi:10.5210/fm.v2i9.548
Uniswap (2025). Uniswap 101: what is uniswap? Uniswap Labs. Available online at: https://blog.uniswap.org/what-is-uniswap (Accessed September 19, 2025).
Van Vulpen, P., Heijnen, H., Mens, S., Kroon, T., and Jansen, S. (2024). Upgradeable diamond smart contracts in decentralized autonomous organizations. Front. Blockchain 7, 1481914. doi:10.3389/fbloc.2024.1481914
Van Woensel, W., and Seneviratne, O. (2025). Semantic interoperability on blockchain by generating smart contracts based on knowledge graphs. Blockchain Res. Appl., 100320. doi:10.1016/j.bcra.2025.100320
Wu, C., Xiong, J., Xiong, H., Zhao, Y., and Yi, W. (2022). A review on recent progress of smart contract in blockchain. IEEE Access 10, 50839–50863. doi:10.1109/ACCESS.2022.3174052
ZKsync (2025). ZKsync docs. Available online at: https://docs.zksync.io/zksync-protocol/era-vm/transactions/blocks (Accessed November 19, 2025).
Keywords: defeasible logic, legal reasoning, smart contracts, blockchain, solidity
Citation: Marković M and Gostojić S (2026) Defeasible logic reasoner to support legal reasoning in smart contracts on blockchain. Front. Blockchain 8:1724292. doi: 10.3389/fbloc.2025.1724292
Received: 13 October 2025; Accepted: 09 December 2025;
Published: 07 January 2026.
Edited by:
Akber Datoo, Independent researcher, London, United KingdomReviewed by:
Ben Chester Cheong, Singapore University of Social Sciences, SingaporeHewa Majeed Zangana, University of Duhok, Iraq
Sayyed Usman Ahmed, Aligarh Muslim University, India
Copyright © 2026 Marković and Gostojić. This is an open-access article distributed under the terms of the Creative Commons Attribution License (CC BY). The use, distribution or reproduction in other forums is permitted, provided the original author(s) and the copyright owner(s) are credited and that the original publication in this journal is cited, in accordance with accepted academic practice. No use, distribution or reproduction is permitted which does not comply with these terms.
*Correspondence: Marko Marković, bWFya2ljQHVucy5hYy5ycw==