# 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.
Last changed by  
 
Team
364

Read more

DAO IMPLEMENTATION IN RUST FOR NEAR - PHASE 1

Reminder of Phase 1 - dev environment & team setup We want to keep the project open and as collaborative as possible. That means that it should be quick and easy for someone to get up to speed and implement a package. To get there, we need to have a team setup with a good documentation so that anyone can set it up locally and focus on the code, not configuring NEAR or any other part that might be needed to get to work. The high levels deliverables here are: Setup so anyone can write the DAO TDD style similar to what has been done for the Solidity version Giving a tutorial / story about how to develop in NEAR for a solidity developer Giving feedback about the pain points to work with NEAR, with solutions if possible

11/25/2020
DAO IMPLEMENTATION IN RUST FOR NEAR

Project Description The goal is to implement the Rust version of LAOLAND so anyone using NEAR can use it to manage a DAO. This is also an opportunity to write a standard interface for this architecture so anyone can upgrade their DAO on NEAR or Ethereum. Team Members David Roon James Young Craig Blake

11/13/2020
DAO IMPLEMENTATION IN RUST FOR NEAR

Project Description The goal is to implement the Rust version of LAOLAND so anyone using NEAR can use it to manage a DAO. This is also an opportunity to write a standard interface for this architecture so anyone can upgrade their DAO on NEAR or Ethereum. Team Members David Roon James Young Craig Blake

11/3/2020
Read more from Team
Published on HackMD