No one asked me to write this, I’m not sure this is the right place, and it’s probably none of my business—but over the past year, I’ve noticed patterns in SNS proposals that were rejected or failed—often for technical reasons 
.
If you’re planning to submit an SNS proposal, here are three key checks that hopefully could help improve your chances:
-
TEST the entire proposal and swap flow beforehand.
-
OPEN SOURCE your code before posting on the forum.
-
Keep DEV VOTING POWER under 50% at genesis.
1. To get started, try to test the entire proposal and swap flow beforehand.
Locally, create a proposal, vote to make it adopted, then participate in the SNS Swap to see how it behaves. Keep testing until you have your token and a set of neurons that look exactly like what you expect to receive in your local NNS Dapp.
Use the SNS testing tools (doc / repo) to simulate this process — or build your own tools if the existing ones don’t meet your needs (I did this with proposals.network (repo) when submitting Juno). It takes time, but running through the full scenario is worth it because sh** happens.
2. Open source your code before posting on the forum.
Not parts of it, not afterwards—open source all of it. If a DAO isn’t open source from the start, voters might not have enough time to review the code before casting their votes. For example, this is part of the guidelines the foundation follows when deciding how to vote.
3. Keep the developer voting power under 50% at genesis. If the team control more than half the voting power, the project isn’t decentralized—you’ll have enough influence to enforce decisions. This is also one of the foundation’s guidelines, by the way.
To verify your setup, upload your sns_init.yaml file into the SNS Tokenomics Analyzer of the Dashboard and review the final graph.
I hope this helps! Good luck 