Kusama 2025: Private DAOs, regional chains, LIP and more

[olanod]

A quick recap before my Kusama 2025 ToDo list
Virto is one of the very few teams building exclusively on Kusama with the help of its treasury, I started Virto with the idea of implementing the Local Incentives Protocol, LIP defines a way for local communities to receive “contributions” from commercial communities every time anyone pays for a product or service. Contributions are like a tax that incentivizes the creation of the local DAOs empowered to improve local welfare.

I imagine LIP as an experiment part of the yet bigger experiment of re-imagining world societies built as a swarm of intelligent/integrated decentralized autonomous societies(IDEAS?) that move wealth around efficiently with dynamic tax policies changing by the minute and specific goals in mind ram

With all this anarchist long term experimentation in mind what better place to build than the most decentralized resilient cypherpunk corner of the web3
Virto felt right at home in Kusama where we’ve been slowly building the many pieces of this puzzle…

… client libraries, payment system, a DAO Hub, token-less economics and more goodies that make UX great on the Kreivo parachain.

A sustainable success case in Kusama?

It’s great to build for the long term but our very down-to-earth team knows we need intermediate deliverables that bring utility today, to the regular folks we want this technology to benefit. Virto is enabling entrepreneurs not familiar with blockchain technology to set up their organization in minutes and provide them with the tools they need to iterate fast to achieve product market fit at a fraction of the cost.

We are glad to share that as of now Virto is sustainable(*in a poor way), we closed 2024 and started 2025 with brave beta testers that already see benefit in the technology and are willing to pay for the value it provides in its early state.
We’ve got a pilot of an on&off-ramps operation moving 200K+ USD/month, the yield bearing Decent stable coin(dUSD) issued by the regulated stable coin provider Brale and managed by the Decent Partners DAO, the Neotec grant recipient Kunveno building a technology for freelancers and taking with EU regulators about DAOs, some regional communities in the ecosystem looking to establish their own OpenGov enabled DAO and several more use cases we will be sharing over the course of 2025 that will enable us to keep evolving the protocol and attract even more real world use cases.

[olanod]

Regional parachains: a fast global payments network

In 2025, Virto will evolve the initial architecture of LIP to introduce regional parachains - specialized chains optimized for local transactions and everyday user interactions. The close geographical proximity of collators will allow us to optimize for fast block production for better UX allowing for example end users doing fast secure reversible dUSD payments in stores from their phone or smart watch without relying on Visa/Mastercard infrastructure.

Architecture Overview

• Kreivo as the Governance Hub: Kreivo remains the central governance parachain where all DAO activities occur. It retains control over the root origins of regional chains, ensuring coordinated ecosystem development.
• Regional Chain Operations:
  • Optimized for fast block production through geographical proximity of collators
  • Enables near-instant transactions for real-world use cases (e.g., point-of-sale payments)
  • Implements the Pass system for wallet-less transactions
  • Handles all end-user interactions, keeping Kreivo focused on DAO operations

Geographic Organization

• Regions are defined using larger geographic cells than the original LIP communities
• Each regional parachain acts as a super-DAO governed by its constituent communities
• Regional chains can mint and manage smaller geo cells for local community registration
• This hierarchical structure enables efficient coordination between regional and local governance

Membership and Access

• Memberships continue to be minted on Kreivo
• Users can transfer their memberships to their local regional chain
• The membership NFT’s “gas tank” enables free transactions on the regional chain
• Regional chains implement the Pass system for simplified user authentication

Governance Structure

• Regional chains operate without local governance or sudo access
• All governance actions occur through Kreivo via XCM
• Communities within a region can participate in their regional chain’s governance through their DAO on Kreivo

[olanod]

Private DAOs with VOS

As Kusama positions itself as the privacy-focused canary network, we’re excited to advance this vision with VOS (Virto/Virtual Operating System) - a new privacy layer for Kreivo DAOs. Built on tech like Noir for zero-knowledge proofs and Matrix for encrypted messaging and data storage, VOS lets organizations vote and manage funds privately while staying decentralized. By 2025, Kusama-native DAOs will be able to handle sensitive operations and data without compromising on decentralization or compliance, strengthening the network’s commitment to privacy-first innovation.

Architecture Overview

• Virtual Operating System Components:
  • WASI component runtime for portable computation
  • Noir program support for zero-knowledge proofs
  • Familiar ink!-like interface for both WASI and Noir programs
  • Matrix protocol integration for secure messaging and storage

Private Governance MVP

• Zero-knowledge voting system:
  • Members cast votes privately using Noir contracts
  • ZK proofs enable anonymous vote verification
  • Kreivo updates referenda tallies based on verified proofs
  • Preserves voting power verification without revealing individual votes

Enhanced Privacy Features

• Private Balance Management:
  • DAOs act as privacy-preserving token pools
  • Internal ledgers maintained off-chain in encrypted form
  • Cross-DAO transfers visible only at organization level
• Secure Data Handling:
  • GDPR-compliant storage through Matrix integration
  • Encrypted messaging for sensitive DAO communications
  • Private state management separate from public blockchain

Future Integration with JAM

Looking further ahead, VOS’s ability to compile to PolkaVM and run “regular std programs”, it opens exciting possibilities for integration with JAM. As more DAO operations move to private contracts, VOS could evolve beyond its role as a Kreivo companion into a native JAM service, streamlining private organization management without the overhead of traditional Substrate runtimes.
We’re excited to develop these ideas together with the community - reach out on Matrix or join the Virto DAO to help shape the future of private, decentralized organizations

[brenzi]

@olanod

As Kusama positions itself as the privacy-focused canary network, we’re excited to advance this vision with VOS (Virto/Virtual Operating System) - a new privacy layer for Kreivo DAOs. Built on tech like Noir for zero-knowledge proofs and Matrix for encrypted messaging and data storage, VOS lets organizations vote and manage funds privately while staying decentralized

this is interesting indeed. Do you see synergies with Incognitee’s private messaging? In contrast to Matrix it allows to message wallet addresses directly and privately with much less metadata leaking. It’s live, try it!.

[olanod]

Will look into it we don’t have the requirement to message wallet addresses as we want users to not care about blockchain addresses but I wouldn’t lock ourselves into a specific kind of messaging protocol or encrypted storage. Matrix is great for our current needs but always open to other possibilities

[olanod]

I’ve been asked about VOS, our SDK and other aspects of our architecture, I apologize Virto doesn’t have much documentation at the moment but with our limited resources we are more focused on working directly with our initial use cases instead of attracting developers at this early stage, but I’ll use this thread to expand more on some topics and use it as reference for future documentation

Expanding the ink! familly

As part of the ink!alliance I’m sharing with the members ideas on how the ink! family could grow in the future, zink!(for zero-knowledge) would be this ink-like dialect for Noir that enables private contracts and then there is wink!(for wasm/wasi/web/worker) that could have a future variation for JAM(jink!?). Here’s my copy-pasted response of a chat trying to explain concept:

For a long while I’ve been quite exited about WASI and have followed its development. WASI components have a nice dev experience(e.g. just compile a normal rust std app to wasi and run) and I’ve been looking into ways to bring that to our ecosystem.

A simple way to bring WASI to Polkadot is with off-chain “helpers”, regular backend programs/bots that do things like aggregate on-chain data or react to events to send transactions, run an LLM to send an email/chat, etc. … regular stuff people already do. However If you are already in the ecosystem writing ink! contracts, there’s little mental overhead if developing your bot can be done with the same interface you are already used to, that’s wink!, packing the boilerplate of a simple server/cli that writes to the filesystem or a database and make it look like an ink contract.
Since a wink! program is a regular WASI program you can just do wasmtime run bot.wasm and it works. More interesting though, is to enhance the wasm runtime to allow multiple kinds of WASI programs be composed and run together and possibly provide different implementations of the WASI APIs to for example change the meaning of what opening a file or creating a socket is, e.g. creating virtual filesystems that abstracts some capability, similar to how in unix systems everything is a file and you can mange some hardware simply by writing to a file. This enhanced wasm runtime is pretty much what our virtual OS(VOS) should be.

Obvious side note, I like Rust, I wouldn’t even bother with Polkadot if it wasn’t written in Rust and if I could(and I try hard) I’d make sure every piece of software I interact with is open source Rust This lead me to tinker with embedded Rust early and since I like WASM+WASI of course I also tried to mix the two Fast forward a bit and an interesting recent development made me revisit the topic, wasmtime now supports being compiled to no_std, with some “restrictions” I actually found quite interesting, wasm programs need to be pre-compiled to the target architecture, but what if the target architecture is another VM? it sounds like a way to transpile bytecode from one VM to another, in this case I saw it as a way to bring WASI components running on VOS and their better developer experience to the still infant world of PolkaVM and by extension to JAM.

jink! is just the conceptual idea of said WASI programs running on JAM, although WASI components allow defining domain specific interfaces, ideally the hypothetical jink! programs shouldn’t need new JAM specific interfaces, so just regular wink! programs that magically run in this new world computer.
I like to believe that we will get good at abstracting web3/blockchain related concepts and bury them under interfaces and paradigms most developers already know, not tell people they need to learn something new every time. In JAM’s context, VOS can be the abstraction layer that gives meaning to simple concepts like opening a file, querying a DB, painting some pixels in a screen, doing AI with wasi-nn, etc. The important bit is that it needs to remains simple and transparent for the developer even if under the hood there’s complex coordination of multiple external systems that submit work to JAM and do other things.

VOS and the ink! dialects would all be part of this bigger initiative that we’ll pack as the VirtoSDK which would of course integrate well with Kreivo, hopefully it can become an easy alternative for developers(and AIs) to bring new real-world use cases to the ecosystem without much hassle.