Create SpellRouter-proposal.md #2057
Conversation
|
CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅ |
|
I have read and hereby sign the Contributor License Agreement. |
There was a problem hiding this comment.
@dudo50 thank you for the grant application. I know that you already had some grants with us and the proposal to continue evolving the API seems to make sense from a technical perspective. I have some doubts more about the business/marketing part of the application than the technical one.
- There is also some data in the application about the usage of the API. The number of requests is interesting to have, but do you from how many sources/applications/users these requests come from?
- What are the plans for continuing funding this project in a short and long-term vision?
- Did you consider continuing to apply for grants or going for treasury or another program such as the substrate builders program?
- Do you have some user feedback about your API? For example, posting in Polkadot forum and getting the opinions of users could be a good way to get feedback and support the argumentation about the utility of the API and the proposal in the application.
|
Hi @dsm-w3f, thank you for your questions.
As we stated during the implementation of the analytic tool into API. We strictly do not collect any user data and API users remain anonymous if they use captcha verification only (Up to 100 requests per minute - sufficient for most projects out there as XCM is not yet that widely adopted). Once there will be a project requesting access to more than 100 requests per minute we require them to fill small form informing us what they will use requests for to prevent malicious behaviour. Their token is then stored in a Database which stores these special cases (Only token and allowed max request amount). We otherwise do not have another way to know who uses the API and this is intentional. Our tools are common good tools and we do wish to enhance anonymity and ease of use. All this while being completely open-source and completely free for every developer. We believe, that this can only bring benefits to Polkadot which is a decentralized blockchain network. The intention of sharing personal details should be a personal choice for users.
We are currently maintenance funded for 5 months by Kusama treasury and our latest win in the Polkadot APAC 2023 Hackathon. This maintenance funding is meant to cover XCM API, XCM SDK and can be considered as a short-term vision. As for long-term vision - we wish to apply for maintenance funding via treasury again after 5 months. If the community sees the importance of us maintaining these ecosystem-beneficial tools they will allow us to continue maintaining them - compensating our time. As we stated in our LightSpell proposal before - we will work on maintaining these tools for free just like before when we weren't treasury funded if this ever becomes necessary again. We wish to bring new innovations to the ecosystem as we feel, that the adoption of XCM is not yet where it should be while the potential is definitely there.
We did. While we believe treasury is a good way to apply for grants - based on previous experiences of other projects being rejected token holders do not seem to be happy to fund innovations at the moment as their outcome might not always be as expected. This can be bad because the treasury pays in advance. Thus we only wish to use treasury for maintenance funding where token holders already see the potential and already see the built product. This is why we consider Web 3 Foundation to be the best place to apply for innovative funding/grants. Projects are not paid in advance and they have to be delivered according to pre-accepted terms. The substrate builders program was in our scope, however, we do not have a business model as a common good and a completely free set of tools. Their focus is primarily to jumpstart teams that have business ideas in mind. Our team focuses on improving the network rather than profit and business cases.
We mostly collected feedback for the API from Hackathon Participants and judges while participating in Polkadot Global Series 2023 APAC Edition. The feedback was, that API was very well made and definitely needed in the ecosystem. Thus we also won the competition in the XCM Integration track. We consider our main source of feedback our recently implemented analytic tool - Sentry meant to catch errors that are not handled by the API. This way we can always improve if we see a new error without users even needing to remind us. On top of that, we are always open to solving new issues in our GitHub repositories. These issues may also contain enhancement ideas that can then be implemented. As for Polkadot forums, our team mostly engages in governance topics, but perhaps getting feedback from there can also be resourceful and useful. We will definitely consider it. We believe all your questions were answered. |
|
@dudo50 thank you for the answer. I'll make your application ready for review. I have only one more question, which exchanges will be supported? |
dsm-w3f
added
the
ready for review
There was a problem hiding this comment.
Thanks for the application @dudo50 happy to see you again.
- After seeing the proposals fail with the treasury, I'd be in favor of supporting your team again. But it looks like we've given out about 50k to your team so far, which prompts me to ask if there has been any further adoption of your tools yet at this point? Your team does good work, but my fear is that we end up paying out a lot for something that doesn't get used.
- So if I understand correctly, after this grant you plan on going for maintenance funding from the treasury, similar to the Kusama treasury funding for LightSpell? Just want to make sure we aren't double funding anything that the treasury is already covering. For example, combining all the tools into a monorepo sounds like it could be covered under maintenance.
- Could you integrate more technical details into the milestone delivery tables, for example what is "automatic selection" in M2 XCM Router section?
- For M2 section 3, what are you using to automatically update the repos, is this just Dependabot? And how often do you need to do manual updates?
@dsm-w3f , thank you for the question. This is a matter of research for now. But what I can say is, that no third-party exchanges for sure for safety reasons. Only native on-chain exchanges that Parachains offer. For example Omnipool by HydraDX or Karura/Acala exchanges etc. With kind regards, |
Hey @keeganquigley, happy to see you again too!
I understand your concerns. To answer them, yes, the number of repos implementing SDK increased from 16 to 21 for example and the API served to the moment I am writing this comment 29095 requests since it was launched so it is a slow increase but it goes to show, that the increase is headed in a good direction. On top of that, we are in talks with Parachain teams like Astar, who agreed to put implementing our tools on backlog once they will be refactoring their defi tool. It is hard to get implementations as this is a very niche set of tools meant specifically for dApp developers. As XCM is not yet that widely adopted I believe, that we need to continue pushing boundaries and implementations will come as projects will start adopting XCM. They will naturally try to search for tools that can help them resolve complexities they would otherwise have to face.
This grant is meant to fund our innovative work - XCM Router. As we are maintenance funded for the next 5 months we do not need another proposal for maintenance until then. We will include the XCM Router in maintenance once it is developed and maintain it along with XCM API and XCM SDK without requesting any additional costs. About monorepo, you are right, after internal discussion within our team, this should be covered under maintenance and I am removing it from the application and significantly lowering proposal costs.
Will do along with commit where monorepo integration will be removed from proposal.
As this was also meant as an enhancement of monorepo later on, this will be also removed and costs reduced. But to answer your question, it was supposed to be a script that auto-updates XCM SDK in both XCM Router and XCM API packages if a new XCM SDK version is released. I will ping you in the next comment today when the updates will be applied. With kind regards, |
|
Hey @keeganquigley, With kind regards, |
|
@dsm-w3f , thanks for the notice. It has now been fixed. With kind regards, |
|
Hey team thanks for the application. I had some questions:
|
Hey @nikw3f, thank you for your questions.
Very feasible, we already provided a simple overview of the architecture. In a more basic overview:
The rest of the logic will be handled by the XCM Router itself (Picking the exchange chain, checking the best exchange chain, generating exchange calls, requesting SDK to generate calls and so on..)
As we already know, the complexity of XCM implementation is extensive. Thus, bringing tools that allow us to abstract this complexity from developers is very beneficial. XCM Router goes beyond than just generating specific XCM Calls. It allows for generating calls that give users the opportunity to receive different assets on the destination chain without any additional manual efforts (Eg. manually transferring tokens to the exchange chain, exchanging them manually and then transferring tokens to the destination chain. These steps could result in asset loss if the inexperienced user decides to do them.) Developers will be able to not only abstract this logic from their code but also abstract it from users which I believe will come in much benefit for both parties. We hope all your questions were answered, if any new arise feel free to ask. |
There was a problem hiding this comment.
Thanks for the changes and updates @dudo50 I'm happy to go forward with it.
|
@keeganquigley , @dsm-w3f , @nikw3f , thank you kindly for your support. It is very appreciated. With kind regards, |
|
Sorry for ping @dsm-w3f , we have received 3 approvals as is required for level 2 grant, however, our application is not yet merged. Just wondering if there is delay or mis-comunication. We would like to start working on XCM-Router already but as PR is not yet merged we don't know what to do. Many thanks for your answer. With kind regards, |
|
Thanks @dudo50 it has to be manually merged, let me ask the team. |
|
Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions. |
|
This pull request has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/introducing-complex-set-of-xcm-tools-paraspell/5625/1 |
|
This pull request has been mentioned on Polkadot Forum. There might be relevant details there: |
Project Abstract
This proposal aims to push boundaries in the state-of-the-art development on the Polkadot and Kusama ecosystem. It aims to create the first XCM Router for the Polkadot and Kusama ecosystem. There is a large demand for such tool. XCM Router will allow developers to create XCM messages with asset exchange in just one line (Eg. Transfer GLMR from Moonbeam and receive DOT on Astar). The XCM Router will utilize already hardened and fully developed XCM SDK.
Grant level
Application Checklist
project_name.md).@_______:matrix.org(change the homeserver if you use a different one)