Thanks Ian and Merit for commenting here, and to others who have given feedback through other channels. We have received similar signals about the budget, as well as a few other points of feedback. I’ll try to address all of these below in a Q&A format and explain where we go from there.
Why did you choose this project scope? Can’t you reduce it and get to a lower budget?
The scope of the project is deliberately quite wide, including a usable interface for the wider public, developer-focused tooling, managed hosted versions and a long period of maintenance. We strived for a complete package because we felt otherwise the value might be significantly less. As one example, since an important goal is achieving transparency, it means there should be a generally accessible and usable version (because not everybody can and will run code), but also a capability for technical users to dig deeper (because a web frontend can only go so far).
We do see some options to reduce the scope while preserving most of the goals we had with it, and we intend to circulate a revised proposal.
Isn’t this a throw-away project? Why bother?
The token swap from ENG to SCRT will be quick and smooth, and then we’ll forget about it, right? So why spend all this effort and budget? While we have great confidence in the token swap team and code, and we are hopeful that all ENG holders will swiftly migrate all of their tokens without problems, precedents show that that’s usually not the case.
As an example, if you can show me clear sources that can answer the questions we have listed the Token Swap Watcher can answer as a minimum about previous ERC20 -> mainnet swaps such as EOS, TRON, or Zilliqa, I would be very interested because I haven’t found any. From a transparency perspective that’s not great, and there isn’t a time limit to the relevancy of that transparency. SCRT is a cryptoasset with hopefully a lifespan of many decades, and its stakeholders deserve transparency and accountability throughout its life. We intend the Token Swap Watcher to contribute to that, long-term.
How did we get to the requested budget?
The proposal document describes some of the principles, and I’ll give some further background here. Software project estimation is hard. I’ve done it for over two decades, and if I’ve learned anything it’s that things never work as intended right away, they always take longer than expected, and the team will always have to do quite a few different things than originally foreseen. So there’s uncertainty. To deal with that uncertainty, you cut things up, make your best estimate, and build in buffers.
Furthermore, there might be a difference in perception (by who reads the proposal) versus the intended reality (as we perceive it) of what and how will be delivered. We intend to approach this like how a premier software firm treats a client - only here the client is a decentralised network, which ultimately means all stakeholders of that network. It means not just ticking off a list of requirements and features and “throwing it over the wall”, it means we’ll go far and wide to make sure the results are great and the client(s) - the Secret Network stakeholders - are happy with them.
Why do we think this project is a good use of Secret Network Community Pool spending?
We want to see the Secret Network thrive and professionalize, as the open, decentralized network that it started out as. It’s why we’re very happy to see the launch of the Secret Foundation as an entity to play an important role in this ecosystem, and the idea of it being supported by part of the block rewards, and see other important development projects funded. Cryptonetworks which are able to fund development of core network assets in a high-quality manner can go a long way. We believe the Token Swap Watcher is such a core asset to the network.
Couldn’t someone build this over a weekend?
It’s very well possible that somebody could build a codebase that delivers a large part of the listed functionality of the Token Swap Watcher, in a much shorter time frame. However that’s a long way off from what we propose here. We propose a professionally built, tested, mature codebase, made and kept generally available in a well-working manner over an extensive period, by a business that has a brand and a reputation to maintain and will go to great lengths to maintain it.
One way to think about it is the difference between a hackathon project, and an actual product that can actually be used by a large audience for a significant period. A hackathon project could definitely include a large part of the functionality we envision. But then the hackers go home to do something else, it turns out it just barely worked for the demo, when you actually try to use the product it turns out that while the demo was nice it doesn’t quite do the thing you need it to do, and after a month the code doesn’t run anymore because of dependency such and such, and it gets abandoned. In contrast, we’ll make this work well and we’ll make sure it keeps working.
What’s next?
We intend to submit a revised proposal, with a narrowed down scope, leading to a lower budget, while maintaining most of the goals we have with it in delivering value to the Secret Network community. We’ll make sure we’ll have strong social consensus before, and if, we submit another on-chain proposal.
I’m open to feedback and questions here, in DMs and on Rocket Chat. Looking forward to hearing from you!
- making this contribution to the Secret Network!