
Iām for the proposal of enabling transferability

@Daniel, I think youāve laid out some valid logic there.
-
I would completely disagree with. As radical as it may be, I donāt think the DAO would benefit from it. + This forum would have new posts every week requesting transferability taking away from other needs of the DAO.
-
Waiting till the DAO has āmaturedā is also challenging. There would need to be some KPIās for the definition of matured to be met. To be honest, there are 100ās of DAOās out there and I would say there are only a handful that are mature. It tooks years to get there and itās still not perfect.
My suggestion would be to wait until the claims window has passed and all users have had the opportunity to claim their $SAFE tokens. This also allows for fair listing/secondary market process. It prevents the rush on claiming tokens to dump (like with OP airdrop there were website crashes and early exitors could dump). This process also gives the $SAFE DAO to seed liquidity (if wanted) into the secondary market and interested exchanges. This time also allows for users to see if they want to contribute to the SAFE DAO or if they donāt see value in it.

Thank you for your proposal @Daniel.
I agree fully that unpausing the contract will be good for the Safe ecosystem and may also:
- Encourage more people to interact with the Safe Protocol;
- Allow for price discovery of the SAFE token asset;
- Imbues the $SAFE asset with value based on supply/demand dynamics;
- Enables the SafeDAO treasury to use its native asset for ecosystem growth;
- Allows people the ability to transfer control of the token between wallets.
Abstract
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.
Proposal details
Purpose and Background
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:
Effects and Impact Analysis
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.
Alternative Solutions
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.
Technical Implementation
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)
Source: https://github.com/safe-global/safe-token/blob/6a1a4a99a7f3166b525cbd5469eaf0aea1c88e54/docs/token.md
Copyright
Copyright and related rights waived via CC0.