“Zapps”, XCM based DApps.
How does Kabocha play with the other parachains? What are some of the cross-collaboration applications that Kabocha can explore?
Kabocha is a decentralised community organism. On a technology level, we’re working on developing tools (primitives) for our nascent community of inter-dependent contributors and orgs, so that we can better manage, self-govern and sustainably earn from the creative assets and value we produce collectively, individually and the in-between.
Kabocha, born from Edgeware, and is now living with its parent Kusama, who happens to be obsessed with Kabocha. Kabocha is one of those children that can do no wrong. Even if it stayed up all night past its bedtime playing with the other shards.
A great way to collaborate with other chains is through XCM. Here we will explore some ways XCM will make Kabocha parachain inter-dependent with other chains. This article is not complete, but just a starter to inspire possibilities…
XCM
It is the future of cross-chain DApps. Instead of having a DApp on an evm chain, you can have a DApp that sits on a layer above multiple chains, instead of being in an EVM, they are on an XCVM (cross chain virtual machine).
From now on I will call DApps on XCM “XApps”, or better still “Zapps”. This is not official but it may catch on (don’t forget where you heard it first).
What is XCM ?
It is a cross-chain messaging format, where for example a parachain can send an instruction to another parachain to execute a function call which comes from the origin parachain. This is useful if one parachain has some functionality that the other parachain may want to use.
To be a little more precise, XCM is a standard messaging format, and a kind of procedural language where custom function calls between different locations (parachains, pallets, relays, consensus networks) are executed. XCM is a higher level of abstraction than the consensus infrastructure beneath it. It is agnostic and not opinionated whether it is a message being sent over a parachain, relay chain, solo chain, smart contract or pallet.
XCM messages travel across XCMP channels. You can create a programme of XCM instructions with the XCVM.
To explain the above statement a little further:
- XCM are the messages or instructions.
- XCMP is the passing of XCM messages across different parachains. Channels need to be set up and accepted by each parachain in both directions for this to be set up.
- XCVM is a register-based virtual machine where there groups of XCM instructions that form version-aware programmes.
Current example of XCM
OAK, the “automation” chain is connecting with Mangata, the DEX chain, to enable DEX traders to have “stop-loss” and “take-profit” functions when trading on the Mangata DEX. The functions to stop a trade is stored on the OAK parachain and executed if the correct conditions are met.
XCM is sent over XCMP cross-chain messaging protocol, though currently HRMP is being used, which is a lite version of XCMP. You can find out more here.
Supersig
Like multsig but with superpowers, supersig is a governance tool for collectives. You can create a supersig and add or remove members, which you can’t do with multisig. The next phase for supersigs would be to enable it to manage assets that are not just in Kabocha, but also across Kusama and other parachains. How can we do that? Through XCM.
Scenario example:
You have a Supersig of 10 people called “The institute of egomaniacs”, which hold 100,000 KAB, you can make group decisions on how to manage this KAB. Perhaps you will send a balance transfer to pay for a service, vote on a Kabocha referendum, or stake some funds to Kabocha collators.
But what if your supersig could manage KSM, buy other assets, or vote in different parachain governance? The solution is XCM, more accurately a XCVM DApp, and in the new lingo a “Supersig Zapp”.
Supersig Zapp
What if you could own and manage assets across other chains as a supersig collective?
What are some things you could do with a supersig zapp?
You can interact with other chains through channels that have been established with Kabocha. Then you can send instructions across chains, such as:
- Supersig buys aUSD on Karura,
- Supersig earn NFTs on Statemine/KSM.
- Supersig votes in Kusama referendum.
- And much more…
Your Supersig will be able to do these things, but only if KAB has established channels and curated the instruction sets for each chain.
Supersigs can interact with other chains who have setup bi-directional HRMP channels with Kabocha, and send XCM through the XCM virtual machine (XCVM). Sounds a little bit complicated but it is required to enable specific functionality across chains.
Subscriptions
Kabocha subscriptions and memberships open the door to an ecosystem of valuable and useful revenue producing organisations, who can earn for what they create, provide or produce.
Subscriptions can enable individuals and collectives, product/service providers, to earn automated income from other individuals and orgs.
By creating tools that inspire payments between people, where KAB is a medium of exchange, then we no longer need to be reliant on a central funding mechanism referendums as an incentive.
Subscriptions merely support and supercharge the notion of value exchange between the community, opening the door to revenue models where people can create livelihoods (or even “thrivelihoods”).
Subscriptions is a primitive that can create sustainable economy.
Subscriptions “Zapp”
Kabocha is exploring a collaborative partnership with OAK, this will unlock payment automation.
For example, where someone can subscribe to my monthly subscription to receive dedicated engineering support.
What is the mechanics of automating subscriptions in collaboration with OAK?
- Kabocha and OAK establish bi-direction HRMP channels through Root (sudo, technical committee or governance).
- It is decided how fees are paid and in which currency.
- Kabocha creates a Zapp, by leveraging OAK’s time and price pallets, by curating the necessary XCM instructions. This Zapp can then be used by anyone with KAB.
- Pricing pallet can enable conversion of KAB to a stable coin.
- Time pallet can enable automate transfer of balances between two accounts in frequent intervals, i.e. daily, monthly, yearly.
Seeds
Think of Web2… are you thinking..? Ok, now destroy everything you know about “Web2", and therein the emergent concept of Seeds begins.
And not to be mistaken with a “mneumonic seed”, Seeds are an emergent identity primitive spawned from Kabocha. The idea is that a person or group’s connections, actions, contributions, roles, duties, and overall holistic and dynamic growth are represented in their Seed, with Roots and Shoots, that grow based on acquired value, roles, duties, skills, etc. Seeds can be a primitive across Kusama and beyond. People can create their Seed and their contributions across Kusama can be connected to it, which will sit on Kabocha and/or Kusama chain.
Seeds Zapp
How will XCM increase the capability of Seeds?
It is still very early in exploration, but for Seed functionality to be available across chains, most likely XCMP channels will need to be setup and XCM instructions designed (a Seed Zapp). Given that the concept of Seeds is emerging and intentionally undefined, these instructions will become clearer over time.
DEX
Kabocha also requires using XCM for DEXs. Whether we choose Karura, Mangata, or Basilisk (or all three at some point), then these channels need to be established.
Above we mentioned how XCM based cross-chain DApps aka “Zapps” can be created using Supsersig, Subscriptions and Seeds. But there are many other users. If we want to leverage the tools of other parachains then we would need to do so through XCM. Resonant projects such as Invarch, encointer, statemine, etc, can be leveraged to build Kabocha funded Zapps.
I do hope this article was informative and inspired ideas for the Kabocha and Kusama community.
Stay creative,
Ramsey(Decentration)
