Parachain Runtime and SDK Split-up in KILT

While the Kusama and Polkadot ecosystems are eagerly waiting for parachain auctions, we at KILT Protocol are preparing to secure one of the first Kusama parachain slots and then launch our mainnet. Today we are happy to announce our new releases of the KILT mashnet-node 0.24.0 and SDK 0.20.0 as the next phase of our development.

The mashnet-node received a second runtime for the parachain and multiple updates to run on Rococo using the newest version of Substrate (3.0.0). The SDK was multilaterally improved and restructured by splitting it into several separate packages.

Mashnet-node: It’s parachain time!

These consecutive updates of our Substrate blockchain were required to sync with the official Rococo parachain testnet. Rococo has been rebooted multiple times and always required us to be on the bleeding-edge of Substrate and Cumulus.

Apart from that, we made major improvements to the readability and structure of three of our KILT pallets: Attestations, Delegations and DIDs. On the one hand, we refactored the on-chain data types to be distinct Structs instead of tuples. On the other hand, we replaced our custom error pallet with Substrate errors and improved the order of checking for these.

Moreover, we added benchmarking to all our extrinsics. During this process, we had to introduce two limits for revoking Attestations and Delegations. You now have to specify up to which limit you enable the transaction to recursively check for the parent delegation until it matches the owner of the delegation you would like to revoke. Since revoking a Delegation automatically revokes all of its children recursively, you also have to submit such a limit for the number of children. We require both these bounds in order to be able to calculate the transactions fees and weights correctly.

SDK: Split it up!

After switching to yarn v2 berry, we decided to make use of the supported workspaces and split up the SDK into multiple packages, at least some of which are independent of each other. This enables builders to pick the exact packages they need from our SDK when they want to build on top of it, and reduces the overhead (bundle size, required dependencies etc.) of requiring the entire SDK. Moreover, we can version each package separately.

SDK: Transaction improvements

We enabled multi-transactions which allow you to trigger blockchain transactions successively in one go, e.g. you are not required to wait for one transaction to finish before calling the next one. This is accomplished by counting up the next nonce on the client-side, if possible, and by resigning transactions if the returned error from the chain is recoverable

In addition, we made all our transactions explicit. Whereas before you implicitly submitted a signed transaction when storing an Attestation or CType, revoking an Attestation or making any kind of transfer, you are now rather generating an SubmittableExtrinsic. Upon signing and submitting this, the transaction is then executed on the blockchain.

SDK: Add Config Service & improve chain connection

We introduced a new Config Service that can be used to configure the node address to which you want to connect and set the log level, for now. In the future, this will be expanded whenever we introduce new configurations.

As a result, you no longer need to (and also cannot) provide an address parameter to the connection function Kilt.connect(). Instead, the configured address will automatically be used.

SDK: Use sr25519 as default identity key pair type

Whereas in our last release we added the support for sr25519 and ECDSA signatures, we have now switched our default identity key pair type from ed25519 to sr25519. We are mainly following the direction of Polkadot. Another motivation was that it is much easier to create an sr25519-based account in the polkadot.js apps or polkadot.js browser extension. Of course, ed25519 is still supported by adding it as an option to the identity builder.

Since sr25519 relies on polkadot.js crypto functions, which themselves rely on an included WASM library, you need to wait for the crypto library to be ready. Thus, we added this wait to our initialization function KILT.init({…}) which combines the configuration functionality of KILT.config with asynchronously waiting until the crypto library is ready.

SDK: Add message (de-) compression

Another feature we have added is the possibility to compress and decompress messages. As these can be used for communication between Claimers, Attesters and Verifiers, it is important for them to be shrinkable.

SDK: Switch to JSON-LD based hashing algorithm

During the preparation of the VC-Export package we found a potential exploit where labels could be re-ordered and still lead to the same root hash. This was fixed by switching to an JSON-LD based property hashing algorithm.

SDK: Remove portablegabi

Lastly, we decided to remove our experimental anonymous credential feature “portablegabi” which we introduced in our last release. The main reason is that the portablegabi library handles its cryptography in a Go-Wasm binary which can only be called asynchronously via callbacks. As a result, the instantiation of identities and other protocol functions had to be made asynchronous as well. Moreover, the Go-Wasm binary caused issues when using the SDK in applications like React Native.

This was a disappointment not only for us but also for other teams that build on top of KILT. We are already investigating alternative solutions and will keep you posted on our effort to incorporate an anonymous credential solution (which won’t be portablegabi). But this is a non-critical feature and thus won’t be part of the launch candidate. For now, our focus is to launch the KILT chain with secure code and an easy-to-use SDK.


  • Majorly improve documentation by gathering all documentation combined in one place:


Mashnet-node updated from Substrate 2.0.0-rc5 to 3.0.0 (release notes):

  • Added separate parachain runtime

SDK was split into multiple separate packages (release notes):

  • Switched to yarn v2 berry

KILT is a blockchain protocol for issuing self-sovereign verifiable, revocable, anonymous credentials and enabling trust market business models in the Web 3.0.

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