💳Accounts
Last updated
Last updated
Mimir aims to be the launcher for users in the Polkadot ecosystem, therefor Mimir's account design is more aligned with the Polkadot ecosystem. Unlike Safe, extension wallets and multisig wallets will be on the same level in Mimir.
Once a user selects an account, all subsequent transactions and application accesses will be conducted under that account as the main entity.
Currently, the account entities we support include: Extension Account, Static Multisig, and Flexible Multisig.
Mimir allows interactions with all single-signature accounts in the Polkadot ecosystem extension wallets. Currently, we support Polkadot.js, Subwallet, and Talisman. All accounts in the extension wallets authorized by the user will be displayed under the Extension Wallet section.
Users can access applications in Dapps using this wallet and interact with them using the extension wallet as the main entity.
Some quick operations, such as transfers, can also be easily completed.
In Mimir, multisig accounts are currently offered in two forms: Static Multisig and Flexible Multisig. They share some common rules:
Mimir supports multisig wallets as members of another multisig, which can greatly expand the real-world business scenarios of multisig.
The created multisig is visible to all multisig members (including members of nested multisigs).
If a member user needs to operate on a particular multisig (including initiating and approving transactions), please select that multisig in the account options.
A, as a multisig account, wants to send 10$DOT to B. C is a multisig composed of E and F, and A is a multisig composed of C and D. E, F, and D are all single-signature accounts.
If the user holds accounts E or F, after logging into Mimir, they can enter multisigs A and C.
If the user holds account D, after logging into Mimir, they can enter multisig C.
Static Multisig is generated based on the Multisig Pallet, which is a native Pallet of Substrate.
Its advantages are:
During the creation process, users do not need to pay any fees.
It only needs to be created once and can be shared across the entire Polkadot ecosystem.
Users will get the same address as long as they create it based on the same threshold and members.
Its disadvantage is:
Once created, the members and threshold cannot be changed.
Reference:
Flexible Multisig is an account type formed by the combination of the Proxy Pallet and the Multisig Pallet. Essentially, it is a Pure Proxy with only one Static Multisig acting as its proxy.
Its advantages are:
After successful creation, users can still modify members and thresholds (with the agreement of members reaching the threshold).
Even with the same members and thresholds, different multisig addresses can be obtained.
Its disadvantages are:
Multiple transactions are required during the creation process, and a certain Reserve Fund needs to be prepared.
Each creation is only effective in the currently selected network
When a proxy account makes a transaction, Polkadot filters the desired transaction to ensure that the proxy account has the appropriate permission to make that transaction on behalf of the proxied account. For example, staking proxies have permission to do only staking-related transactions.
Pure proxies are new accounts that are created (not assigned) by a primary account. That primary account then acts as any proxy on behalf of the pure proxy. Pure proxies are keyless non-deterministic accounts as they do not have a private key but they have an address that is randomly generated. Also, in some sense, nobody owns a pure proxy as nobody has a private key to control them.
When a proxy account makes a transaction, Polkadot filters the desired transaction to ensure that the proxy account has the appropriate permission to make that transaction on behalf of the proxied account. For example, staking proxies have permission to do only staking-related transactions.
When you set a proxy, you must choose a type of proxy for the relationship with the proxied account.
Any: allow any transaction, including balance transfers. In most cases, this should be avoided as the proxy account is used more frequently than the cold account and is therefore less secure.
Non-transfer: allow any type of transaction except balance transfers (including vested transfers). Hence, this proxy does not have permission to access calls in the Balances and XCM pallet.
Governance: allow to make transactions related to governance.
Nomination pool: allow transactions pertaining to Nomination Pools.
Staking: allow all staking-related transactions. The stash account is meant to stay in cold storage, while the staking proxy account makes day-to-day transactions like setting session keys or deciding which validators to nominate. Visit the Advanced Staking Concepts page for more detailed information about staking proxies.
Identity Judgement: allow registrars to make judgments on an account's identity. If you are unfamiliar with judgment and identities on chain, please refer to this page. This proxy can only access provide_judgement call from the Identity pallet along with the calls from the Utility pallet.
Cancel: allow to reject and remove any time-delay proxy announcements. This proxy can only access reject_announcement call from the Proxy pallet.
Spokesperson: Kusama-specific proxy type that only allows remark or remark_with_event calls.
Society: Kusama-specific proxy type that only allows society-related calls.
