Patract Labs walked into Substrate Seminar and introduced Wasm contract tool suite

Our Mission

As stated on our website: Patract’s mission is to accelerate the smart contract industry’s transition to WASM technology stack. Polkadot is really a great platform. It provides unlimited imagination for developers, and allows people to build their own chain with substrate. Meanwhile, many business scenarios can be implemented by deploying, composing contracts, So we believe, Polkadot’s parachain with contract platform, will have stronger activity than other ecosystems.

Truffle Suite

Patract Products

  • Redspot is a product similar to Truffle, a tool to make contract development become projectized. It covers the entire process of contract development such as Develop->Debug and so on.
  • Europa is a product similar to Ganache. It is a simulation node that provides a contract running environment, and it records a lot of contract information during executing contracts.
  • Metis is a project similar to OpenZepplin contracts. it’s purpose is to establish a way for developers to write contracts in a standard way.
  • Ask! is a contract language which we are developing, based on AssemblyScript. It is used for writing Wasm contracts, same as ink!, but because it is based on AssemblyScript, which is a variant of TypeScript, So it may become more popular with developers.
  • Himalia is the general name of contract SDKs in multiple languages, similar to Web3.js, web3J, Web3py, and so on. Currently Polkadot.js is officially designed by Parity, but other languages do not have good support for contracts, such as go, java, python and .Net. Himalia is for this purpose, and this project has finished two languages SDK for go and python。
  • Leda is used to monitor the contract running information. For example, the storage rent mechanism of the pallet-contracts will cause the contract to be destroyed when it does not have enough money, so monitoring contract on-chain data is required. The project is currently only in planning, because ink! and pallet-contracts cannot be widely used in production environment.
  • Carpo is our contract WebIDE that integrates all our products on the developer side into a service, and will provide developers with a one-stop contract development process. There is a Remix in Ethereum, but the Remix cannot give developers a good experience, for it does not have a good language service system, (but it does a good job for helping contract development, I mean, it is designed for contract).
  • And the Substrate playground is a good usecase, but it lacks the design of For Contract Development. Therefore, we believe that Carpo will greatly help the contract development ecosystem, because it’s designed for the contract development, and the experience can be close to the local developing. Carpo is in planning now, but we expect this project to start around July.
  • Elara is a product that provides blockchain endpoints for developers and users, similar to Infura in Ethereum. Our Elara has some unique designs, which can provide more connected node services with fewer resources. We are re-writing this part recently, and it will be more robust in the future.
  • For the user side, our products mainly include PatraScan and PatraStore. Among them, PatraScan adopts a different design with other blockchain scan in the Polkadot ecosystem, thus it could show more detailed blockchain information. For PatraStore, we adopt a concept similar to dapp platform, which allows users to experience all kinds of dapps in one-stop, now it only contains several sample open source DApps. For now, PatraScan is in development and PatraStore is running for first version.

Product Demo

By the way, we are building the document for WASM Contract and our other products, which is named Substrate Contract Book. The document can be a greatly useful tool to help developers learning and writing WASM contracts in one stop.

Case Share

First, let me show you how to use Redspot and Europa to develop contracts.

  1. You should make sure you have nodejs in your computer
  2. npx redspot-new erc20
  3. Look at this, this is not just a simple contract, it’s a project which contains scripts, tests, and you could use redspot command to do many things.
  4. This method regulates the way to organize a contract project. It has many advantages, such as the project. This project is an ink! project built by redspot. it’s a multi-contract structure. Since the deployment of multi-contract projects is complicated, for example, first need to deploy this contract, and next deploy this contract.
  1. Now we need to run a node to deploy and run the contract. Parity has its own Canvas testnet environment for contract testing, but in the actual development of local testing process, using node to test is time-consuming and troublesome. Therefore, we designed Europa to replace the node which runs the contract
  2. First, we run europa in this way, it’s similar to a normal substrate node. and we open apps, we can see that apps can connect to europa directly,
  3. Then we try to do a transfer, and we can see that the extrinsic is packed immediately, without the need to wait for the time of block interval. This feature saves developers a lot of time. This feature is very important in developing and debugging, or in combination with redspot for integration testing, or in other cases. so europa is a better simulation of a node environment.
  4. Now we have a node to execute the contracts. then we go back to Redspot.
  5. First we execute npx redspot compile, we could see that Redspot auto detects the contract directory, and do compile. the detected directory config is in redspot.config.ts file. All based Redspot configs could be found here, and more features could refer to our document. Here the config part introduces all configs.
  6. Now, we can see the compiled products is in artifacts directory, and the name is your contract project name.
  7. Parity apps can react with node to deploy the contracts, we try this first. We deploy this contract and call transfer. It’s a normal workflow.
  8. But please note that, image if we change the contract and wanna test it, first we compile it again. Then we need to re-deploy it and call a function. We can find that, this process in apps is very troublesome and boring.
  9. Then we look at the deploy script in this directory. Like what we do in apps, deploy a contract and call a function, we can write those action as a script.
  10. Then, we only need to execute run command to run this script( npx redspot run scripts/, so this script will automatically do the same thing in apps. When the contract changes, after compiling, we can execute the run command to quickly do the same thing. We can see that, Redspot cooperating with Europa can greatly free the power of contract developers.
  11. Next, we look at the scripts in the tests directory. You can notice that test provides rich tools for testing. Redspot’s testing framework is based on mocha and chai, and we have designed our own redspot/chai plug-in for test. View for details.
  12. Here, we emphasize that redspot is forked from Hardhat, so redspot can expand its rich functions through plug-ins. For example, the redspot/chai is a plugin, and here is the imported plugins. Currently we have some basic plug-ins, and community developers can also participate in enriching the features of Redspot.
  13. Now we switch to europa to take a look. During calling the contract, a lot of information is printed in europa’s log. Compared with normal system, when execute the contract in EVM or in pallet-contracts directly, the execution process of the contract is a black box for developers. Therefore, europa is committed to display the internal information of execution and turn the execution process into a white box to provide developers with rich execution information.
  14. We collect a contract’s execution process into a NestedRuntime, so for once execution, we can see the contract address, selector, parameters, gas and other information in the contract execution. Notice the gas_left here. When in a cross call contract situation, I mean a contract calls another contract, only the gas consumed during the entire call can be known, but the gas consumed by each layer of the contract call cannot be known. And the gas_left shows one layer contract gas consumption, it can solve this problem.
  15. For example, in a call, contract A calls contract B. In normal case, we only know the gas consumptionfor the whole process, and don’t know how much gas for A and B respectively. And in Europa, the gas_left here shows the gas consumption inside the contract. So we can figure out the gas consumption through this field.
  16. And env_trace shows the call of host_function in this contract execution. According to host_function, we can get more information to help user to solve the bug of contracts, for example we can follow the sequence of host_function to guess where the contract is trapped. If the contract is trapped, the following host_function will not be printed.
  17. The nest field represents the crosscall for contract. For example, in the process of A calling B, contract A is the outer layer NestedRuntime, and contract B will appear in the nest part with the same NestedRuntime structure.
  18. Therefore, through Europa, the execution process of the contract can be turned into a white box , allowing developers to debug the code in a better way.
  19. In addition, Europa can also print out the Wasm backtrace when contract traps. To test this, We add a panic in “constructor” function. Of course, when init the contract, it will trap here. So, we execute command to deploy contract, and switch to Europa log. View for details.
  20. you can see that the Wasm error can’t be parsed to show more details. To analyze this parts, we need to install the cargo-contract under our patract repo, not parity. For our cargo-contract providers debug compiling feature. (cargo install cargo-contract — git click — branch=v0.10.0 — force)
  21. Then we switch to the contracts directory to compile contract. Please note that our cargo-contract can add the — debug parameter to compile, and then we replace the target contract file in the artifacts directory, because, redspot can recognize the contract file here.
  22. Now, we execute the run command again, but notice we need to add no-compile flag in case redspot recompiles the contract, and we can see the detailed Wasm backtrace print during this execution, and from the print process we can see that the error location appears in new function part, here, is the same location we just added panic code.

Patract’s data service layer

PatraScan & Other Scans

  1. First, they need to know that there is the business logic of transfer on the chain, and after the transfer occurs, a event will be printed. And they need to understand that when the transfer occurs, the balance of the sender and receiver will change.
  2. Subscribe to this event.
  3. When meeting an event such as transfer, they need to query the chain for the balance of the sender and receiver, then update their own database.

PatraScan & Apps


  • Cross-contract call. ink! tries to use trait_definition to define the interface, but the current implementation of this part is not good enough. For Ask!, we adopt the concept of interface, which is similar to the design of solidity.
  • Code reuse. Since ink! is based on Rust, the code can only be combined. While, Ask! can use inheritance. But ink!’s current support for reuse is very limited.
  • A typical case is, if there is already an ERC20 contract standard implementation, like the OpenZepplin-Contracts library, if you want to add an issue_token function to this standard contract. Then in ink!, currently developers only can copy the entire contract from the source repo to local, and add this function.
  • (Unless ink! is designed on the contract composability. And because the resources of the contract are bound to this contract, it is difficult to design this piece of composition semantics. )
  • As for Ask!, it can design a way similar to solidity’s inheritance, inheriting from this ERC20 contract and extending the issue_token function directly.

About Patract

Patract is providing solutions for the development of Parachains and DApps in the Wasm smart contract ecosystem of Polkadot. We help the community to design and develop on-chain contract modules and Runtime support, and provide DApp developers with full-stack tools and services support, covering development, testing, debugging, deployment, monitoring, data provider and front-end development stages.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Patract| Wasm Contract Open Platform

Patract| Wasm Contract Open Platform

Patract is providing solutions for the development of Parachains and DApps in the Wasm smart contract ecosystem of Polkadot.