Dappsuite is the Blockchain Platform as a Service (BPaaS) built on Ethereum and Salesforce. Dappsuite allows for Salesforce customers to make Ethereum payments and to create smart contracts that are automatically executed, linked to existing customer data and other implemented business processes. The financial elements of the smart contracts are deterministic and transactions such as payments are auto executing based on oracle data feeds.

Install it:

Go to Dappsuite on the Salesforce AppExchange or install the managed package using SFDX and the steps below.

    sfdx force:package:install --package 04t1K000002N1fmAAA

The managed package can also be installed directly here: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t1K000002N1fm

Contact connect@dapps-inc.com for the Dappsuite Managed Package password.

After the managed package has downloaded go to the rop right corner and switch to Salesforce Classic.

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

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

So far, we get:

• Connected to the Ropsten Ethereum Network
• Encrypted Middleware and API between Salesforce and Ethereum
• Ethereum Blockchain Node Provider

To spin up your own encrypted middleware and API between Salesforce and Ethereum, clone this repo:

    git clone https://github.com/dappsinc/dappsuite-middleware

You will need to install the managed package, create a net new connected app and enter in your org and client credentials, and create a SQL database for managing Key Pair; and set all as config VARS. This can be done via Heroku as well.

PR's are welcome on the dappsuite-middleware, reach out to connect@dapps-inc.com for more information.

Ethereum is the foundation for a new era of the internet:

• An internet where money and payments are built in.
• An internet where users can own their data, and your apps don’t spy and steal from you.
• An internet where everyone has access to an open financial system.
• An internet built on neutral, open-access infrastructure, controlled by no company or person.

The EVM is stack-based execution environment that uses Smart Contracts (similar to object-oriented classes) and HTML, CSS, and JavaScript to create dapps. When you are running a decentralized application (dapp), every instruction is executed on every node of the network.

Contracts in Solidity are similar to classes in object-oriented languages. Each contract can contain declarations of:

• State Variables
• Functions
• Function Modifiers
• Events
• Structs Types
• Enum Types

with Parameters of:

• The gas-price I want to pay (gasPrice).
• The maximum amount of gas that may be spent (gas).
• The amount of ether I want to transfer (value).
• My account address (from).
• The target account address (to).
• The nonce (nonce).
• The transaction data (data).

A smart contract’s code resides in a Contract Account.

1. Install Dappsuite and Connect to the Dappsuite Network from Salesforce Classic (Installed directly to your Salesforce Org here: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t1K000002N1fm password: d@pps123)
2. OAuth with the Connected App now you can create an Account, Compile Contracts, Create Tokens and Transfer Tokens back in Lightning Experience
3. From the Solidity Compiler Page you can leverage the NetworkToken.sol Smart Contract below (use compiler version 0.4.8)
4. Save the Contract in the Library and you can go to the Dapps Dashboard and create an Account
5. Set your password, confirm your password and the Account will be created. You can send some Ropsten ETH to it using this faucet https://faucet.ropsten.be/
6. You can check the balance of your Ethereum Account on the Ethereum Account Manager Page, once the balance is at 1.5 ETH you can deploy your smart contract
7. Go to the Smart Contract Interface and Deploy the Network Token with whatever parameters you would like.
8. Once the Smart Contract is deployed you can use the Token Transfer Interface or the Dappsuite Wallet to transfer the tokens to other Ropsten Ethereum Addresses. To add the Dappsuite Wallet go to Salesforce Navigation and add it to the Mobile Navigation Menu on the right.
9. You can create a New Address by clicking the Address Object and you can add that to a Salesforce Contact as a child object.
10. Lastly if you go to Dappsuite Wallet on your Salesforce Mobile App you can transfer your Token to your Contact, sign it using your Ethereum Account and Password, and Check it on Etherscan.

Now that you are connected to dappsuite.network you can start writing and deploying Smart Contracts. Go to the Solidity Compiler back in the Lightning Expirience interface.

Here is a sample Smart Contract for an ERC-20 Token that can be used in the compiler.

pragma solidity ^0.4.24;/**
* This file has 2 contracts: tokenRecipient and MyToken
* and is reproduced directly from https://www.ethereum.org/token
*/
contract tokenRecipient { 
function receiveApproval(address _from, uint256 _value, address _token, bytes _extraData); 
}

contract NetworkToken { 
/* Public variables of the token */
string public name;
string public symbol;
string public version;
uint8 public decimals;
uint256 public totalSupply;

/* This creates an array with all balances */
mapping (address => uint256) public balanceOf;
mapping (address => mapping (address => uint256)) public allowance;
mapping (address => mapping (address => uint256)) public spentAllowance;

/* This generates a public event on the blockchain that will notify clients */
event Transfer(address indexed from, address indexed to, uint256 value);

/* Initializes contract with initial token supply to the creator of the contract */
function NetworkToken(
uint256 initialSupply, 
string tokenName, 
uint8 decimalUnits, 
string tokenSymbol, 
string versionOfTheCode
) {
balanceOf[msg.sender] = initialSupply; // Give the creator all initial tokens 
totalSupply = initialSupply; // Update total supply
name = tokenName; // Set the name for display purposes 
symbol = tokenSymbol; // Set the symbol for display purposes 
decimals = decimalUnits; // Amount of decimals for display purposes 
version = versionOfTheCode;
}

/* Send coins */
function transfer(address _to, uint256 _value) {
if (balanceOf[msg.sender] < _value) throw; // Check if the sender has enough 
if (balanceOf[_to] + _value < balanceOf[_to]) throw; // Check for overflows
balanceOf[msg.sender] -= _value; // Subtract from the sender
balanceOf[_to] += _value; // Add the same to the recipient 
Transfer(msg.sender, _to, _value); // Notify anyone listening that this transfer took place
}

/* Allow another contract to spend some points in your behalf */
function approveAndCall(address _spender, uint256 _value, bytes _extraData) 
returns (bool success) {
allowance[msg.sender][_spender] = _value; 
tokenRecipient spender = tokenRecipient(_spender);
spender.receiveApproval(msg.sender, _value, this, _extraData); 
return true; 
}

/* A contract attempts to get the points */
function transferFrom(address _from, address _to, uint256 _value) returns (bool success) {
if (balanceOf[_from] < _value) throw; // Check if the sender has enough 
if (balanceOf[_to] + _value < balanceOf[_to]) throw; // Check for overflows
if (spentAllowance[_from][msg.sender] + _value > allowance[_from][msg.sender]) throw; // Check allowance
balanceOf[_from] -= _value; // Subtract from the sender
balanceOf[_to] += _value; // Add the same to the recipient 
spentAllowance[_from][msg.sender] += _value;
Transfer(_from, _to, _value); 
return true;
} 

/* This unnamed function is called whenever someone tries to send ether to it */
function () {
throw; // Prevents accidental sending of ether
} 
}

Copy and paste the Smart Contract into the Solidity Source Code and Select Solidity Version: pragma solidity ^0.4.24;/**

Click Compile and once it is complete, select the Save button to save your Smart Contract to the Library.

We created the Dapps Dashboard to provide the ability to create Ethereum Accounts.

Enter in the Account Name.

Then set a Password and confirm the password.

Lastly, click the create Account button.

You can see all of the ethereum accounts you have created on the Ethereum Account Manager Page.

You can also use the web3 api to create ethereum accounts using the steps below and import the account into Dappsuite.

npm install web3 –save

var Web3 = require(“web3”)

var web3 = new Web3(new Web3.providers.HttpProvider(http://eth.dapps.network:8545))

web3.eth.accounts

web3.eth.accounts[0]

web3.eth.getBalance(web3.eth.accounts[0])

)

Please see the web3 ethereum documentation for more examples.

To import an account use the Ethreum Account Manager page. You can import by private key or wallet file.

To export an account use the Ethereum Account Manager page.

Go to the Smart Contract Interface and select a Smart Contract in the Library lookup field.

The interface will populate with Input variables for the Smart Contract you selected based on the ABI (Application Binary Interface)

dappsuite deploy --name erc20.sol 

Note: The Smart Contract Interface can be called from Salesforce Lightning or from the SFDX command line interface

We use a Transaction Signer modal in order to sign messages and deploy smart contracts to the network.

Select the Account that you would like to use to deploy the Smart Contract.

Enter in the Password of the Account and click Sign.

Once the smart contract has been deployed, the functions for the contract will appear in the Smart Contract interface.

Notice that to load data when the page loads, we have call methods which are static methods. It can asynchronously fetch the latest state from the blockchain.

Data returned from the Blockchain is also persisted in various objects such as Smart Contract, Transactions, Tokens and Token Transfers.

Note: Contract Address is specified and existing contracts can be loaded into the interface.

Go to the Token Transfer Interface page and select the Token you want to send.

Next, enter in the Ethereum Address of whom you want to send the funds to.

Lastly, enter the Amount of number of tokens you want to send.

Click the Send Button and sign the Transaction using the Transaction Modal.

In the Custom Settings you have the option of deploying to the Oasis Dev Network.

Oasis provides privacy computation for smart contracts and is backwards compatible with the Ethereum Network.

• RPC URL | https://web3.oasiscloud.io
• ChainID | 42261
• Symbol | DEV
• Nickname | Oasis Devnet

You can develop a confidential smart contract in much the same way as you would develop a non-confidential smart contract, with a few important differences. When deployed confidentially, all of the contract's internal state remains encrypted for its lifetime, being decryptable only by the smart contract when running in a secure environment.

Note: In Ethereum and other platforms without confidentiality, the private modifier states that the value should not be accessible through transactions. This does not provide confidentiality. The value of the field is still stored in plaintext on the blockchain, allowing any node/worker to easily read it.

Here is a sample Confidential Smart Contract for a Secret Ballot that can be used in the Solidity Compiler.

pragma solidity ^0.4.18;

contract SecretBallot {
    // The address of the account that created this ballot.
    address public ballotCreator;

    // Is voting finished? The ballot creator determines when to set this flag.
    bool public votingEnded;

    // Candidate names
    bytes32[] public candidateNames;

    // Keep track of which addresses have voted already to prevent multiple votes.
    mapping (address => bool) public hasVoted;

    // Tallies for each candidate
    mapping (bytes32 => uint256) private votesReceived;

    // The total number of votes cast so far. Revealed before voting has ended.
    uint256 public totalVotes;

    constructor(bytes32[] _candidateNames) public {
        ballotCreator = msg.sender;
        candidateNames = _candidateNames;
    }

    function voteForCandidate(bytes32 candidate) public {
        // can only vote during voting period
        require(!votingEnded);
        // candidate must be part of the ballot
        require(validCandidate(candidate));
        // one vote per address (not sybil resistant)
        require(!hasVoted[msg.sender]);
        // prevent overflow
        require(votesReceived[candidate] < ~uint256(0));
        require(totalVotes < ~uint256(0));

        votesReceived[candidate] += 1;
        hasVoted[msg.sender] = true;
        totalVotes += 1;
    }

    function endVoting() public returns (bool) {
        require(msg.sender == ballotCreator);  // Only ballot creator can end the vote.
        votingEnded = true;
        return true;
    }

    function totalVotesFor(bytes32 candidate) view public returns (uint256) {
        require(validCandidate(candidate));
        require(votingEnded);  // Don't reveal votes until voting has ended
        return votesReceived[candidate];
    }

    function numCandidates() view public returns(uint count) {
        return candidateNames.length;
    }

    function validCandidate(bytes32 candidate) view public returns (bool) {
        for(uint i = 0; i < candidateNames.length; i++) {
            if (candidateNames[i] == candidate) {
                return true;
            }
        }
        return false;
    }
}

DappScape is a blockchain application that enables Salesforce customers to leverage the power of blockchain to build trusted business apps, fast. With DappScape you can iterate quickly to build and deploy blockchain business networks without the complexity of managing and maintaining them. All of the infrastructure and workflows needed to run and scale your Blockchain app are managed for you so that you connect with key stakeholders and business partners.

DappScape provides an Enterprise Blockchain Interface, a REST API Gateway, and Blockchain Network Infrastructure to drive trusted data and process unification across your business. You can easily integrate Dapps into your Salesforce workflows or other 3rd party applications to transform the customer experience. You can provide a single lense of the customer by using Dapps’ OOTB solution for Hyperledger. DappScape gives enhanced visibility for the entire value chain enabling them to operate on a single source of truth across multiple Salesforce organizations.

Here is a link to the Dappscape REST Server: https://dappscape.com:3000

The Dappscape Managed Package allows you to connect to your own business networks.

Install it:

Go to Dappscape on the Salesforce AppExchange or install the managed package using SFDX and the steps below.

    sfdx force:package:install --package 04t41000002z74bAAA

Hyperledger Fabric is a distributed consensus transactional state machine. It is Blockchain Infrastructure and a permissioned protocol. Hyperledger is a permissioned transactional database; it takes an ordered series of messages that are both valid and invalid and distributes states to the nodes on the network. It ensures that by hashing the previous block of messages and attaching that to the header of the new block that the transactional ledger is immutable. The Hyperledger Infrastructure runs in a Virtual Machine that is operated by Dapps. We run the latest Fabric docker images in a virtual machine with 500GB of Memory. We use a C3 Large EC2 Instance on AWS or we can integrate with your existing business network on the IBM Blockchain platform. Hyperledger Business Networks can be thought of as two layers; the application layer (Composer) and the infrastructure layer (Fabric).

To model the business network use the CTO modeling language and javascript. When finished designing you network, deploy you composer application. When you have launched the application you can then manually send transactions to the network using the Salesforce Lightning Experience. How can we completely integrate the Hyperledger data and the Salesforce data while running a multi tenant node server and ordering service in VM? This will be an entire new ecosystem based on event driven applications and the infrastructure will be run by users of the many different technology stacks and Salesforce organizations. Hyperledger enables enterprise companies to build applications that are permissioned, scalable and an abstraction layer above to the transactional infrastructure; across a number of verticals and Salesforce organizations. Dapps enables companies that run their business on the Salesforce platform to leverage this blockchain infrastructure, abstraction layer; and combine it with their existing customer data, event driven workflows, and other third party applications. Again, the goal is to build an object model and an interface that enables Salesforce Customers to quickly build and deploy Business Networks that are tightly integrated with their existing customer data, third party applications and other proprietary business processes. We handle the underlying infrastructure level so that companies can focus on modeling the participants, assets, and transaction logic. When deploying state changes to the network these changes are updated across every peers state. The data is also persisted and virtualized in Salesforce using Dapps External Objects and Data Sources.

After the managed package has downloaded go to the rop right corner and switch to Salesforce Classic.

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

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

So far, we get:

• Connected to a Hyperledger Fabric Business Network
• Encrypted Middleware and API between Salesforce and Hyperledger API
• Hyperledger Blockchain Peer

The advantage of building distributed applications on the Salesforce platform is the event driven architecture that Salesforce and Fabric blockchain share. We can now connect distributed ledgers to various business process that are built on the Salesforce platform. Ideally we can build a type of asset transformation in that we take the asset as it stands today, a record in an Oracle database, simply allowing a system to see which as assets are owned; and we can now unlock the asset across an entire value chain. By enabling an asset to be digitized and to be used on a Blockchain Network such as Fabric; the state changes that happen for the asset on the ledger are propagated using the shared event system. By taking care of the various components at the infrastructure level, the application level; and ultimately connecting it to the enterprise platform layer that is Salesforce.

We need to create Platform Events that are subscribed to state changes at the emit event transactional level of the Fabric Composer REST service. We have developed the Salesforce integrations to business network models based on assets, participants and transaction logic. The development process is built into the Salesforce Lightning Experience. Testing and deploying these types of assets on the ledger (therefore emitting events) are virtualized in corresponding external objects in the Dapps managed package. Any state changes (CRUD) that happen are registered as Business Network Events and these events can be used in other business processes and applications.

Salesforce provides the platform event that we can link to the blockchain network. We call these Business Network Events and the object is Business_Network_Event__e. We use this type of object as a asynchronous messaging system from the blockchain network to Salesforce clients. This becomes a message broker and it comes with many advantages when distributing state or network status update. One message from the network can be sent to several recipients because it logically decouples the sender from the recipient (the send just published messages and doesn’t care who consumes them). This message broker can automatically delivered messages to a process that has crashed as well and thus prevent messages from being lost is a recipient is unavailable or overloaded.

This essentially means that the various participants in the business network can listen to the same event and carry out actions knowing that endorse and verifies by the peers in the network. The advantage to having a Business Network event driven architecture is that multiple participants that are on the network can subscribe from various clients and understand and receive asynchronous messages with regards to the current state of the network. We can then subscribe to these notifications inside of Salesforce and use the Platform Events Framework as an asynchronous processing system that can leverage distributed verifiable committed transactions and state changes from the shared ledger. Linking together Hyperledger Fabric Network Events and the Salesforce Event Streaming System not only for the infra level, but also the application level taking these two event systems and linking the together is powerful.

Events are defined in the business network model file and are emitted by specified transactions in the transaction processor function file. Before an application can subscribe to events, you must have defined some events and the transactions which will emit them. An application must send a specific API call to subscribe to events emitted transactions in a business network. Salesforce is the subscriber. Fabric-Composer is Publisher; to the Event Bus where Salesforce gets pinged. The application will now receive all of the events emitted by the business network, and it's up to the application to choose to what extent those events are integrated. We can then write after insert triggers or business processes on the Salesforce Platform that listen for events that are being published by the Hyperledger Blockchain Network. By connecting these two event systems we can enable companies to quickly develop and integrate blockchain applications that are driven by the Salesforce platform and the Hyperledger blockchain protocol.

The REST Server is used to Authenticate users by Salesforce Org and User Id to know exactly how many calls are being made and who is writing to the network. This has its advantages in that we can customize the solution but dynamic deployment will be dependent on an IDE that is tied to the Business Network Rest Server. Upon updating the Business Network the Rest Server will need to be upgraded and all participants will need to update their network. This is a Business Network Lifecycle Management application process which will need to be build upon.

The Hyperledger Architecture WG has distinguished the following business blockchain components:

• Consensus Layer – Responsible for generating an agreement on the order and confirming the correctness of the set of transactions that constitute a block.
• Smart Contract Layer – Responsible for processing transaction requests and determining if transactions are valid by executing business logic.
• Communication Layer – Responsible for peer-to-peer message transport between the nodes that participate in a shared ledger instance.
• Data Store Abstraction – Allows different data-stores to be used by other modules.
• Crypto Abstraction – Allows different crypto algorithms or modules to be swapped out without affecting other modules.
• Identity Services – Enables the establishment of a root of trust during setup of a blockchain instance, the enrollment and registration of identities or system entities during network operation, and the management of changes like drops, adds, and revocations. Also, provides authentication and authorization.
• Policy Services – Responsible for policy management of various policies specified in the system, such as the endorsement policy, consensus policy, or group management policy. It interfaces and depends on other modules to enforce the various policies.
• APIs – Enables clients and applications to interface to blockchains.
• Interoperation – Supports the interoperation between different blockchain instances.

Corda is a global network of nodes for enterprise-grade, real-time transactions and asset workflows. It is a platform for developing the next-generation of enterprise software where state and processes can be shared and uniform across multiple trusted entities leading to operational efficiency, speed and better customer experiences. What does the Business-to-Business enterprise space look like when there is a real-time network for shared processes, state and transfer of value. Globally reachable like a next gen Bloomberg but not just for trades and messaging but for any front-office, middle-office or back-office application. The future state is that there is much more secure, automated and deterministic business process based; assets and value flow freely across the business network and are interoperable with other sector specific business networks.

Dappsync is a software application that enables business to connect their Salesforce instance to Corda Business Networks. Dappsync empowers organizations to utilize a Corda State Machine backend for distributed business processes across multiple stakeholders. This workflows process is distributed in the form of JARS that make a CorDapp.

A CorDapp allows for a direct transaction, from two nodes on a p2p network. This transaction is also broadcasted to a notary service. The transactions that are shared between two participants / proposers on the network are known as shared facts. The shared facts represent a state change on the network. A chain of transactions that are deemed historically shared facts or state are used to preserve the history of the chain. Using the Salesforce platform we can create an interface for CorDapps to be integrated into any of the Salesforce Clouds. This could allow for a number of different products that are currently offered in financial services to be directly integrated with customer data. Corda allows multiple organizations to transfer transactions using the UTXO model. The applications are written in Kotlin or Java, and can be also used with JavaScript.

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.

_Source: https://solutions.corda.net/business-networks/what-is-a-business-network.html

Install it:

Go to Dappsync on the Salesforce AppExchange or install the managed package using SFDX and the steps below.

    sfdx force:package:install --package 04t1U000007nZKXAAA

After the managed package has downloaded go to the rop right corner and switch to Salesforce Classic.

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

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

So far, we get:

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

Now that you are connected to dsoa.network you can start sending states with other organizations that are part of the network.

There are many different types of assets that can be transacted on the DSOA.

Customer States are transferred between stakeholders on the network.

The first state to be deployed on the network is the Account. Version 0.1 of the Account State has the following structure:

// *********
// * Account State *
// *********

data class Account(val accountId: String,
                   val accountName: String,
                   val accountType: String,
                   val industry: String,
                   val phone: String,
                   val controller: Party,
                   val processor: Party,
                   override val linearId: UniqueIdentifier = UniqueIdentifier())

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

• CreateAccount - Create an Account between your organization and a known counterparty on the DSOA
• TransferAccount - Transfer the Account between your organization and a counterparty on the DSOA
• ShareAccount - Share the Account Data with a counterparty
• EraseAccount - Erase the Account Data

The second state to be deployed on the network is the Contact. Version 0.1 of the Contact State has the following structure:

// *********
// * Contact State *
// *********

data class Contact(val contactId: String,
                   val firstName: String,
                   val lastName: String,
                   val email: String,
                   val phone: String,
                   val controller: Party,
                   val processor: Party,
                   override val linearId: UniqueIdentifier = UniqueIdentifier())

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

• CreateContact - Create a Contact between your organization and a known counterparty on the DSOA
• TransferContact - Transfer the Contact between your organization and a counterparty on the DSOA
• ShareContact - Share the Contact Data with a counterparty
• EraseContact - Erase the Contact Data

Version 0.1 of the Lead State has the following structure:

// *********
// * Lead State *
// *********

data class Lead(val leadId: String,
                val firstName: String,
                val lastName: String,
                val company: String,
                val title: String,
                val email: String,
                val phone: String,
                val country: String,
                val controller: Party,
                val processor: Party,
                override val linearId: UniqueIdentifier = UniqueIdentifier())

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

• CreateLead - Create a Lead between your organization and a known counterparty on the DSOA
• TransferLead - Transfer the Lead between your organization and a counterparty on the DSOA
• ShareLead - Share the Lead Data with a counterparty
• EraseLead - Erase the Lead Data
• ConvertLead - Convert a Lead State into an Account State and Contact State

We created the Carmen Dashboard to provide the ability for organizations to create Accounts, Contacts, and Leads with counterparties on the network.

// *********
// * Case State *
// *********

data class Case(val caseId: String,
                val description: String,
                val caseNumber: String,
                val caseStatus: CaseStatus,
                val casePriority: CasePriority,
                val submitter: Party,
                val resolver: Party,
                override val linearId: UniqueIdentifier = UniqueIdentifier()) 

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

• CreateCase - Create a Case between your organization and a known counterparty on the DSOA
• StartCase - Start on an unstarted Case
• CloseCase - Close the Case with a counterparty
• EscalateCase - Escalate the Case

Message States are transferred between stakeholders on the network. Messages are encrypted and directly sent to individual users at nodes on the network.

Version 0.1 of the Message State has the following structure:

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

     data class Message(val id: UniqueIdentifier,
                       val body: String,
                       val fromUserId: String,
                       val to: Party,
                       val from: Party,
                       val toUserId: String,
                       val sentReceipt: Boolean?,
                       val deliveredReceipt: Boolean?,
                       val fromMe: Boolean?,
                       val time: String?,
                       val messageNumber: String,
                       override val participants: List<AbstractParty> = listOf(to, from)) : ContractState

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:

@CordaSerializable
enum class AgreementStatus {
    REQUEST, APPROVAL_REQUIRED, APPROVED, IN_REVIEW, ACTIVATED, INEFFECT, REJECTED, RENEWED, TERMINATED, AMENDED, SUPERSEDED, EXPIRED
}

@CordaSerializable
enum class AgreementType {
    NDA, MSA, SLA, SOW
}

The Reference State of the Agreement to Agreement Line Items.

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 occur 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)

}

We created the Agreement Dashboard to provide the ability for organizations to create Agreements with counterparties on the network.

We created the Asset Dashboard to provide the ability for organizations to create Assets with counterparties on the network.

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 carmen.network you can start sending agreements and assets with other organizations that are part of the network.

The purpose of this Business Network is for stakeholders to come to a shared set of historical facts related to customer data.

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.

_Source: https://solutions.corda.net/business-networks/what-is-a-business-network.html

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.

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.

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.

Source: https://corda.network/policy/admission-criteria.html

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.

_Source: https://solutions.corda.net/business-networks/business-network-operator-node.html

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.

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

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.

Source: https://corda.network/policy/gdpr.html

Customer data is represented a historical set of states between controllers and processors.

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.

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.

Source: https://corda.network/policy/security.html

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 connect@dapps-inc.com

• Dom Steil (@domsteil) – DAPPS

DAPPS INCORPORATED 2019. ALL RIGHTS RESERVED.