Safe's canonical singleton factory and proxy patterns are fundamentally designed for the Ethereum Virtual Machine. Deploying Safe on non-EVM infrastructure—such as Solana, Cosmos SDK chains, or Move-based networks—requires a departure from the standard CREATE2 factory deployment and delegatecall-based proxy architecture that defines Safe on EVM chains. These deployments typically take one of two forms: a full contract rewrite in the target VM's native language that preserves Safe's multisig logic and ownership model, or a canonical wrapper pattern where a minimal set of Safe interfaces is emulated to achieve address compatibility with EVM-based tooling. Neither approach achieves full parity with the EVM singleton's module, guard, and fallback handler architecture.
Alternative L1 and Non-EVM Deployment Registry
Understanding Safe on Non-EVM Infrastructure
A technical analysis of Safe smart account deployments on non-EVM chains, examining the architectural compromises, emulation patterns, and version parity risks that affect cross-chain integrators and wallet teams.
The operational impact for integrators is significant. A Safe deployed on a non-EVM chain will not support the same module interface as v1.4.1, meaning custom guards, recovery modules, and transaction relayers that depend on checkAfterExecution hooks or specific storage layouts will not function. Teams building cross-chain Safe tooling must verify, on a per-chain basis, whether the deployment supports EIP-1271 signature validation, whether the fallback handler pattern is preserved, and whether the execTransaction flow matches the EVM singleton's gas accounting and nonce management. Version parity is rarely maintained; a non-EVM deployment labeled 'Safe-compatible' may only replicate the v1.3.0 feature set or a subset thereof.
Chainscore Labs can assist teams navigating this fragmentation by auditing the behavioral equivalence of non-EVM Safe deployments against the canonical EVM singleton, reviewing cross-chain address determinism guarantees where CREATE2-like mechanisms are claimed, and assessing the security implications of emulated delegatecall or proxy patterns in VMs with different state models. For wallet teams, exchanges, and custody providers integrating Safe on alternative L1s, a deployment registry entry without a corresponding technical review represents an unquantified operational risk.
Deployment Registry Quick Facts
Operational facts for Safe deployments on chains that diverge from standard EVM execution, including emulation layers, wrapper patterns, and behavioral differences that affect integration.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Execution environment | Safe contracts may run on an EVM emulation layer or a non-EVM VM, altering gas metering, opcode support, and storage layout assumptions. | Protocol architects, wallet teams, and security auditors. | Verify that the execution layer fully supports the exact EVM version targeted by the deployed Safe singleton. |
Singleton version parity | Deployed singleton versions often lag behind canonical EVM releases (e.g., v1.3.0 instead of v1.4.1) due to emulation constraints. | Custodians, exchanges, and multi-chain dApps. | Check the deployed singleton version against the canonical registry for the chain and assess missing features like EIP-1271 or module hooks. |
Proxy determinism | CREATE2 address determinism may break if the chain uses a different bytecode commitment scheme or genesis state for the factory. | Multichain operators deploying Safes at the same address across chains. | Do not assume cross-chain address parity without verifying the factory deployment transaction and chain id. |
Fallback handler compatibility | The standard fallback handler may rely on EVM-specific precompiles or opcodes that are absent or behave differently in emulation. | Wallet integrators and relayer services. | Test token callbacks, EIP-1271 signature flows, and transaction simulation on the target chain before enabling them in production. |
Module and guard execution | The checkAfterExecution hook and module transaction flows depend on precise gas forwarding and delegatecall semantics that emulators may not replicate. | Module developers and guard authors. | Audit module behavior under the chain's specific execution model, especially for cross-chain message verification patterns. |
Transaction relaying | Gas estimation and transaction submission may fail if the relayer's EVM assumptions do not match the chain's execution quirks. | Relayer operators and wallet UI teams. | Integrate chain-specific gas estimation logic and test multi-signature execution flows end-to-end. |
Indexing and event logs | Event signatures and log generation may differ if the chain modifies the EVM's LOG opcode behavior or receipt structure. | Data teams, indexers, and analytics providers. | Validate that Safe transaction events are emitted and indexed correctly for the chain's block explorer and subgraph infrastructure. |
Canonical deployment verification | The official Safe deployment registry may not include the chain, leaving teams to rely on community or self-verified addresses. | All integrators and operators. | Cross-reference deployment addresses with Safe's canonical sources and verify contract bytecode independently before integrating. |
Emulation Patterns and Technical Compromises
Safe deployments on non-EVM chains require emulation or wrapper patterns that fundamentally alter security assumptions, execution guarantees, and cross-chain behavioral parity.
Safe's core contract suite is designed for the EVM execution environment, relying on precise gas accounting, delegatecall semantics, and storage layout guarantees that do not directly translate to non-EVM runtimes. When Safe is deployed on chains like Solana, TON, or Starknet, the canonical Solidity contracts cannot run natively. Instead, teams must choose between two compromise paths: a canonical wrapper pattern where a native smart account implements Safe-compatible signature verification and state management, or a full EVM emulation layer that runs the original Safe bytecode inside a zkVM or interpreter. Both approaches introduce trust assumptions and behavioral differences that integrators must model explicitly.
The canonical wrapper pattern, used in early Solana and TON deployments, reimplements Safe's multisig logic in the chain's native execution environment. This preserves native performance and composability but breaks bytecode-level audit equivalence with EVM deployments. Signature verification, nonce ordering, and module execution flows must be manually ported and verified against the EVM reference implementation. The emulation approach, explored in zkVM-based environments, preserves bytecode identity but introduces a new trust assumption: the emulation layer itself must correctly interpret EVM opcodes, precompiles, and state transitions. A bug in the emulator becomes a bug in every Safe deployed on that chain.
For operators and integrators, the critical risk is behavioral divergence under edge conditions. A Safe on Solana may handle checkAfterExecution hooks differently than on Ethereum mainnet, or a TON wrapper may process multi-signature threshold logic with subtle ordering differences. Wallet teams building cross-chain Safe tooling cannot assume that a transaction that succeeds on one chain will produce identical state transitions on another. Chainscore Labs provides protocol impact assessments that map these divergence points for specific chain deployments, helping teams identify where emulation compromises create integration risks and where additional verification logic is required before deploying capital or connecting to cross-chain infrastructure.
Who Is Affected
Multisig Operators
Teams managing Safe treasuries on non-EVM chains face degraded security guarantees. Emulation layers or wrapper patterns often lack full bytecode equivalence, meaning opcode-level differences can alter transaction execution outcomes.
Immediate actions:
- Verify whether your chain uses a canonical EVM emulation (e.g., Aurora on NEAR) or a custom wrapper.
- Test signature validation edge cases, especially EIP-1271 compliance, which frequently breaks in emulated environments.
- Confirm that the fallback handler and module execution hooks behave identically to mainnet v1.4.1.
Chainscore can audit your specific deployment's behavioral parity against canonical Safe contracts and flag silent failure modes before they affect production treasuries.
Integration Impact Areas
Teams integrating Safe on non-EVM chains must account for architectural compromises, emulation-layer risks, and version parity gaps that do not exist on canonical EVM deployments.
Emulation-Layer Trust Assumptions
Non-EVM deployments often rely on emulation layers or wrapper contracts to simulate EVM bytecode execution. This introduces a new trust dependency on the correctness of the emulator itself. A bug in the emulation layer can break Safe's core security invariants—such as signature validation or threshold enforcement—without any failure in the Safe contracts. Integration teams must model the emulator as a critical dependency and verify its security model against the canonical EVM execution environment.
Signature Validation and Cryptography Mismatches
Chains using non-ECDSA signature schemes (e.g., Ed25519 on Solana, BLS on some appchains) cannot natively validate Safe's EIP-1271 signatures. Integrations must bridge this gap through precompile emulation or off-chain signature verification. This creates a mismatch between on-chain validation logic and the signing behavior expected by Safe's off-chain services and relayers. Wallet teams must verify that their signing stack produces signatures compatible with the chain's emulated precompile behavior.
Singleton Version Parity and Feature Gaps
Non-EVM deployments frequently lag behind the canonical v1.4.1 singleton, missing critical features like the checkAfterExecution hook or updated fallback handler logic. This creates a fragmented security posture where Safes on alternative chains lack the same module and guard protections. Operators must maintain a chain-specific feature matrix and assess whether missing hooks expose them to reentrancy or access-control risks that have been patched on mainnet deployments.
Cross-Chain Address Determinism Failures
CREATE2-based address determinism does not function identically on non-EVM chains due to differences in address derivation, bytecode commitment schemes, or factory contract initialization. Teams attempting to deploy Safes at matching addresses across EVM and non-EVM chains may encounter collisions, deployment failures, or unexpected address mismatches. Multichain operators must validate address derivation logic against the specific chain's virtual machine semantics before assuming cross-chain address parity.
Transaction Relayer and Indexer Compatibility
Safe's transaction service, Gas Station, and relayer infrastructure are built around EVM transaction formats, gas accounting, and event logs. Non-EVM chains may use different transaction structures, fee markets, or log indexing mechanisms. Integrators must assess whether the chain's RPC interface and indexing services can support Safe's transaction lifecycle—including nonce management, gas estimation, and event decoding—or whether custom middleware is required.
Module and Guard Execution Environment Differences
Modules and guards written for EVM Safes rely on specific opcodes, storage layouts, and gas metering that may not translate cleanly to a non-EVM runtime. Even with emulation, edge cases in storage access, delegatecall semantics, or gas limits can cause modules to behave differently. Security auditors must test module logic against the actual chain runtime, not just the EVM reference implementation, to catch environment-specific failure modes.
Risk Matrix for Non-EVM Safe Deployments
Evaluates behavioral differences, trust assumptions, and operational risks for Safe deployments on non-EVM or EVM-incompatible chains using emulation or wrapper patterns.
| Risk Area | Failure Mode | Severity | Mitigation |
|---|---|---|---|
Signature Verification | Emulated ECDSA or contract signature checks may not match canonical EIP-1271 behavior, leading to invalid signature acceptance or rejection. | Critical | Verify signature validation logic against the canonical Safe v1.4.1 implementation. Conduct differential fuzz testing between the EVM reference and the target environment. |
Cross-Chain Address Determinism | CREATE2 deployment may produce a different address or fail due to chain-specific opcode behavior or gas scheduling. | High | Do not assume counterfactual address parity. Verify the deployed singleton and proxy factory addresses against the canonical registry before integrating. |
Delegatecall Semantics | The emulated environment may handle delegatecall context, storage layout, or gas forwarding differently, breaking module execution or upgrades. | Critical | Audit the proxy upgrade path and module execution flow. Test state integrity after any delegatecall-based operation, including fallback handler changes. |
Gas Accounting and Transaction Simulation | SimulateTxAccessor or relayer gas estimations may be inaccurate due to different metering, causing out-of-gas failures during execution. | Medium | Relayer and wallet teams must recalibrate gas estimation models. Test multi-signature execution with maximum signers under worst-case gas conditions. |
Module and Guard Compatibility | Modules relying on EVM-specific opcodes or precompiles will fail. The checkAfterExecution hook may not fire correctly. | High | Module developers must verify compatibility. Do not assume existing EVM modules are safe to use. Chainscore can review module logic for environment-specific failure modes. |
Fallback Handler Behavior | Token callback and domain separator logic in the fallback handler may not function, breaking ERC-721/1155 support and dApp interactions. | Medium | Test all token standard callbacks. Verify that the Compatibility Fallback Handler works as expected if supporting legacy Safe versions. |
Indexing Service Dependencies | Standard Safe indexing services may not track the non-EVM chain, leading to missing transaction history or incorrect nonce tracking for integrators. | Operational | Wallet and custodian teams must verify indexing support. Plan for self-hosted indexing or alternative transaction history sources. |
Operator Verification Checklist
A technical checklist for operators and integrators to verify the integrity, version parity, and behavioral correctness of a Safe deployment on an alternative L1 or non-EVM chain. This process confirms that the emulation layer or canonical wrapper does not introduce state divergence, signature incompatibility, or security gaps relative to the canonical EVM singleton.
Confirm that the deployed Safe contracts match the official registry for the specific chain. This is the root of trust for all proxy interactions.
- What to check: The singleton address, proxy factory address, and fallback handler address against the official
safe-deploymentsrepository or a chain-specific Safe documentation page. - Why it matters: A mismatched or unofficial deployment could be a malicious copy or an outdated version with known vulnerabilities. For non-EVM chains, the deployment may use a wrapper contract; you must verify the wrapper's address and its linkage to the canonical bytecode.
- Confirmation signal: The deployment transaction hash on the target chain resolves to the exact bytecode expected, and the addresses are explicitly listed in the Safe community's canonical registry for that chain.
Canonical Resources
Use these resources to verify whether a Safe deployment on an alternative L1, EVM-incompatible chain, or emulated environment is canonical, compatible, or only ecosystem-maintained.
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
Frequently Asked Questions
Common questions from protocol architects and wallet teams evaluating Safe deployment on non-EVM or EVM-incompatible chains through emulation or canonical wrapper patterns.
A non-EVM deployment refers to a Safe smart account implementation on a chain whose execution environment is not natively compatible with the Ethereum Virtual Machine. This typically involves one of two patterns:
- Canonical Wrapper Pattern: A Rust, Move, or Cairo implementation that mirrors the Safe singleton's logic and storage layout, adapted to the target VM's idioms while preserving the same ownership, threshold, and module semantics.
- Emulation Layer: A precompile or system contract that interprets EVM bytecode, allowing the standard Solidity Safe contracts to run with minimal modification.
Teams should verify which pattern a given chain uses, as it directly affects gas accounting, storage layout guarantees, and cross-chain behavioral consistency.
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.