# Substrate Integration in Openlaw

## Project Description

Integrate Kusama/Substrate as a supported network in [OpenLaw](https://openlaw.io) legal agreements and VM.

We want to enable OpenLaw users to create agreements that can interact with the Kusama network by recording signatures, initiating contract calls and listening to contract events.

There are several changes necessary to integrate the Kusama network. The [OpenLaw language](https://docs.openlaw.io) will be amended to support the definition of new networks at the agreement level and appropriate configuration entries added to the OpenLaw application to enable the new network at the server level. In addition, the OpenLaw Virtual Machine will require a new network provider implementation to be written to handle API interactions with Substrate-based chains. Finally, code that generates and verifies signatures, initiates contract calls, and handles events from deployed contracts must be updated to support the new network type.

## Team Members
* David Roon
* Craig Blake

## Team Website
https://openlaw.io

## Legal Structure

Joint venture between Aaron Wright, David Roon, and ConsenSys AG

## Team's Experience
OpenLaw is a Ricardian contracting system co-founded by Aaron Wright and David Roon.

OpenLaw has built a core set of tools that enables the creation of Ricardian contracts. Its core technology transforms natural language agreements into a computer-readable JSON object and also enables creators of agreements to trigger one or more smart contract calls.

These agreements can be automatically generated from an OpenLaw private instance or through a public or private API.

OpenLaw has also build various different work flow related tools, which enable users to pull in data from third-party oracle solutions, store agreement in centralized document management systems, and pull data from agreement into other data structures (like a spreadsheet)

The team has members, which contributed to the initial Java implementation of Ethereum, and played a small role in Ethereum's launch.

## Team Code Repos
* David Roon: https://github.com/adridadou
* Craig Blake: https://github.com/craigwblake-openlaw

## Team LinkedIn Profiles
* David Roon: https://www.linkedin.com/in/davidroon/
* Craig Blake: https://www.linkedin.com/in/craigwblake

## Intended Language of Development

Javascript, Scala

## Development Roadmap

Please note the team also has other features and work items outside of this grant application. The timeline below is not based on two people working full-time but rather cumulative 1 full-time person. Deliverables marked with * have a detailed list of types/methods that will be implemented in the next section "Specification Details"

### Timeline and Milestones

#### Milestone 1

To set up an agreement, the agreement needs to be "marked up" using [OpenLaw's markup language](https://docs.openlaw.io/markup-language/).

In order to integrate with Kusama, the Markup Language needs to be updated to acccomodate language-level and application-level constructs to define new networks.

On the language level, OpenLaw needs to update the way smart contract calls as well as OpenLaw smart contract event listeners are being defined so they can accept a Polkdot node / network definition.

This needs to be done and validated within OpenLaw templates and workflows.

Changes in the OpenLaw template language whereby signed legal agreements can trigger smart contract calls on Kusama

Duration: 2 weeks

Deliverables:
- New syntax to inline network definition (as opposed to just the network name) with type check in Ethereum calls and Ethereum event listeners
- node url
- chain id
- Change data structure from enum to a type for network definition with validation

Funds Requested: 800 KSM

#### Milestone 2

Users of OpenLaw can set up a private instance whereby they can manage the agreements they want to use and also set up smart contract calls.

These private instances have an "admin" page where a user can select the blockchain they want to use for smart contract calls. We need to update the admin page to be able to select one or more Kusama substrates.

Duration: 2 week

Deliverables:
- create new page to see the definition of every networks (by default you have mainnet, rinkeby, ropsten and kovan)
- repurpose the private network configuration to edit each new network
- new add /edit / delete function for the networks
- each network can be used in the template / flow language
- set by default the common nodes, if it makes sense we can add the common nodes from Kusama as well

Payout: 800 KSM

#### Milestone 3

Each smart contract call that interacts with OpenLaw needs to open a connection with a specific node, send the request and listen to the result.

We need to update the way orchestration is done to only open up to a certain amount of connections to Kusama to avoid starving the server.

Duration: 2 weeks
Deliverables:
- Modify the EthereumFacadeProvider to connect to custom networks
- Create a connection pool to avoid issues
- Test with Kusama nodes to make sure that the functions we use for Ethereum calls and Event listeners work
- Define relayers where possible (for calls made by Openlaw itself)

Payout: 800 KSM

### Specification Details

The milestones are organized in layers

#### Layer 1: Language layer
We want to make sure that a user can define the connection to one of the chains within Kusama for agreements and flow

#### Layer 2: Admin layer
Admin part is important to pre-package those networks and make it easier and more portable to work with. By having a common name, people can use different nodes for the same network

#### Layer 3: applicant / orchestration layer
We need to integrate these changes so that anyone can simply integrate any chain within Kusama in their template or flow

## Funds Required Overall
2,400 KSM

## Additional Information
The implementation is based on the fact that each side chain in Kusama is compatible with ABI v1 encoding.

We are not yet supporting ABIv2 but it could be added if necessary.

Also, we know that some parachains will have rust smart contracts and the question here is whether ABI encoding is compatible with it or if we will need a new encoding for them. That could be scoped later if needed.