A Practical System Architecture for Contract Automation: Design and Uses

TL;DR

This paper argues that blockchain-based smart contracts are limited for real-world contracting due to legal interpretability and operational challenges, while traditional e-contracts lack machine readability and automation infrastructure. It proposes a pragmatic contract network architecture that uses Ricardian contracts with machine-readable parameters, enabling secure negotiation, automated execution, and non-repudiable audit trails without requiring global consensus. The authors detail contract templates and invocation, a negotiation state machine, and reference tracing to external data, and illustrate utility via four use cases: data data delivery, treasury management, order-driven manufacturing, and device on-boarding. By examining realization strategies, trust models, and improvements such as state-transition contracts and digital identities, the work offers a practical pathway to scalable, automated contracting across industries while maintaining legal compatibility.

Abstract

While the blockchain-based smart contract has become a hot topic of research over the last decade, not the least in the context of Industry 4.0, it now has well-known legal and technical shortcomings that currently prohibit its real-world application. These shortcomings come from (1) that a smart contract is a computer program, not a document describing legal obligations, and (2) that blockchain-based systems are complicated to use and operate. In this paper, we present a refined and extended summary of our work taking key technologies from the blockchain sphere and applying them to the ricardian contract, which is a traditional contract in digital form with machine-readable parameters. By putting the ricardian contract in the context of our contract network architecture, we facilitate the infrastructure required for contracts to be offered, negotiated, performed, renegotiated and terminated in a completely digital and automatable fashion. Our architecture circumvents the legal issues of blockchains by facilitating an artifact very much alike a traditional contract, as well as its operational complexity by requiring consensus only between nodes representing directly involved parties. To demonstrate its utility, we also present how it could be used for (1) private data purchasing, (2) treasury management, (3) order-driven manufacturing and (4) automated device on-boarding.

Figures (9)

• Figure 1: The types used to represent contracts. $k$, $v$ and $t$ denote keys, values and type specifications. $(a, b)$ denotes the tuple of types $a$ and $b$, while $e[]$ represents an array of elements of type $e$.
• Figure 2: An example of a contract and its template. Note how both contain the same keys. The former associates them with values while the latter associates them with types.
• Figure 3: A state-machine representing a negotiation between two agents. The agents take turn to perform a state machine transition either by sending messages or by waiting until the session expires.
• Figure 4: A contract network of agents x, y and z. Each agent is controlled by a human, either directly or by policy. Naive definitions for offers ($o_{i,j}$), acceptances ($a_{i,j}$) and rejections ($r_{i,j}$) are given at the bottom, where $i$ identifies a negotiation session and $j$ an offer made while that session was live. The primary utility of $j$ is that it allows our acceptances and rejections to be specific about what offers they refer to. Parties x and y offer $o_{5,1}$ and $o_{7,1}$ to z, which accepts $o_{5,1}$ with $a_{5,1}$ but counters $o_{7,1}$ with $o_{7,2}$.
• Figure 5: Topological characterizations of our theoretical realizations of the contract network architecture. The cloud is a trusted third party, the consortium is facilitated by a blockchain system and the community is formed by a peer-to-peer network without global consensus or data replication.