A proposal has been created here which would enable transfers and links to this page.
I thank the proposal authors (“Simply VC”) for their efforts and look forward to enabling transfers, but I (individually, not representing any official entity) have serious concerns with this proposal as written. Specifically:
Network upgrade process: dual-proposal vs. single-proposal
I think a dual-proposal process for software upgrades would be safer and provide a higher degree of certainty for node operators (particularly validators). Such a system would have first an indicative proposal to demonstrate stakeholder approval of a particular milestone (such as 0.34.0), and then once software development was completed and the software version released / tested, a second proposal with an exact code hash and block height would facilitate the network upgrade.
I think compressing these two proposals into a single one, which preapproves the software release, may introduce undesirable levels of uncertainty and risk. The Cosmos SDK development team - or any future development team working on the Cosmos Hub software - could change the contents of a milestone or the code within a software release - whether due to implementation difficulties, changes in priority, addition of new features, or a whole host of other reasons (most of which are not malicious, although that could also be a concern). Github milestones are mutable - they can be edited at will. Until a software release is completed and an exact Git commit hash provided, stakeholders cannot be certain as to what software precisely they are agreeing to run.
This is my primary concern. Secondary concerns:
Unclear process for handling critical issues on the testnet
The proposal suggests a mechanism for accepting bug fixes:
Any bug fixes, as defined by the Tendermint development team, encountered during the operation of the gaia-14k testnet and committed to the master branch after the release of v0.34.0, will automatically be approved as per the endorsement of this proposal.
What does this mean? Must “approved” bug fixes necessarily be installed by validators? Is there a timeline for when such fixes could be committed (is this intended to be after Gaia-14k but before the upgrade, for example)?
Lack of clarity in genesis changes
Although it may be difficult to approve an exact new genesis file in proposals - due to the desire to export-import at the same height - I think proposals would be well-advised to include extremely explicit instructions on how the genesis file for the new network is to be changed, if at all (beyond export-import). Validators must make these changes manually themselves, and it is essential that they change exactly the same fields in exactly the same way, or the new network will fail to start. Perhaps it would be prudent to include a script to automate the genesis changes.
As written, I believe this proposals omits a change to withdraw_addr_enabled (allowing different withdraw addresses for rewards, which was originally disabled along with transfers), which I expect they intended to also re-enable along with enabling transfers. This is relatively minor and could be enabled in a later proposal - but does indicate the importance of precision.
Conclusion
I would be in favor of a revision of this proposal which served as the first indicative vote in a two-proposal process, with a second proposal slated for later to approve an exact code hash. Further feedback or discussion of the above points welcome.