This is a proposal to call the unpause method of the token contract (using the SafeSnap module), which would result in the SAFE token becoming transferable. Unvested tokens would still remain in the vesting contract, and thus would not become transferable.
If we go with the definition of Adam Levi, Co-founder @ DAOStack, a token needs to hold two distinct properties to be actually called a token:
While the first point is satisfied with the current design, the same is not true for the second. Since SAFE does not have the two properties mentioned above, we cannot consider it a token (yet) per the definition of Adam Levi.
I'm not sure if I completely agree with him on this definition, but I do think that those two properties are fundamentally important to a token that is intended to govern a DAO.
While non-transferability has its advantages (e.g., the governance process is more resilient against malicious vote-buying at all participation rates), it also has some disadvantages:
Having a transferable token also makes it tradeable, this is inevitable. In an adverse market environment such as the one we're currently finding ourselves in, this might lead to a suppressed valuation compared to what it could have been a year ago.
However, I'm not sure if that's actually something we should care about, as price fluctuations are simply part of how a market-based economy works. I don't think SafeDAO should structure its roadmap around how to maximize token value. The current macro environment is outside our sphere of influence, and honestly I believe that a "hockey-stick" price chart is more favorable than a down-only chart with the peak being the token launch, resulting in disillusioned market participants as we've seen in the past with tokens like DYDX, PSP and countless others.
It is beyond SafeDAO's control if and how individuals/institutions choose to price SAFE. Therefore, we should not let the adverse market environment influence our decision on whether to make this token transferable or not.
As mentioned above, the advantage here is obviously the increased resilience against malicious vote-buying. The big down side is the fact, that the ownership structure, voting power held by individuals and institutions, would remain static. I reject this on this basis that I'd rather have (new) players who genuinely want to participate in governing SafeDAO accumulate tokens and thus increasing their voting power, than maintaining the status quo indefinitely. And with a high voter turnout, there would also be sufficient resilience against malicious vote buying - even with a transferable token.
This is the alternative solution that appeals to me almost as much as the immediate unpausing of the token contract. Simply because this would give us time to think about what SafeDAO wants to accomplish and how to structure everything (there's for example the "Outcomes-based resource allocation (‘OBRA’)" model proposed by @pet3rpan-1kx which could be interesting to adopt).
However, despite all of this, I believe we should not wait until SafeDAO has matured (although that would not be a disaster either). We should start attracting contributors now, for which a liquid token is necessary and we should not voluntarily limit the scope of our activities, which is a result of this non-transferability.
And what if SafeDAO can never mature without having a transferable, liquid token to attract contributors, etc. in the first place? I can't give a definitive answer to this, but this is a realistic scenario in my opinion that should not be overlooked.
To make the token transferable no significant additional code is required, however the owner of the token has to call the unpause method of the token contract. This can be accomplished without an intermediary or gatekeeper by ensuring that the "unpause()" function is called by the SafeSnap module. Once the token contract is unpaused (and therefore the token is transferable), it is not possible to pause the token contract again (e.g. once transferable forever transferable).
(Thanks to @Arseny for his suggestion regarding the use of the SafeSnap module)
Copyright and related rights waived via CC0.