Camila is a Contract Lifecycle Management (CLM) network for inter-firm process automation.

1) Install the Camila CLM CorDapp locally via Git:

git clone

2) Deploy the Nodes

cd camila-cordapp && gradlew.bat deployNodes (Windows) OR ./gradlew deployNodes (Linux)

3) Run the Nodes

cd workflows
cd build 
cd nodes
runnodes.bat (Windows) OR ./runnodes (Linux)

4) Run the Spring Boot Server

cd ..
cd ..
cd server
../gradlew.bat bootRun -x test (Windows) OR ../gradlew bootRun -x test

The Camila CLM Network API Swagger will be running at http://localhost:8080/swagger-ui.html#/ in your browser

To change the name of your organisation or any other parameters, edit the node.conf file and repeat the above steps.

Add the following to the node.conf file:


This is the current network map and doorman server URL for the DSOA Testnet

1) Remove Existing Network Parameters and Certificates

cd build
cd nodes
cd Dapps
rm -rf nodeInfo-* network-parameters certificates additional-node-infos

2) Download the Network Truststore

curl -o /var/tmp/network-truststore.jks

3) Initial Node Registration

java -jar corda.jar --initial-registration --network-root-truststore /var/tmp/network-truststore.jks --network-root-truststore-password trustpass

4) Start the Node

java -jar corda.jar

After the managed package click on Configure next to the installed Managed Package.

Go to the search bar on the left and click on Installed Packages. Next to the DSOA installed package select Configure.

and then just click Connect to DSOA at the bottom and you will be redirected to Authenticate with a Connected App page.

  • Corda version: Corda 4
  • Vault SQL Database: PostgreSQL
  • Cloud Service Provider: GCP
  • JVM or Kubernetes (Docker)

So far, we get:

  • Connected to the DSOA Network Map
  • Spring Boot Webserver
  • Braid Websocket for Events
  • Encrypted Middleware and API
  • Corda Node for your Organization

The enterprise software industry of cloud applications has created efficiencies but lacks a networked layered of verifiable integrity for agreements, assets and the financial elements of active contracts between stakeholders. The Distributed System of Agreement (DSOA) is a new platform for companies to interact in unison leading to verifiable verticalization.

The next generation of b2b enterprise computing has arrived and is based on a substrate where companies are operating in unison with verifiable, replicated processes and data to yield top line growth. The DSOA is a blockchain platform that is on a mission is to serve as the interface into the enterprise-grade business networks for the world. There will be a collective oneness for all businesses where data is owned by the customer, processes are distributed amongst a network of peers and nodes in the network at scale. This is the natural progression of computing where the enterprise now can ensure the integrity of their data and replicate the processes amongst multiple partners in a vertical.

Nodes on the network can instantly communicate with other nodes on the network in real-time on a global transaction ledger. All the business information that is called on by Smart Contracts will be the same across every node in the network and run in a trusted executable environment to create a secure encrypted ledger.

Now that you are connected to you can start sending agreements and assets with other organizations that are part of the network.

The purpose of this Business Network is for companies to come to a shared set of historical facts related to sales and service agreements.

If a business network is a group of independent parties transacting together, then its purpose is to allow its members to create a shared representation of information, or facts, and to then use shared processing of those facts to achieve agreement, or consensus, about operations involving them.

This ability to enable both shared understanding of facts, and shared understanding about how they are to be used is something uniquely powerful within DLT/blockchain systems. Earlier systems focused on the shared representations of information, but could neither consistently guarantee its correctness, nor ensure that all participants processed things in the same way. The Corda promise is that “I know I see what you see” after each operation between involved parties.

Achieving the Corda promise requires shared business logic, which for Corda is reflected in the design and development of CorDapps (Corda Distributed Applications) that are shared among parties engaged in the same business processing. The paramount shift to developing shared business logic in CorDapps not only improves the correctness of the shared data, but also eliminates the expensive and error-prone approach of interacting parties implementing their own interpretation of required business logic. Ultimately, this shared business logic, the CorDapps, form the basis of a business network.

The model of Corda business networks also enables something particularly powerful. It allows for the possibility that one business network can build upon the work of another, and that others can then build on top of that.

However, while Corda enables business networks, it deliberately sets out to have few “opinions” about what they might be, or exactly how they should work. Instead, Corda attempts to define some mechanisms to allow for the construction of business networks, and leaves the rest rather open-ended. This flexibility means it is possible to build both very simple and very complex designs, but, as with most software, over-simplified designs often miss essential functionality, while over-complex ones are almost impossible to get right.


Asset Modelpermalink

There are many different types of assets that can be transacted on the Camila Network. The first model to be deployed on the network is the Agreement. The Agreement has the following structure:

// *********
// * Agreement State *
// *********

data class Agreement(val agreementNumber: String,
                     val agreementName: String,
                     val agreementStatus: AgreementStatus,
                     val agreementType: AgreementType,
                     val totalAgreementValue: Int,
                     val party: Party,
                     val counterparty: Party,
                     val agreementStartDate: Date,
                     val agreementEndDate: Date,
                     val active: Boolean,
                     val createdAt: Instant,
                     val lastUpdated: Instant,
                     override val linearId: UniqueIdentifier = UniqueIdentifier()) 

The Agreement has the following business flows that can be called:

  • CreateAgreement - Create an Agreement between your organization and a known counterparty on the DSOA
  • ActivateAgreement - Activate the Agreement between your organization and a counterparty on the DSOA
  • TerminateAgreement - Terminate an existing or active agreement
  • RenewAgreement - Renew an existing agreement that is or is about to expire
  • ExpireAgreement - Expire a currently active agreement between you and a counterparty

The Agreement Status and Agreement Type enums are listed as follows:

enum class AgreementStatus {

enum class AgreementType {

The Junction State of the Agreement and the Line Item is the Agreement Line Item.

In order to cope with the increased complexity that multiple state types introduce, we can use the concepts of high cohesion and low coupling.

The Agreement and the Agreement Line Item are bounded together by Command to that the creation of the states via a transaction occure simultaneously as well as a StateRef in the child state property.

The Agreement Line Item state is as follows:

// ****************************
// * Agreement Line Item State *
// ****************************

data class AgreementLineItem (val agreement: Agreement,
                              val agreementNumber: String,
                              val agreementLineItemName: String,
                              val agreementLineItemStatus: AgreementLineItemStatus,
                              val agreementLineItemValue: Int,
                              val party: Party,
                              val counterparty: Party,
                              val lineItem: LineItem,
                              val active: Boolean,
                              val createdAt: String,
                              val lastUpdated: String,
                              override val linearId: UniqueIdentifier = UniqueIdentifier()) : LinearState, ContractState {

    override val participants: List<AbstractParty> get() = listOf(party, counterparty)

// ****************************
// * Message State *
// ****************************

    data class Message(val messageId: UniqueIdentifier,
                       val message: String,
                       val to: AbstractParty,
                       val from: AbstractParty,
                       val sentReceipt: Boolean?,
                       val deliveredReceipt: Boolean?,
                       val fromMe: Boolean?,
                       val time: Instant?,
                       override val participants: List<AbstractParty> = listOf(to, from)) : ContractState

Go to the Network Map tab and you can see other organizations that are part of the network.

The interface will populate with known legal entities that are part of the network.


Identity is managed for individual users leveraging Hyperledger Indy Credentialing.

Note: This is the first iteration of the DSOA Network and the following roles are subject to change for future networks.


Asset Issuerpermalink



Oracle services are provided natively by the Corda Protocol Chainlink and by Oraclize. The Oraclize service can be called at the beginning of a flow to get validation data from a trusted source.

DSOA Notarypermalink

Dapps Inc. is the BNG for the DSOA Network.

It is critically important that a commercial entity should not control Corda Network going forwards, and that it should be governed transparently, with a fair and representative structure that can deliver a stable operating environment for its members in the long term.

A separate entity called DSOA Network Foundation has been set up, using a not-for-profit legal entity type known as a Stichting, residing in the Netherlands. This type is suited for governance activities, able to act commercially, with limited liability but no shareholders, capital or dividends. Its constitution is defined in a set of Articles of Association and By-laws.

A Foundation enables Network participants to be involved with, and also understand, how decisions are made (including around issues of identity and permission), building trust and engagement from a wide range of stakeholders. We believe this will bring about the best decisions and outcomes for the Network’s long-term success.

Its governance bodies shall include:

  • A Governing Board (‘the Board’) of 11 representatives (‘Directors’).
  • A Technical Advisory Committee (‘the TAC’), comprised of representatives of Participant organisations.
  • A Governance Advisory Committee, comprised of representatives of Participant organisations.
  • A Network Operator (‘the Operator’), charging the Foundation reasonable costs for providing network and administration services, paid by the Foundation through membership funds, and accountable directly to the Board. Operating on behalf of:

Participants (‘Participants’), open to any legal entity participating in Corda Network, and independent of R3 alliance membership.

Nodes are up with 99.999% up time once deployed in the DSOA.

Dapps Inc. is the BNO for the DSOA.

The set of services provided by a business network operator node vary by application. The following sections discuss typical services that may be required:

In addition to the assignment of a base identity to a Corda node that ensures each node across all business networks have a unique identity, each business network performs its own deeper membership management process, e.g., registration, licensing, and KYC/AML checks. While the exact requirements for each business network are governed by the network policies, the process of allowing nodes to join and transact on a network will be performed by the BNO node.

A certificate will be provided to non-natural persons, i.e. organisations that are an incorporated legal entity. The following information should be provided by all Participants seeking access to Corda Network:

  • Entity name
  • Entity Address
  • Contact Name
  • Contact Email Address
  • Contact Phone Number
  • Unique ID – (GLEIF ID, EIN, CRN, etc.)
  • Website Domain (Optional)

Note: additional details may be required for Participation billing, but these requirements do not form part of this Policy.

The Operator must conduct a sanction review commensurate with jurisdictional laws and regulations on all entities and establish a process to clear false positives. Positive matches will not receive a certificate for the network. Business Network Operators must perform their own KYC check and should not rely on the Operator’s identification or sanction review. Business Network Operators are responsible for obtaining further documentation such as articles of incorporation, ultimate beneficial owners, etc. to verify identity and conduct appropriate due diligence checks (high risk industry analysis, high risk geographies, negative news checks) to ensure entities meet acceptable risk tolerance standards designed by the business network.

Certifications will be issued based on the information provided in the certification request. Any changes to information provided, including updating the entity name or contact information, will require a certification to be revoked and subsequently re-issued by the operator.


A common requirement for business networks is the need to maintain a set of shared master data that pertains to the application domain and made available to all business network participating nodes. This data may be served via an API, messaging system, or stored on-ledger, and governed by one more contracts.


Depending on the network policies, certain activities such as vault synchronisations or upgrades may require authorisation from the business network operator node.

For commercial, operational or regulatory reasons it is often a requirement to monitor and/or report on network level metrics. For example, an operator may want to monitor network health by tracking operational metrics such transaction volumes and latency. It may also choose to bill its members (periodically or on-demand) by tracking transactions across the network. The network may be designed to reveal as much or as little about the transactions as appropriate.

Certain network level events such as planned maintenance, outages and upgrades must be communicated to all network users. In many cases, traditional communications channels may suffice but in some cases it may be appropriate to use a BNO service to distribute such information such that it can be integrated into the application itself.

Although distribution of CorDapp jars and other shared dependencies may be managed via traditional deployment software tools, it may be appropriate to integrate this into the network itself.


This is the policy for the deployment of software components by the Operator onto physical infrastructure for the DSOA Network.

Wherever possible, deployment procedures shall be executed via an automation tool or combination of tools. The Operations team is responsible for selecting an appropriate tool, or combination of tools, for each element of a deployment procedure requiring automation. The default preferred tools for each activity are listed below; these should be used for all deployment procedures in the absence of technical obstacles.

The Operations team may, at its discretion, select an alternative tool to perform a given task where the default tool is determined to be unfit for purpose. The rationale for using alternative tooling should be documented within the associated deployment procedure(s).

  • Overall deployment operation: Ansible
  • Code build & packaging: Gradle
  • Cloud infrastructure provisioning: Terraform

The Operations team is responsible for ensuring that all tools used in deployment procedures are themselves updated, and that the testing of the deployment process traps for any version compatibility issues between deployment tools and the software being deployed.

The network commercial model is to charge on a per month basis for access to the network.

The operating costs factor are related to the opeating costs associated with running the nodes in JVMs in addition to paying developers for the ongoing improvement of the network.

The network is for profit and members will be charged by Dapps Inc to transact agreements across the network.

Associated costs for ongoing maintenance of the network as well as additional services will be available for purchase.


Data Privacypermalink

All data is encrypted at rest and owned by the customer in their own secure environment.

Governing law is local to the users jusrisdiction.


GDPR is enforced on the DSOA. The following are key definitions as they pertain to the DSOA.

  • Personal Data: means any information relating to an identified or identifiable natural person (‘data subject’). In turn, an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, address, an identification number (such as a passport or a social security number), location data, telephone number, an online identifier or log in details or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person. First Name and Last Name can be personal data if linked to other data (or otherwise independently if they are not common names).
  • Data Controller: “‌controller” means the natural or legal person, public authority, agency or other body (each, a “person”) which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law.
  • Data Processor: any person (other than an employee of the data controller) who processes the data on behalf of the data controller.
  • Processing, in relation to information or data means obtaining, recording or holding the information or data or carrying out any operation or set of operations on the information or data, including:
  • organization, adaptation or alteration of the information or data,
  • retrieval, consultation or use of the information or data,
  • disclosure of the information or data by transmission, dissemination or otherwise making available or
  • alignment, combination, blocking, erasure or destruction of the information or data.


Customer data is to be owned by the customer and managed by members of the DSOA.

The need to prune data on the network map arise over time. Therefore it is imperative that members of the DSOA establish rules for their organziation and policies to ensure efficient keeping of state.

Data Securitypermalink

The Foundation will implement an information security management program with three main components:

  • An information risk management program which will identify, assess and prioritise information security risks to the business. The program will produce an information risk register together with proposed activities to control the risks identified. Those activities will be assessed and prioritised in the light of the impact and likelihood of the risks they address, combined with cost of the control activities themselves. The output of this process will be a prioritised program of activities to establish and maintain a security posture that is aligned to the Foundation’s business objectives and attitude to risk.
  • An information security management capability that delivers the program of work defined by the information risk management program and carries out other major, or highimpact, security projects. The information security management capability will oversee the design and implementation of an information security management system (ISMS) for the Foundation. The ISMS will define such policies, procedures, standards and guidelines as are necessary to maintain the Foundation’s desired security posture.
  • A security operations capability, that monitors and maintains the Foundation’s security posture, provides a security incident response capability and executes smaller projects of limited impact. The security operations capability will operate the information security management system.


Before actively participaing in the DSOA Network, Dapps Inc. will provide the customer with the following Terms of Service for all of the Network Services it provides. At a minimum, Terms of Service shall include clear, explicit statements to cover the following:

  • Identification of Service Operator including relevant contact information, trade registry reference number, legal status and regulated status.
  • Description of the Network Service offered, including technical detail where relevant to its access and operation.
  • Conditions of service, which may include:
  • Any requirements for the User to enter into prior agreements with the Service Operator
  • Applicable hours of operation
  • Specific conditions under which service may be withheld (e.g. legal, regulatory constraints etc.)
  • Data restrictions: Data which Users are prohibited from sending to the Network Service
  • Commitments to deliver a specific level of performance, specifying relevant metrics (e.g. throughput, latency etc.), and how they are measured
  • Commitments to ensure a specific level of availability (uptime) including provisions for planned and unplanned outages
  • Charges due to the Service Operator in relation to the Network Service, and how these are to be paid
  • Acceptance of liability for improper service
  • Dispute resolution procedures, including means to contact the Service Operator
  • Compensation scheme(s) applicable in the event of financial losses by a User due to improper service, and procedures for accessing scheme(s)
  • Disclosures arrangements (see 2.6)
  • Data handling: Treatment and arrangements for secure management of data provided to the Network Service by Users
  • Data retention: Policy on the retention and deletion of data provided to the Network Service by Users
  • Geographical location of all resources (databases, servers etc.) making up the Network Service, naming specific countries in which resources may reside. Where resources are distributed over more than one country, the division of resources across countries shall be unambiguously described.
  • Governing law: Which set(s) of legislation shall be considered to govern the Terms of Service
  • Process for changes to the Terms of Service, including notice given to Participants and notification procedures
  • Process for termination of the Network Service, including requirements for advance notice and migration, where relevant Where any of the above do not apply to a Network Service, the Terms of Service shall include explicit statements to this effect.


Please reach out to