Symbol Launch - m-of-n Optin Validation Problem (11 accounts)


While working through the Extraction, Validation and Creation of Genesis/Nemesis block work (Symbol Launch - Genesis Block Creation and Opt-In Validation) it has become apparent that there is a minor logic error in how some Multi Sig Opt-ins have worked that will leave the Symbol account with a stricter co-signing threshold than they have NIS1, for cosigner removals.

The issue only affects m-of-n multisig accounts (2-of-4, 3-of-5 etc) and there are only 11 affected opt-ins so most people can ignore this, if you haven’t opted a multi-sig account in, you can ignore completely.

This one gets a little involved but I will try and explain as clearly as I can. The purpose of this post is essentially to provide information, explain the issue, quantify it and give an approach to resolve if people want to.

The new Nano Wallet v2.5.0 release resolves the issue for any future opt-ins so it only affects those 11 accounts noted below.

First, an overview of some Multi Sig basics

NIS1 Multi-Sig

In NIS1 a Multi-signature account can be one of the below for initiation/signing:

  • Only some cosigners must approve a transaction or remove a signer: m-of-n
  • All Cosigners must approve a transaction: n-of-n, in which case removal is n-1

Docs here: Multisignature and Multi-User | NEM Documentation

Symbol Multi-Sig

Symbol supports all of the above but also allows the account owner(s) to explicitly set the removal signature threshold for taking a signer off an account. It brings into it a concept of two settings:

  • minApproval: The n-of-n or m-of-n
  • minRemoval: Explicitly set signing requirement to remove

Docs here: Multisig Account — Symbol Documentation

Issue with the Opt Ins

The logic in Nano Wallet’s opt-in module and the design is correct for most scenarios but we have found some specific ones with certain Multisig setups in which it sets the Removal threshold higher than it is currently on NIS1.

Essentially the logic that was mapped will set Symbol accounts minRemoval to a higher number than was set on NIS1.

We cannot resolve this in the extraction routine because it involves signed transactions that have been submitted on NIS1 as part of the opt in process. There is a way to resolve this manually.

The table below tries to explain this logic more easily with examples, note the two columns:

  • Expected is how it should behave
  • Actual is how it does behave.
  • 2 of 4 example is the problematic one.


Affected Accounts

The issue affects 14 accounts in total, of which 3 have below 100 XEM balances so will be excluded anyway. You can monitor the list by going to this link:

Opt-in Statistics and searching for unexpected multisig mapping

The accounts affected at the time of writing were (NIS1 account address):


Under 100 XEM and can be ignored if not being used


Resolution Options For Affected Multi-Signature Account Holders

Unfortunately it is not possible to opt in a second time from the same account via the wallet, this means there are these primary options available if your account is affected:

  • Accept opt-in explicitly: if you wish the account to be migrated as it has been opted in, even with the mis configuration, you will need to explicitly confirm this by sending a 0 value transaction from the MultiSig account, with a message of m-of-n accepted in the message field. This must occur on NIS1 from the account in question to the Opt In account and is accepted at the account owners’ risk. You can then. The NIS1 opt in account is: NAQ7RCYM4PRUAKA7AMBLN4NPBJEJMRCHHJYAVA72

  • Re-opt In: Register a new Multi-Sig account, download the updated Nano Wallet with the fixed opt-in module in it, opt-in again and then transfer balance to the new account

  • Do nothing: the opt-in will be rejected and you can opt in post launch


If you need any help with this issue, please contact the helpdesk is available on: Telegram Telegram: @nemhelpdesk or NEM Helpdesk or reply on this thread

We are also in the process of sending a transaction with a message to the affected accounts


I was testing 2 of 4 opt-in process before doing it for real.
But since I am retarded person, I lost all the nem keys… I only have Symbol keys.
I made my peace with losing those 120 xem.
so you dont have to look for owner of NC7MBV2WLRXBPRP6TSIQG7TWZCGM66NRPQY22XKT any more…

One technical question: If i control minApproval cosignatories but dont have enough for minRemoval:
cant I just add cosignatories until I have enough for minRemoval?
Or the minRemoval automatically increases with any added cosignator?

1 Like

Why would you post a PK anywhere?

Regarding question. Yes, you can do that but as Dave mentioned those accounts will be not included by default.

1 Like

current symbol wallet does not have “sign message” option and that PK is worthless for multiple of reasons :smiley:

I am the owner of one of the 11 accounts.
If I ‘Accept opt-in explicitly’, will my namespace be also migrated?

Hi. Yes - namespace will be migrated. Just verify if multisig setup is ok for you.

1 Like

I’ve accepted opt-in explicitly, but my account does not seem to be migrated yet.

Will it be migrated manually?

Thanks, it may take a day or two for the acceptance to show up. @CryptoBeliever, would you mind checking and confirming for @masahiro please?

1 Like

Yes. Will check :+1:

I confirmed that my account is in the migrated multisigs list and in the migrated namespaces list.
Thank you.

1 Like

Yes. It was fixed. Thank you for information :+1:


I am the owner of one of the 11 accounts.
When “accepting opt-in explicitly”
What should I do?

Unfortunately that needed to happen before optin closed, the final block had been created before this message

You need to follow post launch opt in but if you flag to @CryptoBeliever then we will try and expedite given you tried and it didnt work through no fault of your own


Thank you
Will I still get the symbol if I opt in after the release?

Yep, just dont move the tokens (fo r now), you will be fine