Safe Wallet on zkSync and StarkNet: Native Account Abstraction and Embedded Multisig

The multisignature wallet has long been a workaround solution. Organizations, DAOs, and Web3 treasuries deploy separate smart contracts to require multiple approvals before transactions execute, adding a layer of security and governance on top of single-key account models that blockchains have historically enforced. Safe Wallet, formerly Gnosis Safe, pioneered this approach on Ethereum and has become the dominant standard for shared custody across EVM-compatible chains. Yet the emergence of zkVM platforms such as zkSync and StarkNet introduces a different model: account abstraction built into the protocol itself, where multisignature logic and other advanced authorization schemes can exist natively without requiring a separate wrapper contract.

That architectural shift has immediate implications. If a blockchain supports native account abstraction at the protocol layer, the practical need for a separate multisignature wallet application diminishes. A user or organization can define authorization rules directly within their account without deploying additional code, paying redundant gas fees, or managing a second smart contract. The question is not whether Safe or similar solutions will disappear entirely, but rather how the economics and user experience will change when multisig functionality is no longer an add-on, and how traditional EVM wallet designs will adapt to compete on chains where account abstraction is native rather than optional.

How Safe Wallet currently solves the multisig problem on EVM chains

Ethereum and most EVM-compatible blockchains treat user accounts in a fixed way: a single private key controls transactions through cryptographic signatures. This model is simple, but it offers no native way to require multiple approvals, rotate signers gradually, or define conditional logic before a transaction is executed. Safe Wallet solves that constraint by deploying a smart contract that acts as the actual custodian of funds. The contract holds tokens and assets, while a configured set of signers must approve transactions before the contract will execute them. That separation between the account that holds funds and the accounts that approve their movement is the core innovation.

The operational sequence remains straightforward for users. A signer connects their wallet—any compatible Web3 wallet—to the Safe interface, verifies the multisig contract’s address, and can then propose or approve transactions. Once a threshold of approvals is reached, typically a 2-of-3 or 3-of-5 configuration, any signer can execute the transaction by broadcasting it to the blockchain. The security model rests on the quality of the underlying smart contract code, the arrangement of signers, and the correct management of recovery and emergency procedures. An EVM wallet used for signing remains distinct from the multisig contract itself; the wallet provides the cryptographic proof, while the multisig contract enforces the approval rule.

This architecture has proven robust and has become the standard for DAOs, protocols, and teams managing shared treasuries. Safe Wallet’s widespread adoption means that tooling, integrations, and operational procedures have matured. Organizations can rely on established best practices for signer rotation, time-locks, transaction queues, and emergency recovery. The drawback, however, is efficiency. Every multisig transaction requires multiple approvals, each of which involves a separate on-chain action. Transaction costs accumulate, and the entire system depends on a separate piece of code that must be audited, maintained, and upgraded independently from the base layer protocol.

Account abstraction at the protocol level: zkSync and StarkNet’s native model

zkSync and StarkNet take a fundamentally different approach by building account abstraction into the protocol itself. Rather than requiring users to deploy a separate contract to handle advanced authorization, these chains allow any account to define custom validation logic as part of its core account structure. A user or organization can specify that their account requires three approvals before executing a transaction, can implement time-locks, can rotate signers, or can enforce spending limits—all without deploying a separate smart contract wrapper.

The technical benefit is considerable. A transaction on an account-abstraction-native chain does not need to distinguish between a “user operation” and a “contract call.” Instead, the protocol validates the transaction using whatever logic the account has defined, whether that is a single ECDSA signature, multiple signatures, a threshold scheme, or even a custom cryptographic proof. The account itself is the authority, rather than outsourcing that responsibility to a secondary smart contract. For an EVM wallet accustomed to standard single-signature accounts, the shift requires rethinking how security and governance work.

StarkNet’s StarkAccount and zkSync’s native account abstraction implement this at different levels of abstraction, but both achieve the same outcome: multisignature logic, spending controls, and advanced authorization rules become properties of the account itself, not additional smart contracts layered on top. A multisignature wallet in this context is not a separate deployment but a configuration of the account’s validation rules. The distinction may seem technical, but it has profound implications for cost, complexity, and how security is built and maintained.

Why separate multisig contracts become redundant on account-abstraction chains

The primary reason Safe-like solutions become unnecessary on account-abstraction-native chains is redundancy. If an account can natively require multiple signatures before execution, adding a second smart contract that also enforces multisig rules wastes gas, creates operational friction, and introduces an additional attack surface. A user would be paying to validate twice: once at the account level and once at the contract level. That is economically irrational.

The secondary reason is simplicity. A traditional EVM wallet user must deploy a Safe multisig contract, configure it, and then interact with it through a separate interface. On a chain with native account abstraction, the same user simply configures their account’s authorization rules during account creation or later through a protocol-level operation. There is no separate contract to manage, no need to teach team members how to interact with a specific Safe interface, and no risk of misconfiguring a separate smart contract. The functionality is part of the account itself.

However, “redundant” does not mean “never used.” An organization might still deploy a traditional Safe-like contract on a zkSync or StarkNet account if they need additional features—such as module plugins, specific governance structures, or integration with existing Safe infrastructure—that go beyond the account’s native capabilities. But the default case, and the case that drives adoption, is to use the native mechanism. An ordinary DAO that needs three-of-five approval can configure their account without deploying additional code.

The third consequence is that Safe multisig wallet products must evolve or risk obsolescence on these chains. Safe’s value proposition on Ethereum rests partly on being the only way to achieve multisig custody at reasonable cost and reasonable complexity. On account-abstraction-native chains, that moat disappears. If Safe wants to remain relevant on StarkNet or zkSync, it must offer something beyond basic multisig: superior governance interfaces, module ecosystems, institutional features, or tight integration with DeFi protocols.

The economics of multisig on traditional EVM versus account-abstraction chains

Gas costs illustrate the difference clearly. A multisig transaction on Ethereum using Safe typically requires multiple on-chain approvals before the final execution. That might involve three separate transactions: a proposal, two approvals, and then the execution. On a fully packed Ethereum block during network congestion, each transaction could cost $50 to $500 in fees. For a DAO that executes dozens of transactions weekly, the cost of Safe adds up quickly.

On a chain with native account abstraction, the equivalent operation can be designed to cost a fraction of that. The multisig validation logic runs as part of the account’s built-in validation, not as separate contract calls. A properly optimized implementation might reduce costs by 50–80%, depending on the chain’s gas model and validation scheme. For organizations managing large treasuries, that efficiency gain justifies the migration even before considering other improvements.

StarkNet’s Cairo-based execution model and zkSync’s high throughput also affect the equation. An EVM wallet designed for Ethereum cannot always port efficiently to these chains because the underlying execution model differs. Traditional EVM wallet design assumes sequential execution, specific gas pricing, and opcodes that may not map cleanly to Cairo or zkVM instruction sets. A solution built natively for account abstraction can take better advantage of the chain’s specific strengths, such as StarkNet’s parallel execution or zkSync’s compression benefits.

Organizations evaluating a treasury management solution should compare the total cost of ownership. On Ethereum, deploying and maintaining a Safe multisig is the standard approach, and costs are well-understood. On StarkNet or zkSync, native account abstraction offers lower fees and better integration with the chain’s architecture. The tradeoff is that fewer organizations have operational experience with account-abstraction-native multisig, and tooling is less mature. For a risk-averse organization, the established Safe workflow may remain preferable despite higher costs.

How user experience and authentication will shift

On Ethereum and traditional EVM chains, a user must go through several steps to participate in a multisig. First, they deploy or identify an existing Safe contract, configure signers, and set the approval threshold. Then, to use that Safe, they connect a compatible Web3 wallet—MetaMask, Ledger, or similar—via wallet-based authentication. The Safe interface reads their wallet address and verifies whether that address is a configured signer. If it is, the user can propose or approve transactions. The separation between the wallet and the Safe contract is clear but adds friction.

Account-abstraction-native chains can streamline this. A user sets up their account with multisig authorization rules during account creation. When they connect to an application or protocol, their account naturally enforces those rules without needing a separate Safe interface. The application does not need to know whether the account is multisig or single-key; it submits a user operation, the account’s validation logic authenticates the operation, and execution proceeds if validation passes. From the application’s perspective, multisig is invisible—it is simply how this particular account validates transactions.

That transparency has implications for blockchain wallet design. An EVM wallet that currently supports connecting to Safe contracts must evolve to support account-abstraction-native multisig. The wallet’s role shifts from being a signing tool for a separate multisig contract to being part of the account itself. A signer in a multisig account on StarkNet would use a compatible wallet to sign the operation, but the account itself manages the threshold logic rather than outsourcing it to a secondary contract. The user interface may look similar, but the underlying mechanics change significantly.

When Safe-like functionality remains valuable even on account-abstraction chains

Despite the efficiency advantages of native account abstraction, traditional multisig contracts will not disappear from zkSync, StarkNet, or other emerging chains. Several scenarios justify their continued use. First, institutional organizations may need modular governance features that exceed the account’s native capabilities. Safe offers plugins, delegation patterns, and governance modules that allow sophisticated authorization structures. If an organization needs conditional approvals based on transaction type, amount, or time, they might implement this more easily through a modular contract than by reconfiguring their account repeatedly.

Second, cross-chain bridges and custody solutions may require a SafeWallet-compatible interface for compatibility with existing infrastructure. A protocol that manages treasuries across Ethereum, Arbitrum, Optimism, and zkSync might continue using Safe on all chains for consistency, even if zkSync’s native account abstraction would be more efficient. Standardization across chains can be worth a cost premium if it reduces operational complexity and training burden.

Third, legacy systems and audited deployments create path dependency. An organization running a Safe multisig that has been audited and operational for years may not migrate to a native account-abstraction solution even if it is more efficient. The cost of migration, the risk of misconfiguration, and the sunk investment in procedures and training often outweigh the efficiency gains. This is especially true for risk-averse organizations managing large treasuries.

The integration path for Safe Wallet and competitors

Safe and similar platforms face a choice: adapt or decline on account-abstraction-native chains. One adaptation strategy is to offer native account abstraction configuration tools—interfaces that help users set up multisig authorization rules directly on the protocol layer without deploying a separate contract. Safe could position itself as the governance and multisig experience layer, allowing users to configure their accounts’ authorization logic through Safe’s familiar interface, even when that logic runs natively on the chain.

Another strategy is to build additional modules and features that add value beyond basic multisig. Safe’s existing module system allows extensions such as spending limits, recurring transactions, recovery mechanisms, and conditional approvals. On a chain with native account abstraction, Safe might offer the same modules—but they would integrate with the account’s native validation rather than requiring a separate contract. This would let Safe maintain relevance by being the most powerful and flexible governance layer, not by being the only way to achieve multisig.

Competitors entering the account-abstraction space have the advantage of building natively from the start. A new blockchain wallet designed specifically for StarkNet or zkSync can assume native account abstraction and optimize the user experience accordingly. They avoid the constraint of maintaining compatibility with older EVM-based designs. However, they also lack the established reputation and operational maturity of Safe. For many organizations, especially those already using Safe on Ethereum, migration to a new platform carries significant switching costs and risks.

The resolution likely involves coexistence. Safe will continue to dominate multisig on traditional EVM chains where its architectural advantages are clear. On account-abstraction-native chains, Safe may shrink to serving organizations that benefit from its modular ecosystem and cross-chain consistency, while native solutions capture the majority of new users and deployments. The Safe multisig wallet login experience will need to adapt to support both paradigms—traditional separate contracts on some chains and native account abstraction on others.

The broader implication: Decoupling wallet design from account model

The shift from separate multisig contracts to native account abstraction illustrates a broader trend in blockchain development: decoupling the wallet interface from the underlying account model. On Ethereum, wallet and account have been tightly coupled. An EVM wallet generates a single-signature account, and multisig requires a secondary smart contract. On account-abstraction-native chains, that coupling breaks. An account can have any authorization logic, and a wallet is simply the client that signs on behalf of the account.

This decoupling opens possibilities that traditional EVM design does not support. An account could require different authorization rules for different transaction types. It could implement time-delays for large transactions and instant execution for small ones. It could support account recovery mechanisms, signer rotation, and spending limits without deploying additional contracts. All of this becomes possible when the account itself is programmable rather than being a fixed function of a single key.

For users, the implication is that wallet choice becomes less about security and more about user experience and interface. Two wallets might interact with the same account abstraction rules, but one provides a better interface for configuring thresholds or viewing transaction history. This shifts competition from architecture to usability. Wallet developers must innovate in interface design, integration with DeFi protocols, and support for advanced account features rather than simply implementing the most secure single-signature scheme.