This text was originally written by EOS Nation CEO Yves La Rose and was published on Voice.com on September 9th at 0500 UTC. We are republishing it here in its entirety. 

I have been trying to gather my thoughts in order to write this post as there has been much movement in the EOS DeFi realm recently. I wanted to summarize the discussions from our EOS Nation telegram group in an easy to read format for you, also having something handy to point to in future reference.

Disclosure; I was prompted to write this specifically tonight for two reasons:

1. A token holder reached out this evening to inform me they believe a project that added EOS Nation in their MSIG permission list is a scam project.
2. It appears that the EMD project has exit scammed.

My goal is to have the widest reach possible, I will therefore try and keep this simple in terms of complexity – those with a deep understanding of these concepts might feel I am oversimplifying certain things; that is my intention.

Audit VS Open Source

What we see in EOS right now are projects that choose to either get their contracts audited, or skip the audit and open source the code which essentially opens the door for anyone and everyone to audit. There are advantages and disadvantages to both which I do want to dwell on. The point is that we should typically see one or the other.

A potential red flag is when a project does neither.

What is also important to note is that having an audit performed or having code that is open sourced does not remove the risk of having issues within the code (intentional or not) – it simply mitigates a portion of the risk, and even reduces it greatly to a certain extent, but it is not full-proof. They are both means to improve the relationship with the token holder by building an initial base layer of trust. There are several companies that I know of that offer auditing services on EOS which I have worked with: Slowmist, PeckShield, EOS42 and Sentnl. It is my opinion based on experience working with these four that they are competent and trustworthy. However, I need to repeat it – an audit does not remove risk, it mitigates it to a considerable extent. Please remember this. The process of performing an audit is a back and forth that can last several days and is intended to close any potential loophole in the code. If a project performs an audit, but deploys a different version of the code, one which is not audited, it has no meaning. Ensure that the code that is deployed matches the hash of the audited code. Usually the auditor will add this as a mention when they give their stamp of approval (i.e. we have audited this code and the deployed code matches the hash that we audited).

MSIG VS Single Owner

This is a tricky one, so please bear with me. MSIG is short for MultiSignature – it is simply adding the requirement for more than one party to make changes to a particular contract. Changes could be anything from code modifications to executions of functions from within the contract itself. MSIGs are great for many reasons; the main being giving away sole authority over a particular contract – decentralizing its ownership.

EOS has an incredibly powerful set of base-layer permission functions that can be leveraged alongside the MSIG. The two main ones that need to be adjusted are: threshold and weight.

• Threshold is the bar to reach, a concrete number that needs to be attained or surpassed in order to have authority over the contract.
• Weight is the the value that is assigned to each participant. Adding the weights together is what is calculated when determining if the threshold is met.

For example, let’s pretend there is a contract with a set threshold of three (3). In the permission set there are five (5) accounts that each have a weight of one (1) assigned. In order to make changes to the account, any three (3) of those accounts would need to be in consensus in order to meet the threshold set.

Each EOS account has an owner key as well as an active key.

The owner permission can do whatever it wants

• including changing the active key and permission sets.
• In many cases, the active permission is only eosio.code; so the contract itself.

Note that for most projects you would see the MSIG at the owner level, but not necessarily at the active level. This is fine. Here is where it gets a little tricky…

Any account can be added onto an MSIG permission list. This does not require consent nor knowledge from said account owner.

Why is this important? For one, having an account that is MSIGd does add a layer of security to a certain degree (as I mentioned above it does decentralize ownership of the contract), but it can be superficial if other criteria aren’t also followed. An MSIG account does not inherently mean there are no issues with the contract.

• Always look to see if the code has been audited or is open sourced.
• Always check to see if the MSIG participants are known and trusted entities.
• Always check the threshold and weights set; how many other entities need to approve changes for consensus to be reached.

On the question of consent, it is somewhat irrelevant. It is good form, see polite, for a project to reach out and ask whether a particular entity wants to be a party to an MSIG, but as you now know, it is not necessary. There is no way for us to guide, direct, mentor and review each project, we cannot do this, there are not enough hours in a day to do so.

Being on an MSIG list is not an intrinsic endorsement of the project.

At EOS Nation we’ve taken the position of accepting to be on the MSIG list on projects in order to help decentralize contracts as a general service to token holders and developers. We accept to do so when the criteria laid out above are met as this helps ensure, to a certain extent, that no one can arbitrarily move assets for example. However, there comes a point where this is no longer scalable as the ecosystem grows and more projects are deployed. Hence, my previous comment about consent not being necessary. At some point it is inevitable that projects will assign trusted entities and only reach out when or if they need to make changes. The review process, if accepted, would be done at that time. Of note, unless absolutely necessary you typically do not want to make modifications to the code, so this may never happen. This is fine, as long as token holders understand what I have written above. An MSIGd account does not mean it is risk free, as with the audit, it is simply an additional layer of protection to mitigate possible risk, not remove it.

I started this article by giving a disclosure for the particular timing of the article, let me address the two.

• A project with little utility, poor communication, questionable tokenomics, an anonymous team, and falling asset valuation does not make it a scam. 
• As far as I can tell EMD was not audited, not open sourced, and the owner and active keys were the same, and not MSIGd. This could have been prevented.

Thank you for reading, I hope this helped shed light on these concepts and that it will help you make informed decisions as our ecosystem enters its next phase of growth.

“As one of the leaders of the space, we support innovation. With innovation comes the chance of high reward, and high risk. Some projects make it to the moon, while some fall short. Always manage your risk accordingly.” – Changpeng Zhao, CEO of Binance

Disclaimer: The information provided above does not constitute investment advice, financial advice, trading advice, or any other type of advice whatsoever, and the information on our website should not be trusted as such. We present this information to you as general market commentary. The information does not constitute investment advice or any professional financial advice of any sort whatsoever. We do not advise or recommend that you buy, sell, or hold any cryptocurrency, digital token, ICO, or digital asset whatsoever. We advise users to conduct their own due diligence and consult with a qualified financial advisor before buying, selling, or holding any type of digital asset or cryptocurrency. We will not be held responsible for any investment decisions made based on the information provided on the website.