The Mimir PolkaVM Alpha version is now live at pvm.mimir.global, currently supporting Passethub with the following features:
Currently Available:
-
Multisig creation
-
Multisig transaction management
-
Batch transactions
-
WalletConnect integration
Coming Soon:
-
Module support(Easy-Expense and Recovery)
-
Opt-in notifications
-
Nested multisig support
-
Pre-Compile(Staking/Opengov/Proxy etc.) support
Why does PolkaVM need multisig?
In the Ethereum ecosystem, leading DAOs and projects like Lido and BanklessDAO rely on multisig as a core tool for managing their assets. Given the significant capital involved, along with the need for both flexibility and programmability, multisig has become the most trusted and secure approach to asset management.
If PolkaVM aims to attract more capital, projects, and DAOs, a robust multisig solution is essential — as fundamental to the ecosystem as infrastructure like Uniswap.
What is Safe?
In the Ethereum ecosystem, Safe (formerly Gnosis Safe) has become the industry standard for multisig asset management. It currently secures over $5 billion in assets across more than 300,000 wallets, and is widely trusted by DAOs, protocols, and institutions. Its multisig contracts are among the most battle-tested and reliable tools for on-chain treasury management.
Safe’s Contract Structure
Safe is composed of two main layers:
-
Main Contracts: Including
SafeProxy
andGnosisSafe
, which handle the core multisig logic and transaction execution. -
Modules: Optional plug-ins that enable custom behavior such as social recovery, passkey login, or spending limits. These are often developed and maintained by the community.
For PolkaVM: More than just Porting Safe
Here, more than porting Safe refers to more than just deploying the smart contracts — it also includes adapting the Safe UX and Safe Service layers.
PolkaVM is not simply another EVM. Key differences impact how dApps — including Safe — are developed and deployed:
td {white-space:nowrap;border:0.5pt solid #dee0e3;font-size:10pt;font-style:normal;font-weight:normal;vertical-align:middle;word-break:normal;word-wrap:normal;}Aspect | EVM | PolkaVM | Potential Impact on DApp Development |
---|---|---|---|
Architecture Design | Stack-based virtual machine, operand stack | Hybrid of register + stack architecture, based on RISC-V CPU | Lower latency, closer to bare-metal execution, better performance |
Instruction Set | Fixed instruction set, stack operations | RISC-V based general-purpose instruction set | Richer and more flexible instruction set, supports better space and gas optimization |
Call Stack Depth | Up to 1024 layers | Shallower than EVM, typically around 5 | Limits deep contract nesting; contracts must be optimized for flatter execution trees |
Cross-chain Support | Mainly supports Ethereum L2s and rollups | Native support for Polkadot Hub scenarios and multi-chain contexts | DApps can access Polkadot’s full cross-chain capabilities, enabling native multichain |
Security Model | Mature and well-understood attack surfaces | Different from EVM due to architecture and boundary differences | Requires re-audit to align with PolkaVM-specific constraints |
Key Notes for Dapp Developer
-
Call Stack Depth Limitation PolkaVM has a significantly lower call stack depth compared to EVM. Deep recursive or layered calls may fail on-chain and must be flattened. Developers should optimize execution paths and manage resource usage carefully.
-
Register-Based vs Stack-Based Architecture Unlike the stack-based EVM, PolkaVM is more like a traditional CPU, using register-based execution. This reduces memory access latency but also means that contracts must be adapted to fit the new compilation and runtime model.
-
Tooling Maturity The EVM has a mature tooling ecosystem (e.g., solc, hardhat, truffle, ethers.js), while PolkaVM tooling (e.g., the Revive compiler) is still rapidly evolving. This makes debugging and testing potentially more challenging at this stage.
-
Cross-chain and Ecosystem Integration PolkaVM is deeply integrated with the Substrate framework, giving it native access to Polkadot’s cross-chain (XCM) capabilities. In the future, precompiles will include XCM support, enabling DApps to become multichain-native and interact across parachains more easily.
Migrating Safe UX: Ecosystem Habits Are Different
For existing ecosystem users, their usage habits aren’t shaped by PolkaVM alone — they also rely heavily on established Substrate account setups and commonly used features.
Account Structure: Proxy + Multisig
Compared to simple multisig wallets, Polkadot users tend to adopt a composite model that combines proxy accounts with multisig, with many even preferring proxy accounts as their primary method for secure asset management.In fact, 51% of the top 100 DOT holders use proxy accounts to enhance account security.
Proxy, as a Substrate-native capability, offers flexible delegation and execution logic. However, this functionality is not natively supported by Safe contracts and must be enabled through custom module development in order to accommodate Polkadot’s account architecture.
Popular Functions: OpenGov, XCM and Staking
Staking and XCM are currently among the most active transaction types in the Polkadot ecosystem. Meanwhile, OpenGov has become one of the most prominent and best practice in the network. These Substrate-native features remain critical even after PolkaVM is launched.
Roadmap Integration: Making Safe Polkadot-Friendly
According to the smart contract roadmap, EVM compatibility is just the first phase of PolkaVM. Future upgrades will include:
-
Cross-chain XCM support
-
Native integration with Pallets, allowing EVM-based accounts to participate in governance, staking, and other runtime-level activities
References:
To truly align with Polkadot’s long-term vision (see: Polkadot Hub), Solidity-based dApps will need more than compatibility — they must offer custom logic and interactions that match Polkadot’s design philosophy. A standard Safe UI designed for other EVM chains simply can’t meet those requirements on its own.
Conclusion
EVM compatibility is just the starting point for PolkaVM. In the long run, PolkaVM aims to go beyond Ethereum, delivering a smart contract platform optimized for Polkadot’s cross-chain future.
To support this, the network needs a secure, modular, and cross-chain–ready multisig solution — not just a contract migration, but an ecosystem-native experience. That’s the gap Mimir is working to fill.
What we need: A Polkadot-friendly Safe
PolkaVM’s smart contract roadmap goes far beyond basic EVM compatibility. It includes:
-
Native support for cross-chain messaging via XCM
-
Deep integration with Substrate pallets for runtime-level functionality like governance and staking
Ethereum compatibility is just the starting line. For dApps to truly succeed in the Polkadot ecosystem, they must be deeply integrated, not merely ported.
That’s why we need Safe’s battle-tested core contracts — but tailored for Polkadot. It’s not enough to bring them over as-is. They need to be reimagined to fit the Polkadot model and unlock its full potential.
What Mimir is Working On
Mimir has successfully deployed a fully functional version of the Safe contracts on PolkaVM, demonstrating that EVM compatibility within PolkaVM has reached a practical level. This milestone not only validates the feasibility of deploying mature Ethereum infrastructure on Polkadot, but also sends a clear signal: PolkaVM is ready for serious applications.
By bringing Safe’s proven security model into the Polkadot environment, Mimir aims to deliver a multisig solution tailored to the unique needs of this ecosystem.
Why Mimir?
Deep Familiarity with PolkaVM: Faster Deployment
As a native multisig solution in the Polkadot ecosystem, Mimir closely follows the technical development of PolkaVM. With a solid understanding of its design patterns and execution model, we have successfully deployed a fully operational Safe contract suite on AssetHub Westend. The deployed addresses include:
{
"DeterministicDeploymentProxy": "0x28d238E92184e99Ee948ebf31317f1279BBC3728",
"CreateCall": "0xd6cf29609A79c73660c19BAB8BC2Ee326c1Ca368",
"MultiSend": "0x124F1623c35467473090126599da93310DcC5Bf6",
"MultiSendCallOnly": "0xaB89915135Eb9b37cA208848f6fc7FAed67d98C7",
"DefaultCallbackHandler": "0x043ed58014Fc4D780375F8d8CAd8cbB1E3F9745d",
"CompatibilityFallbackHandler": "0xAbBc12760F05459A9e693cf123AaaE24838BaBfb",
"SimulateTxAccessor": "0x28617A999101801C6AB99fe7B70e204Df3CBe949",
"GnosisSafe": "0x161CF71d2BB559DD743BDaAe125672F1D25C7838",
"GnosisSafeL2": "0x03Cb7B46ea1Df21d299eebC8c42a1637b3a55851",
"GnosisSafeProxyFactory": "0x0344748785560fd53CFE5d74aD6aC5067d10c1f2"
}
This successful deployment proves PolkaVM’s growing EVM compatibility and sets the stage for onboarding new dApps in the testing phase — offering them a secure and familiar treasury infrastructure from day one.
Polkadot-SDK Expertise: Enabling Substrate ↔ EVM Interactions
Mimir has built complex asset workflows using proxy + multisig structures based on the Polkadot SDK. As Substrate accounts remain core to Polkadot, cross-account interaction between Substrate and EVM addresses is essential. With deep SDK experience, Mimir can quickly support transfers and operations across both formats.
Security First
Safe’s off-chain signature model is efficient but carries single-point-of-failure risk — as seen in the $1.5B Bybit incident. A secure ecosystem needs independent, verifiable multisig solutions. Mimir adds that critical redundancy, enhancing both user safety and overall ecosystem resilience.
What We’re Building
-
Safe contracts adapted specifically for PolkaVM
-
Multisig support that fits Polkadot’s complex account structures
-
Seamless interaction between Pallet-based logic and smart contracts
-
Cross-chain–capable multisig functionality for the Polkadot ecosystem
By combining Safe’s proven contract model with UX tailored to Polkadot’s unique patterns, Mimir is building a powerful and practical asset and governance solution for teams across the PolkaVM landscape.
We’d love to hear your thoughts — if you have any feature requests or ideas for how multisig on PolkaVM can better serve your use case, feel free to share them in the comments!