How to DeFi on Polkadot Series Part 2: Generic assets and Smart Contracts

Published in

Polkaswap Community Collective

16 min readSep 14, 2021

People typically underestimate what it takes to be knowledgeable in the DeFi ecosystem. Often when partaking in the discussions of a DeFi platform people are quicker to ape in without thinking and talk about APYs than they are to talk about the assets themselves or the underlying smart contracts that create the platform. Understanding what these assets are and do can help you better ascertain the potential value and originality of a token in very little time. While understanding the smart contracts can not only help you participate in DeFi but do so with confidence; as you are able to read the contracts and potentially protect yourself from a scam project or rug. This article will attempt to help users understand these subjects better, introducing them to some of the more complex technical aspects of DeFi at the same time and the concept of interoperability between blockchain projects.

Accept and Abandon by Damien Hirst

What is an asset?

Asset

The term ‘asset’ is not used only in the crypto ecosystem, it comes from the traditional financial system which is used to refer to a physical or digital resource with economic value. The same concept is used in crypto for digital resources and can go beyond the traditional idea of value but the most important factor is that it is probably scarce. These digital assets can have utility for the network that issues them, provide some kind of benefit and access to the owner, or are of historical or artistic importance within the digital landscape.

In the last years a unique type of digital asset has been gaining a lot of attention, the non fungible tokens or NTFs. NFTs are mostly used to prove ownership of physical or digital items. As of now it has been mostly used for art, music, digital accessories, etc. while on the forefront complex and open ended derivatives of NFTs are beginning to emerge.

Token

A token is a digital asset created on a blockchain used as a unit of value. They’re mostly used for governance or to pay for the execution of a specific service and their supply is usually capped. A token itself does not have a determined value, its value is gained through the value the community gives to it.

There are several standards created to define a “token”.

At the moment of writing this post, the network with the most tokens on it is Ethereum because of the support the Ethereum virtual machine (EVM) has for smart contracts.

Nowadays most of the tokens are ERC-20s generated with a smart contract on Ethereum. Another popular token type on Ethereum is an ERC-721 which is a non-fungible token or NFT and the newer ERC-1155 that allows developers to deploy a single smart contract and then mint new tokens for perpetuity.

Native Assets Vs Wrapped Assets

An asset is considered native when it is minted, used, or transferred within the chain where it was created. In the case of Polkadot or Kusama, their native assets DOT and KSM use the SS58 address format. This is because even though they serve as relay chains of their ecosystems they were built on top of Substrate and Substrate uses the SS58 format as default.

In the case of Polkadot the concept of “native assets” differs a bit as every chain is free to make their own implementation. Preparing for the implementation of XCMP In 2020, a group of developers from different chains (Acala, HydraDX, Moonbeam), got together to propose a new version of the Tokens module that adds support for XCMP.

As all the chains built with Substrate are able to run as a solo-chain or parachain two different solutions were required, one to manage the balance of the assets for isolated chains and one with support for cross-chain messaging. Together these modules were proposed as the Polkadot Token Standard.

Until now every chain was using either the balance, currencies, or assets modules from the Open Runtime Module Library (ORML) and adding their own customization according to the requirements of their business logic.

Between the proposed changes one of the most important is the definition of a unique identifier that will serve as an asset symbol. Once XCMP goes live the identifier will be replaced by a concatenation of the symbol+multilocation (locations within consensus).

As the crypto ecosystem grows, one of the most demanded features was the possibility to use assets of a chain ‘A’ on a chain ‘B’, while such an idea sounds great, it is not easy to achieve. For teams looking for a solution, things got more complicated when they realized that some networks are so different in terms of design that making them compatible would require an enormous refactor of code for both chains. This makes it an inefficient approach if we consider the number of blockchains that have been released in the last few years only and the possible performance impact that could cause for a blockchain to be able to validate and manage two types of assets that are so different.

In 2014 a concept was proposed. The idea was simple but effective, minting a pegged representation of our underlying asset instead of building native compatibility for it.

As a first attempt to bring this idea to reality, different teams started working on a pegged representation of FIAT currencies, as we could expect USD was the first currency to have a pegged token representation back in 2014 when Tether limited minted the first ‘USDT’ tokens announcing that each USDT token was backed by a physical dollar in Tether’s reserves.

According to DefiPulse until September 5th, 2021, The total circulating supply of crypto-backed dollars is 83.19 billion dollars.

As the concept of wrapped tokens was accepted and adopted by the community, in January 2019 a wrapped version of BTC was launched on Ethereum. As of now, there is a total of 13.74 billion dollars locked into different wrapped versions of BTC, being WTBC the wrapped token of more usage.

Ethereum is not the only network with wrapped tokens. The idea of wrapped tokens was adopted by many networks through bridges that mints a native token pegged to the underlying asset, in 2021 some of the bridges that got most attention from users were Avalanche with a TVL of $1.26B and Polygon.

How do wrapped assets work? Well, every chain has its own methodology to tackle this problem but the basic idea behind wrapped assets is that in order to mint a pegged asset in a chain ‘A’, there must be one asset locked and secured in a chain ‘B’. One of the most used tactics is the use of a vault in the chain ‘A’ to store the native token and once the transaction of the lock has been confirmed, a pegged asset can be minted in the chain ‘B’.

One example of this is the way the HASHI bridge works for Sora network where whenever we want to use our ERC20 assets in Polkaswap our ERC20 tokens are stored in a smart contract on Ethereum and our transaction is validated by HASHI to mint pegged assets on Polkaswap.

Once we have finished our trades the process comes full circle, our Polkaswap assets are burned and ERC20 assets are unlocked for our address on Ethereum.

Another option we have for the Polkadot ecosystem is Snowfork. Snowfork is a trustless bridge that is being built on top of Substrate and aims to become a parachain. Snowfork has been working on a Trustless bridge that allows Parachains or dApps running on a Substrate chain to change the status of a smart contract deployed on Ethereum, as the bridge has a channel open on both sides, a smart contract deployed on Ethereum can change the status of a Substrate dApp or Substrate chain by simply calling a Substrate RPC endpoint.

In order to keep track of the latest state of the chain on both sides of the bridge, Snowfork has developed an Ethereum Client Verifier, a Polkadot Client Verifier and a Parachain Client Verifier. Each client is responsible for monitoring different values from the chains they were configured for, in Ethereum some of those values are new Ethereum Headers and proof-of-work data while in the Polkadot client it keeps track of the latest data block and mmr-proofs from the relay chain.

In the case of Ethereum, besides the use of the Ethereum Client Verifier, Snowbridge utilizes relayers to keep track of the latest status of the target network while using the bridge. A relayer is a third-party entity that is re-sending data from point A to point B. The use of relayers allows the bridge to know what the current state of the target network is so we can know parameters like the latest gas price on a network before executing a call.

As of now, Snowfork has announced the first three dApps, snowETH, snowDOT, and snowERC20. These dApps allow us to mint pegged assets that are in sync on both sides of the bridge, also Snowfork has already announced its intentions to add support for ERC721 tokens in the future.

Snowfork will also allow other parachains to integrate and use its native assets through XCMP calls. It will also allow other parachains to mint an ERC20 version of their native token or deploy real cross-chains dApps.

Smart contracts on Substrate

A smart contract is a set of instructions stored in the blockchain. With a smart contract, we can create crypto applications called dApps (distributed apps) that follow a simple procedure for different scenarios depending on what requirements are fulfilled with the input received.

This kind of application is useful for actions like voting, crowdfunding, auctions, or any other process where you want to reach an optimal result without the intervention of any individual.

Polkadot and Kusama will not support smart contracts themselves since they are relay chains. Their primary functionalities are bringing coordination and security to their ecosystems. Relay chains don’t support smart contracts because they can’t register state changes, they only validate state changes from the parachains. Relay chains per design require any state change to be done on a parachain and then delivered as a WASM executable, this is because the relay chain stores a ‘state transaction function’ (STF) and every time a change of state happens on a relay chain, relay chain validators must compare the state sent by a parachain collator against the one stored on the relay chain.

Substrate-based chains can execute two types of smart contracts, EVM smart contracts and WASM smart contracts. The technology Substrate uses to understand both are different for each one. In the case of EVM, Parity has created ‘Frontier’, an Ethereum compatibility layer for Substrate and a native Smart contract pallet for WASM smart contracts. In theory, several languages could be used to write WebAssembly smart contracts and then just be compiled to WASM but in order to standardize them, Parity developed ‘INK!’, a rust-based e-DSL to integrate deeply with the Substrate modules loaded in each chain’s runtime.

As relay chains don’t support smart contracts natively there are multiple projects focused on adding support for them. Some of the chains offering smart contract support on Polkadot are:

Moonbeam
Edgeware
Acala
Astar
Phala

Pallets

The substrate runtime was designed to be modular, this means it is composed of smart Rust modules called pallets. We could see a pallet as a kind of library created with a single purpose. In the case of Substrate, all the actions across the network were written in pallets, one example of this would be the ‘staking pallet’. As logic on Substrate is delivered through pallets it is really easy for substrate-based projects to re-use the logic coded by others.

Substrate offers a framework with specialized tools for individuals or teams

aiming to work with runtime development. The Framework for Runtime Aggregation of

Modular Entities (FRAME) is composed of pallets with basic functionalities.

Some of these functionalities are:

Sudo pallet
Staking pallet
Assets pallet
Democracy pallet.

Thanks to this framework, developers are able to create a functional Substrate-based blockchain in a couple of minutes and then just add customization to it, instead of writing their own blockchain over years.

Smart contract pallet

The smart contract pallet allows any Substrate network to deploy and execute WebAssembly smart contracts. The smart contract pallet requires a WASM engine integrated into the runtime of the chain using the pallet.

EVM pallet (Stable)

The EVM pallet uses Sputnik VM as the engine. Sputnik is a Rust implementation of the Ethereum Virtual Machine and the accounts created with Sputnik are not compatible by default with Substrate, this is where the EVM pallet goes comes into action mapping the Substrate accounts with the sputnik accounts so if a balance changes in a Substrate account the underlying Sputnik account will be updated as well.

In terms of compatibility with the Ethereum network, the EVM pallet offers almost the same results the original EVM would do including gas cost.

Ethereum pallet

The Ethereum pallet brings Ethereum block emulation, allows already existing dApps to be deployed on Substrate with little modifications, and validates Ethereum encoded transactions.

Even though the Ethereum pallet is already available, it is considered a work in progress by the development team since some parts of it could be changed in the future.

INK!

Ink is designed to be used as the main language to write Smart Contracts for Substrate chains, it is backed by Parity and it offers some cross-chain compatibility with Ethereum smart contracts, instead of inventing a new language the Ink team focused on adapting Rust for this purpose.

Thanks to the compatibility Ink! has with Rust it includes support for most of the most common tools used in Rust out of the box, tools like rustftm, debuggers, and even extensions for text editors.

One of the main differences between smart contracts written with Ink and smart contracts written with Solidity is that those written with Ink will have native support to WebAssembly. Since Substrate was built with Rust the support for Ink smart contracts is native and does not cause any overhead to the runtime.

Some of the benefits WebAssembly brings to the new generation of smart contracts are:

High performance
Small file size
The bytecode can be deployed to any browser
It has compatibility with Just In Time (JIT) compilers
WASM is an open standard, and a lot of companies are working on its development.
Memory safe
Multi-language. You could write your smart contract in Rust, C/C++, C#, Typescript, Haxe, and Kotlin and then compile it into wasm. Substrate recommends Rust for its lack of runtime overhead and the security properties it offers.

How are generic assets created in a blockchain?

Each network has a different process for the creation of new assets, in the case of Ethereum whenever we are creating new assets we must first define if we want to create a fungible or not fungibles asset. Ethereum has decided to divide them into different types, ERC20 is the standard used for fungible assets, while ERC721 and ERC1155 are used for non-fungibles. In terms of creation, they are all created with smart contracts. As of today most of the Ethereum smart contracts that are used to create new tokens or dApps on Ethereum are written with Solidity.

Solidity is a high-level language designed for the Ethereum Virtual Machine.

In the case of Polkadot assets are native to each network, this means each project is able to customize how their assets will be issued directly on their runtime and so they don’t need to deploy any additional piece of code on top of the network.

Is there a way to create a token in Polkadot without building my own network?

Yes, different projects have been working on a solution to create a generic asset without having to build your network.

In terms of interoperability, all the chains should be able to adopt any of the current solutions offered in the market already.

How does that work? An easier way to do it would be using SPREE (Shared Protected Runtime Environment), SPREE was created to solve the trust issues between parachains. SPREE modules are pieces of code that a parachain shares with other parachains and that all of them are forced to execute if they load the same module. SPREE ensures messages sent through XCMP between SPREE modules of different parachains are received and executed. If we follow this logic it is easy to understand how a trustless cross-chain asset management module could work. A parachain ‘A’ only needs to load the same SPREE module as parachain ‘B’ and the runtime will allow both chains to transfer and manage their counterpart tokens in a trustless manner.

One example of this is Polkaswap who created a whole asset management system where any project can list their token using the Sora native address system and once XCMP is enabled they will be able to cross-chain transfer their tokens to the Sora network easily.

Below we will list some of the projects working on a solution of this type.

STATEMINT

Statemint is a parachain that serves for the deployment of generic assets in Polkadot or Kusama (through Statemine) as long as these are backed by a deposit of the token of the main network like DOT or KSM.

How does Statemint / Statemine work?

The account that is creating an asset becomes an asset administrator, and they will automatically get the permissions to mint, freeze, and burn whatever tokens they want. There is also the option of creating an asset that is not backed by any DOT / KSM deposit as long as the governance of the relay chain allows it.

Being an essential part of the Polkadot ecosystem, Statemint was deployed as the first common good parachain both in the test network and Kusama.

The addresses in Statemint use the same SS58 prefix that the relay chain uses. Statemint does not currently have any native tokens, and its token is that of the relay chain in which it is deployed; DOT for Statemint or KSM for Statemine.

Does Statemint work with smart contracts?

No. Remember that Statemint is a blockchain by itself deployed as a parachain, and therefore the logic behind it is deployed in the network runtime through pallets. For this reason, it does not use any smart contract for the creation of generic assets.

Even though Statemint won’t support smart contracts, a smart contract will be able to call Statemint through cross-chain messaging and handle token transactions, the reason for this is that INK smart contracts are compatible with Substrate and they are able to trigger runtime functions.

Statemint offers the possibility of creating fungible assets and non-fungible assets, so it is possible to create NFTs in Statemint as well.

The main difference between ERC20 and the current solutions growing on the Polkadot ecosystem is the price people need to pay to interact with their assets. On an L1 solution like Ethereum, the price will be always higher since any interaction requires a call to a stored smart contract and to pay the price of gas as a fee. On a Substrate-based chain, our interaction with an asset would be through the execution of an extrinsic call which is basically a group of methods running in the runtime of our target network exposed through an API so any client can interact with it and the fees we pay for such a call is significantly lower.

The reason why fees are lower if we use Statemint is that assets minted through a smart contract need to have control of the whole execution while Statemint being an independent network included all the basic logic of an asset directly as a runtime function and so since all the assets will use the same piece of logic the execution price is flat. One of the major perks of having a piece of logic integrated with our runtime is that we will be able to call read-only functions in a costless manner if we do it through a RPC call.

On Ethereum the base fee is calculated and adjusted by how full the most recent blocks were. This causes a considerable increase in the price of the base fee when the number of transactions waiting to be confirmed is high. On Polkadot, we have the weight fee which is in layman terms a fixed value of how much it takes for the relay chain to validate a block.

Polkadot as a relay chain is ready to process more than 1000 transactions per second running as standalone and without having multithreading enabled. What makes Polkadot different is that its shard chains (parachains) are autonomous chains and so the internal transactions of a parachain like balance transfer or interaction with dApps deployed inside that parachain won’t be paid in the relay chain currency (DOT).

MOONBEAM

Moonbeam is a blockchain network building on Substrate focused on reaching a high level of compatibility with the Ethereum Virtual Machine (EVM), one of the main features Moonbeam offers to the public is the possibility of deploying any smart contract originally written for Ethereum with minimum development effort.

Smart contracts on Moonbeam can be written in Solidity, Vyper or any other language that is able to compile EVM compatible bytecode.

How does Moonbeam work?

The Moonbeam development team has focused on creating a product that can make the migration from Ethereum to Moonbeam as smooth as possible for any developer, that is why development tools like Truffle, Remix and Metamask can be used in Moonbeam with minimal modification to their base code.

Thanks to the large amount of Ethereum applications planning to build on Moonbeam, other Polkadot projects can benefit from applications for DeFi, crowdfunding, lock drops, airdrops, and others.

POLIMEC

KILT proposes a new mechanism called POLIMEC (Polkadot Liquidity Mechanism) which focuses on helping obtain liquidity to projects of the Polkadot ecosystem that are not yet ready to have a token or a digital asset in their network. The concept behind POLIMEC is very similar to the mechanism with which ERC20 type assets work on the Ethereum network.

Polimec is designed to function as Parathread in Polkadot.

One of the disadvantages that POLIMEC has is that it is widely integrated with KILT (this because both projects have been developed by the same team) so that every user who wants to use POLIMEC assets must have completed the KYC process before.

Polimec’s transfer system will have an API exposed which will allow any chain to connect easily and start minting assets.