Should the multisig deposit and proxy deposit be reduced on the Polkadot network?

Dear Polkadot Community,

We are Mimir, a project dedicated to providing a user-friendly multisig management tool within the Polkadot ecosystem. During our development journey, we have identified certain barriers to multisig adoption due to high entry thresholds. Similarly, we are currently developing a Proxy module, which faces similar challenges. Through OpenGov, we hope to address these issues and gather valuable feedback from the community.

At present, initiating a multisig transaction on the Polkadot network requires a deposit of 20 DOT. Likewise, setting up a Proxy account also requires a 20 DOT deposit. Even with current DOT prices, this translates to around $80, and at historical highs, it could exceed $800. Although these deposits are refundable at a later point, users must still ensure they have sufficient balances to cover these initial costs, which could be a significant barrier.

From discussions with other multisig projects during Sub0, we have found that this deposit requirement is excessively restrictive. In recent years, more user-friendly multisig solutions, such as Multix, Signet, Polkasafe, and Mimir, have increased the adoption of multisig accounts (rising from fewer than 900 at the end of last year to nearly 1,300 now). However, the limitations of the underlying protocol prevent us from fully optimizing user accessibility.

We believe that multisig should not be a tool reserved only for those with substantial assets. In the Ethereum ecosystem, for example, 1/1 multisig accounts (total member = 1, threshold = 1) represent over 40% of all multisig accounts. These users simply want a more secure, contract-based account rather than one loaded with funds. On Ethereum, even average users can use multisig accounts at a relatively low cost, typically incurring only a transaction fee of a few cents to a few dollars.

Comparasion Between Polkadot And Ethereum


Regarding Proxy accounts, which have even broader use cases, a minimum of 20 DOT is also required. Until the proxy relationship is revoked, these 20 DOT remain in a reserved state and cannot be utilized. Currently, there is also a lack of tools that help users efficiently manage proxy relationships to reclaim these locked DOTs.

A similar issue exists in the Kusama ecosystem; however, due to price volatility, the current locking amount on the KSM network is approximately $10, which is significantly lower than on the Polkadot network. We propose initiating a “Wish For Change” proposal on the Polkadot network and, after gaining some momentum, presenting a similar proposal on the Kusama network.

Our arguments are as follows:

  1. The 20 DOT deposit requirement is a barrier for most users in the ecosystem: According to Subscan, there are 980,993 Shrimp Accounts in the Polkadot ecosystem, accounting for 71.9% of all accounts. These accounts each hold less than 15 DOT, effectively preventing them from utilizing multisig or proxy functionalities.

  2. New system parachains have already implemented more accessible deposit requirements: New system parachains, such as People and Assethub, have set multisig and proxy deposit requirements to around 0.2 DOT. This demonstrates that the need for a lower entry barrier is recognized, and we believe the Relay Chain should follow suit.

  3. Opportunities for innovation in account structures are being missed due to high costs: Projects like Safe are exploring account abstraction to provide users with more secure account architectures, as highlighted in this blog post: Building the Dream Wallet with Safe. While achieving such advanced account structures on Ethereum remains a distant goal, Polkadot can already accomplish this through combinations of Multisig, Proxy, and other functionalities. However, the high deposit costs are a significant deterrent to such innovation.

Our proposal is as follows:

Reduce the deposit for multisig and proxy accounts to ~0.2 DOT (in line with the Assethub parachain) and adjust it periodically based on DOT price volatility to keep costs within a reasonable range, thereby making these features accessible to more users.

multisig.depositBase 200,880,000,000 → 2,008,800,000

proxy.proxyDepositBase 200,080,000,000 → 2,000,800,000

proxy.announcementDepositBase 200,080,000,000 → 2,000,800,000

The above outlines some of the challenges we at Mimir have encountered while promoting multisig solutions, along with some suggestions that could enhance the diversity of accounts within the ecosystem and facilitate the smoother deployment of future proxy-related features.

We welcome feedback from the community and look forward to refining our proposal with your input. If you have any thoughts or suggestions, please feel free to respond here or contact me directly via:
Element: @wayward1989:matrix.org
Telegram: @gravitinyliu

1 Like

Aye, I also posted previously Lowering deposit base for multisig calls

Great! I hope that if it turns into a proposal, it will receive your support, helping the community better understand!!

1 Like

This is my personal opinion - but i think Proxy and Multisig shine when managing large funds. Setting up a proxy or multisig for an account with 15 DOT does not seem that useful to me.

Yes this is no coincidence. Parachains always have lower deposits, because they scale better than the relay. The result is an incentivise to setup the proxies and multisigs on a parachains.
Now, i am not sure how good the user experience is in this case. It should be possible to send XCM from a multisig on AssetHub to any other parachain. But building good UI for this is IMHO more important than trying to just reducing the deposit on the relay.
With a reduced relay deposit, people still want to use that multisig or proxy on parachains. So the problem remains.

1 Like

The fact that we have the largest activity on Polkadot happening on the relay, for now, tells me that if any type of account abstraction (AA) should be developed, it would be on the relay. Otherwise, the app/wallet will have no user and no traction. Now because AA on Polkadot involves proxy and multisig, having high deposits rules out any sort of wide usage de facto unfortunately. Unless ppl try it, and apps get users, they won’t know what they need. There is today no way to have a seamless experience with 1 account on say the asset hub (or even a proxy), and xcm everything from there. Wallets have never worked that way, I wonder if they will ever. Do you think this should be the way to go?

I completely agree with your point about how UI can drive the growth of multisig. In fact, since the introduction of more user-friendly multisig tools, especially from the second half of last year, there has been a noticeable increase in the creation of multisig accounts. It is clear that this is a viable path to solving the problem.


However, we cannot assume that a high deposit requirement won’t cause any issues(Include me). Data shows that most addresses are not eligible to use multisig and proxy, and within the community, there are users who are frustrated because they cannot find ways to retrieve relatively high deposits.
Perhaps the current DOT price, hovering around a low point, is still within a range that is acceptable for most people. However, we must also consider a potential future bull market, where the deposit requirement for DOT could become a significant barrier to adoption.
On the other hand, what obvious downsides would reducing the deposit have on the ecosystem? It does not affect the network’s revenue, and the broader adoption of multisig could facilitate improvements in account structures.

1 Like

Yes, I completely agree with your point. After all, the chain with the most activity (Polkadot) and chains with richer functionalities (like Acala, Bifrost, Hydration) are not unified, and this is clearly problematic. Currently, wallets and applications are not set up to do this, likely because the UI and technology cannot be unified to provide the optimal experience.
This might require a new Pallet to achieve such functionality, or perhaps a chain like Plaza that unifies all parachain functionalities into a single chain. Fortunately, Bifrost seems to be making some attempts in this direction with chain abstraction, and we hope more projects will embark on this journey.
We will also keep an eye on developments in this area and follow up with optimizations as needed.

1 Like