The Token Swap Watcher proposal

Hi all! We (Outlier Ventures) just submitted proposal #15, “Token Swap Watcher”. In very short summary: We propose building a Token Swap Watcher, and hosting and maintaining a public-facing instance of it. The Token Swap Watcher can be accessed as a web interface for the general public, and as an API endpoint and as easily runnable code for more technical users.

This topic is meant to discuss the proposal, ask questions, give feedback, etc. The proposal document contains a good amount of detail on the why, how and what, so please have a read if you want to learn more. You can view the proposal on these network explorers: Cashmaney’s explorer | Puzzle, and here’s a direct link to the full proposal document.

I’m very much looking forward to hearing your thoughts, and - hopefully, if it passes :crossed_fingers: - making this contribution to the Secret Network!


I’m extremely excited for this to help bring some much needed transparency to the process! :pray:t5: will be integrating support for this as soon as we are able.

1 Like

In reaching out to people trying to petition support for this, has found consensus forming around the opinion that the ask amount in the proposal is too high.

For this reason we are changing our vote to no in order to go along with the will of the network.

I want to stress that we still support OV making this tooling and look forward to showing our support once the proposal is adjusted.

Honestly, I think budget is quite High.
Considering that 285k SCRT was asked for swap process.

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!


ok, so, uh, be that as it may, you have 6400 SCRT set aside for setting up your development environment and another 12400 for hosting

Hi Leor, thanks for commenting on these items in the budget. Let me clarify.

Re setting up development environment, it’s an activity that’s part of any development project, and the more external components are included, the more time it can take. When presenting estimates and budgets, some choose to separate these activities out in the budget, others choose to include these activities within the phases, i.e. amortize them. We chose to do the former. Reducing the scope, as we’re doing in our revised proposal, will bring this part of the budget down too.

Re hosting (12,600 SCRT actually), I can understand that amount looks high if you look at it in isolation, and compare it to the bare external cost that, say, hosting a web service has. Let me explain what it’s composed of. It’s for a 9 month period, so 1,200 SCRT monthly on average. Why is this - possibly, assuming a price range for SCRT - significantly more than, say, the ~$10 per month that a single VPS will set you back? Because of the monitoring and proactive management part. What’s being delivered is not “deploy on VPS and be done with it”, it’s making sure that a service runs and keeps running, stays available under whatever circumstances might occur, with high uptime and quick response. And that costs effort. Again, the difference between “hackathon project that - often just barely - runs when presenting to the jury” and “generally available product over a prolonged period” is a helpful analogy here. And this goes hand in hand with active maintenance of the code, which you might also have seen in the requested budget.

That said, from the feedback we have gotten it’s clear that this both of these are areas where more of a “best effort” level over a shorter period is a better fit, which will lead to a lower budget for both points in a revised proposal.