This proposal just went up today as an expedited proposal and per @pmuecke 's advice I am starting this thread.
Summary: The Shillables team was late to filling out the form to submit our contract’s addresses to be included in the next network upgrade to assign an admin address to pre v1.10 contracts. After talking with ertemann and assafmo and a few others we were told it wouldn’t be too late to get our contracts appended to the list of contracts that were outlined in prop #262Proposal #262 | Secret Network | Keplr Dashboard. It was also said that it would be low risk to append our contracts if our proposal were to pass.
Benefits
We unfortunately thought that we had more time to submit our contract addresses to the original form that was setup for prop #262. We recognize that this isn’t the typical way of doing things but hope that we will have the support of the community in this. The overall purpose of this proposal is to allow for a better user experience on the dapps we’ve built and thus continue to make a positive impact for the Secret Network as we continue to build on.
The following are the benefits for our community if this proposal passes.
We are seeking to upgrade all of our Shill Stake contracts that are used on our NFT staking platform to allow for multiple rewards to be given without impacting the users. We currently support staking for 7 NFT projects and for our $Shill token. If this doesn’t pass we will have to require users to unstake and restake to a new pool/contract in order to receive multiple rewards which won’t be the best of experiences
The Wolf Pack PackBuilder is included to be able to fix a problem with the contract where new payment methods can not be added. Currently we are making users pay $1200 $Shill to add a wolf to their pack and do not have a way to lower this price. As the price of our token increases we would like to be able to change the price if our community votes to lower it.
We are also seeking to add out SNIP-25 contract for $SHILL to this list in case there are any key privacy updates. If the prop doesn’t pass it will mean another unfavorable user experience to migrate users to a new SNIP contract in the future
While I intend to vote in favor (or probably actually abstain) of this proposal, I want to make it clear that I am likely to vote against adding administrative keys to other contracts in future votes. I am advocating for a governance-per-upgrade feature (batches of contracts in 1 prop seem fine for cases that makes sense), assaf says this is present on permissioned wasm so we could probably move to it for contract upgrades specifically (not permissioned deployments of initial contracts tho)
The sole entity empowered for contract upgrades approach essentially serves as a backdoor. I consider it not merely an opinion, but an unspoken fact that many are uncomfortable acknowledging. On platforms like Ethereum, it’s easier to identify which contracts are upgradable due to the availability of the source code. In contrast, any application on Secret that allows upgradability—without requiring governance approval for each contract modification and without open-sourcing the code—could arbitrarily compromise both privacy and security, whether by admin action or government order. Objectively this means non-open source and upgradable contracts on Secret are less secure and transparent than they are on eth.
Thanks for the reply nodefather. Are you saying that you are pushing so that even contracts deployed post v1.10 will need a governance proposal passed in order to perform an upgrade? If so that makes sense to me and would help mitigate some of the risks involved with allowing upgradeable contracts. I agree with you that this feature can serve as a back door when there are bad actors involved.
I’d like to add that our contracts for the Shillables team are open source @ wolfbytes4 · GitHub and we take a community approach with everything we’ve built meaning that big changes and updates don’t happen unless the Shillables community votes and passes it.
The long-term objective would be to impose such a governance requirement, particularly for high-priority contracts like sSCRT, sUSDC, etc. The idea is that these could be upgraded collectively through a single proposal, especially if new standards emerge that necessitate such updates.
However, there may still be room for a more per community approach for contracts that have the capacity to attain community consensus independently—NFT holders in your example. In such cases, a similar but nuanced process to what we currently employ could be followed. For instance, a proposal could be initiated to appoint an administrative address that had upgradability tied to that specific community being able to vote, paired with the new source code. This would enable community-specific upgrades, authorized through a community voting mechanism. This is a high-level concept but it should communicate the gist.
Note: even if shillables voted for 269, it gives central entities the ability to perform upgrades in the future that they may not agree with. 269 acts as a blank check power wise for future changes without requiring future consensus, which is fundamentally different than the current situation.
We’ve polled our community on if they’d want to be able to have dual rewards on Shill Stake and have had discussions on our discord that the payment needed on the Wolf Pack PackBuilder contract wouldn’t be able to be lowered until contract upgrades were available. The idea here is that if the proposal is passed then it would give us the ability to upgrade but no upgrading would be done unless our community votes on it.
I fully support and endorse this proposal. It enables flexibility for Shillables to integrate dual rewards for shillstake pools and appropriately price the Wolf Pack PackBuilder contract.
The details of such changes are at the Shillables community level as @wolfbytes mentioned. We do not have formal DAO tooling in place yet but will use discord polls to finalize changes.
I personally thank Wolf for going the extra mile to coordinate for this expedited proposal and for the network’s cooperation/consideration in the matter.