<br> <br> <h1 style="text-align: center; display: block;">Decombine Smart Legal Contract Whitepaper (DRAFT)</h1> <h3 style="text-align: center; display: block;">February 11, 2025</h1> <p style="text-align: center; display: block;">Timothy Tavarez <br> [email protected] <br>Founder, CEO - Decombine</p> <div style="page-break-after: always;"></div> ## Introduction --- The Decombine Smart Legal Contract (SLC) is a software solution and specification to perform programmatic contractual execution in a standardized, templated, and declarative way. Decombine SLC are not a replacement for natural language contracts, but instead, a means to augment conventional contracts. A conventional contract may dictate thousands of varying requirements, conditions, and actions. A Decombine SLC can be used to translate these into a software package that supports mathematical verification, flexible deployment strategies, and infinitely customizable scenarios. The Decombine SLC was invented to offer an accessible, transparent, and cloud-native way for parties to form an agreement. A SLC ensures transparency about *what* will happen and *when*. In contrast to conventional agreements where a digitized contract may be created and then all other processes are separate, an SLC instead integrates contract-related processes into an end-to-end workflow.  For example, a conventional agreement may dictate that two parties must each provide a document during the execution of their contract, such as proof of insurance. Rather than this requirement taking place manually, an SLC may have a step configuring a document storage service and then requiring specific documents to be present before progressing to the next stage. Decombine SLC are not appropriate for every use case. Their utility is most applicable in situations where contractual execution can follow well known, understood, and repeatable processes. A one-off, custom tailored contract is unlikely to be a fit. On the other hand, if that custom contract were to require rigorous and repeatable procedures, such as credit checks, background checks, or payments, SLC could be appropriate to be included. A Decombine SLC is defined using vendor-agnostic, industry-standard formats for configuration and data exchange (JSON, YAML, TOML) that enable the contract to templated and re-used. The configuration constructs a mathematical model of computation known as a state machine. The contract can only ever be in a single state, and it transitions between states based on events and conditions. As an example, an SLC involving an Non-Disclosure Agreement may only have four states: Unsigned, Incomplete, Signed, and Expired. ```mermaid stateDiagram-v2 direction LR state Unsigned state Incomplete state Signed state Expired [*] --> Unsigned Unsigned --> Incomplete: First signature Incomplete --> Signed: All signatures complete Incomplete --> Expired: Expiration date reached Signed --> Expired: Expiration date reached Expired --> [*] ``` Each state is defined using a simple set of criteria and can include software to run when the state is entered or exited. The software could be simple, such as triggering email notifications, or complex, such as running applications and infrastructure. ```json "state": { "initial": "Draft", "uri": "https://github.com/decombine/nda", "states": [ { "name": "Draft", "entry": { "containers": [ { "type": "ContainerAction", "image": "ghcr.io/fellowship/eidas-signature-portal", ... ``` ## State of the art today in agreement --- **Formation** The vast majority of existing agreement today is codified through contractual language on physical paper, static web pages, software applications, and/or documents such as Microsoft Word or PDF. The state of the art for repeatable and reproducible agreement is broadly considered to be digitized documents in Microsoft Word or PDF format. A workflow may produce a PDF as a record, or a singular PDF may be re-used in a multi-step process to record signatures. Different industries, regulatory bodies, and national/international organizations may provide boilerplate templates that can be used as starting points, **Execution** Arguably, there does not exist a state of the art for agreement execution. There is known scientific method or widely understood technical procedures in use. The most convincing case to be made is around blockchain smart contracts, which are capable of a wide array of capabilities, and have demonstrated utility for automated peer-to-peer financial transactions. ### Challenges with the state of the art A conventional digital contract is typically recorded history. The record can be used for reference and litigation. Regardless of the way an agreement is recorded as a contract, whether as a Word document, PDF, or stone tablet, none are capable of providing clarity as to the *state* of the agreement during execution. A Word document can no more prove to you a requirement has been met than the stone tablet. For some stakeholders, a historical record is sufficient, where the intent of the contract is to be archived. For other stakeholders, a contract has very real impacts on their lives or organizations, and understanding the practical effects of what happens when they are formed is far more valuable than a record alone. The average person or even organization is unlikely to spend inordinate amounts of time deciphering legal language. Far more importantly, they are unlikely to have any means to verify that what has been committed to in an agreement is actually being executed *as agreed*. This is the root challenge that Decombine SLC seek to address. ## Decombine Smart Legal Contracts --- Decombine SLC are not a replacement for conventional natural language contracts. They do not offer any solution for reaching or forming an agreement, and they do not prescribe any contractual language or legal advice. SLC may however contain, relate, or refer to conventional natural language contracts. Decombine SLC are intended to provide: - Safer, predictable, and lower cost execution of agreements - Increased transparency and understanding throughout the lifecycle of contract execution - Greater accessibility to complex solutions by integrating with industry-leading open source ### Declarative Decombine SLC are declarative in both design and implementation. The contract author defines the SLC in a series of states that correspond with software payloads and policies that execute and change based on state. States are declared in a template configuration using a standardized configuration or interchange format (e.g., JSON, YAML, TOML) that adheres to a rigorous schema. Declarative design, rather than imperative, has become de facto best practice in numerous domains of software engineering. Practices using this such as Infrastructure as Code (IaC) and containerization are now considered integral to operating at any scale, precisely because they are reliable, repeatable, and standardized. ### Reactive  Decombine SLC are event-driven, enabling them to be reactive. The state defined by the SLC is changed on specific events that the SLC runtime can be configured to listen for. Events are configured using the open source [CloudEvents](https://cloudevents.io/) specification, a [Cloud Native Computing Foundation](https://www.cncf.io/) (CNCF) project. ### Traceable Decombine SLC are composed through templates which are pulled from a source control system (e.g., Git) and inherit all of the traceability advantages that come with that. SLC embrace a practice known as "GitOps", where a source control system serves as the source of truth for a desired state configuration. The system running the SLC, known as a controller, is kept synchronized with a source control system to ensure it has an exact copy and workload, independent of external action. It is a "pull" model, rather than a "push", which greatly increases traceability. ### Verifiable The entirety of a SLC is computationally verifiable from individual building components to the whole. The SLC templates are composed into a Unified Modeling Language (UML) State Machine which can be used to validate correctness and communicate in a standardized way the state of a contract. A mathematically supported verification process can support new use cases being built directly into contractual logic, taking actions and processes that might have previously been manual and moving them into automated procedures. ### Use Cases Decombine Smart Legal Contracts (SLC) deliver the greatest impact in a set of specific use cases around transparency and capability, and especially when they are combined. ### Transparency Since the SLC is at its core a series of validated templates that trigger software, it is much easier to be able to understand the actual series of events occurring in an agreement. Even a non-technical user with minimal familiarity to the templates can open a SLC configuration and likely determine what is happening and when. ### Zero Trust contracts and processes Conventional contractual execution is largely good faith-based. Two parties agree to something and they must trust that the other will meet their obligations as agreed. If they do not, perhaps this is discovered, or perhaps not. Execution in SLC is intended to be zero trust. Zero trust is a set of practices and principles where every interaction begins in an untrusted state. This is facilitated in an SLC by ensuring that the transitions between different states in a contract (e.g., Incomplete -> Complete) are triggered by specific events and conditions. If these events and conditions are not met, the state cannot change. Users of an SLC can put in place policies, workloads, and conditions that ensure the progression of contractual execution is grounded in objective truth, rather than good faith. **Conventional Execution scenario:** A software vendor provides Software as a Service (SaaS) to a customer that is integrated into the customers platform. The customer requires that the software vendor only collect specific, authorized data relevant to their purpose and use specific security practices regarding data collection. The customer in this scenario must rely on good faith that the vendor will only collect what is required or necessary for functionality and adhere to specific security practices. They are reliant on assurances. In the event of negligence or bad faith practices, the customer must bear the consequences. **SLC Execution Scenario:** A software vendor provides Software as a Service (SaaS) to a customer that is integrated into the customers platform. The vendor and customer agree to use a standard SLC to host the integration. The SLC includes a Open Policy Agent (OPA) system that only allows specific data to be queried in specific ways and blocks all other requests. The customer in this scenario has a technical control that enforces their requirements. In the event of negligence or bad faith, the customer has a technical control to limit impact. ### Capability Since the SLC is (*again*) at its core a series of validated templates that trigger software, they are simple to produce. Containerization of software has led to dramatic shifts in how software can be distributed and run. Configuring and deploying software of high complexity that may have taken months or years of manual effort can now be replicated with drastically less labor and computational resources to only run as needed. ### Increased accessibility to complex interactions SLC can be used to package highly complex systems building on existing intellectual property that can provide services such as durable file storage, encrypted chat, real time location sharing, machine learning model APIs, and more. The SLC only needs to be templated once and it can be re-used by anyone with access to the source code. Combining this capability with a conventional legal agreement between parties can introduce entirely new use cases and business models that prior to SLC would not have been viable. **SLC Execution Scenario:** An entrepreneurial individual decides to start a new service offering ride sharing in their country. They collaborate with others to create a SLC that starts a web service with a payment gateway and the ability for users to sign up quickly and easily. They position themselves as a trusted solution by providing contract-backed guarantees and implementing policies in the SLC that limit or even prevent their ability to access any user data other than what is required.