RegionX Application

[Szegoo]

Project Abstract

RegionX is a marketplace and a set of tools for Coretime manipulation and data tracking, with the goal of making development on Polkadot faster, easier, more flexible, and, as an end result, cheaper.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or Polkadot (USDC & USDT) or BTC address in the application).
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @SNK2:matrix.org @cuteolaf:matrix.org

[Szegoo]

NOTE: the designs will be added soon.

[keeganquigley]

Thanks @Szegoo the formatting looks good now; feel free to ping us once the designs have been added.

[Szegoo]

@keeganquigley I added the designs :)

[keeganquigley]

Thanks @Szegoo I will mark the application as ready for review.

[keeganquigley]

Thanks @Szegoo for reducing the scope and cost. I just took a closer look, could you also integrate more technical details into the milestone tables themselves, such as how many ink! contracts are you creating total, and what are the main functions of each? Thanks!

[Szegoo]

@keeganquigley Thanks for the quick review. I provided more details in the milestones table.

[github-actions]

The applicant has requested the discussion of the application to happen in a private chat room.

[Noc2]

Thanks for the application. I have one quick question: Would you be willing to initially start with only milestone 1? This way it will be easier to accept the grant and we have a better understanding of your team and project after the delivery.

[Szegoo]

@Noc2 thanks for the advice. I updated the application so that it only contains the first two milestones and lowered the cost so that the application is now level 2 instead of 3.

[Szegoo]

@keeganquigley Would love to get your review on the proposal after updating it to contain only the first two milestones.

[keeganquigley]

Thanks for the changes @Szegoo can you also change it at the top of the application? As it still says level 3.

Also, milestone 2 Documentation notes that you will build an ink! smart contract but I'm not seeing this included in any of the deliverables. Can you make a section to include it?

Thanks!

[Szegoo]

Thanks for the changes @Szegoo can you also change it at the top of the application? As it still says level 3.

Yes, my bad. It is fixed now.

Also, milestone 2 Documentation notes that you will build an ink! smart contract but I'm not seeing this included in any of the deliverables. Can you make a section to include it?

I am not sure what are you referring to here. From what I can see there is the Coretime Market contract deliverable as part of the 2nd milestone.

[keeganquigley]

Ah thanks @Szegoo sorry yes I see it now. I agree that having another coretime marketplace would be healthy competition. I guess my last question is, can you explain a bit more about how the dynamic pricing model would work?

[Szegoo]

The dynamic pricing model is basically the 'bit-level' pricing system. Compared to regular NFT marketplaces a Coretime marketplace has an interesting property. The regions available for sale gradually lose value over time as they have the potential to be assigned to a specific task.

For this reason, it would be highly impractical to create a marketplace where the price of regions is fixed, i.e. once the seller sets the price of their region it remains the same until the region expires. This model wouldn't make sense since a region that has a duration of 4 weeks shouldn't have the same value as a region with a duration of only 1 day.

The smallest unit of a region is a single bit in its Coremask, so we decided to create the pricing model around that. Given that the duration of a region's bit is known, the contract can calculate the current price of the region based on when it was listed on the market. With this model if a user decides to purchase a region they are only paying for what they get, i.e. they are only paying for the part of the region that hasn't expired.

@keeganquigley Please let me know if you have further questions about this.

As mentioned in the application, all the details about the market will be thoroughly explained on RegionX's documentation website and Medium articles. This documentation will offer comprehensive information for anyone interested in building on top of the contracts or simply curious about the system.

[keeganquigley]

Thanks for your answers @Szegoo, and thank you for reducing the scope. I thought there was a lot of good discussion in the chat, and since it is a bit different from Lastic's approach I'm willing to give it a shot and bootstrap this initial PoC. After that I think it would be best to look for other funding avenues such as the treasury or the new decentralization program.

[Szegoo]

@Noc2 I followed your suggestion and I would really appreciate your review on this.

[Noc2]

Sorry, I missed this here. I'm happy to go ahead with it as well.

[Szegoo]

@takahser As you have reviewed and provided a lot of feedback on the Corego application, I would really like to get your review on this.

[takahser]

@Szegoo thanks for the updates. I think at this stage, M1 is quite similar to the Lastic grant, also w.r.t. the price. Combined with the new wireframes that look much better than those in the previous Corego proposal, I'm fine with it.
In M2 you're adding the secondary market, but I didn't find the wireframes for the Coretime Market dashboard UI. Also, I'm not sure about the UI for transferring the region NFTs's wireframe(s); is that equivalent to the Transfer UI wireframe you included?
I'm fine with the other deliverables in M2, so feel free to clarify the wireframe situation and include additional ones, if necessary.

[takahser]

Btw, @cuteolaf is there any affiliation between this project and the Chain Extension Suite proposal, where you added a suggestion? There's certainly nothing wrong with contributing in conversations of other teams, I just wanted to double-check:)

[cuteolaf]

@takahser I just added the suggestion to fix a typo.

[Szegoo]

@takahser Thanks for the quick response and for pointing out the missing wireframes. I have now included them in the application, so the proposal should hopefully be good now :)

[takahser]

@Szegoo thanks for adding the wireframes. I think the seller side has not been covered yet here, right? Also, it looks like the Buy Regions screen is lacking the support of filtering for start and end duration (all I can see is the Select Region Duration dropdown). Could you do another iteration on that? I believe this part is especially crucial and should be as intuitive as possible, since it might be one of the very key factors for the popularity of this tool among the community.

[Szegoo]

@takahser Yes, as stated in the proposal, we indeed intended to include more filtering options. The initially provided design aimed to give a rough idea of its appearance. I have now updated the application to feature a more precise design for the Coretime market UI, along with the inclusion of the missing region sale modal.

[Szegoo]

@takahser Additionally, regarding the wireframes, I want to mention that there is also a bright version of the design. I didn't include it in the proposal to avoid redundancy, but you can view the Figma design here.

[Szegoo]

Since Lastic has been mentioned multiple times during the discussion about this proposal, I have decided to create a list that describes the differences between the two projects. This will help better understand how they relate to each other:

1. RegionX provides a solution for executing cross-chain region transfers, an essential component for the development of a decentralized Coretime market. The significance of this component lies in the fact that NFT cross-chain transfers are not currently supported on Polkadot or Kusama. However, we managed to come up with a solution that is feasible, makes no compromise on security, and is able to work within the current system. xcRegions will be usable by any project that seeks to build tooling or a market for Coretime.

2. We have put multiple hours of research into designing a pricing model that is best fitted for Coretime trading. The solution we provide offers dynamic pricing that allows the price of Coretime to gradually decrease over time as it is not being utilized. Without the dynamic pricing model, the Coretime market would have inaccurate pricing which would require frequent user activity to continually modify the current price of the Regions being sold.

3. Our bit-level(dynamic pricing) model further allows the later development of the Region derivation feature. This feature will allow users to buy only a portion of the Regions being listed on sale which would overall lower the financial requirements for purchasing Coretime due to users being able to purchase exactly the Coretime they need. This would also bring more activity to the market since the barriers required for purchasing Coretime would be significantly lowered.

4. The contracts specified in this proposal are meant to be common good and utilized by many future projects building around Coretime. For this reason, we will prioritize extensive documentation to facilitate seamless integration of any of our contracts into external projects. Additionally, great documentation around the pricing model is also very crucial since a good understanding of it would be highly valuable for anyone engaging in Coretime trading.

5. The design and UI we plan to develop are extensively detailed, outlining precisely how users can purchase and perform operations on their Coretime. Currently, Lastic's UI appears to be primarily geared toward creating data dashboards. It's challenging to compare our intended UI development to something that Lastic hasn't clearly described or specified. Despite both projects seemingly building UIs around Coretime, the utility they provide differs. Hence, I find it difficult to make any further comparisons on this topic.

6. Unlike Lastic, we are not creating mock data for the UI. Instead, we are building the entire project in a simulated local environment. This approach ensures that the code we develop will seamlessly function in production without requiring any additional development efforts.

7. In the 'Future Plans' section, we have clearly outlined the upcoming steps for this project. We've extensively researched and defined many technical details from our end to ensure the feasibility of our plans going forward. I don't perceive RegionX and Lastic as having identical future goals and plans. For this reason, I believe the two should not be viewed as competing projects.

[takahser]

@Szegoo thanks for your recent proposal updates and detailed insights into how your project differentiates itself from Lastic.
While you made good progress, I still feel there's room for improvement in the UI, particularly in simplifying the buying process. Although I don't have specific suggestions at the moment, I believe this aspect could enhance user experience and might be important to the overall success of your solution - so it might be worth to look into how to improve it, once you have the UI ready. Just as a sidenote - if the UI is not 1:1 identical with the wireframes, we'll approve the delivery either way, as long as everything works and the same scope is covered, while maintaining the anticipated (or better) UX.
On the whole, your proposal now seems robust and support-worthy. It's beneficial for our ecosystem to have diverse projects, and your proposal adds to this variety alongside Lastic. I'm looking forward to this!

[github-actions]

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.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at [email protected] and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

[Szegoo]

@takahser Thanks for your review. I agree that there is room for improvement in the designs, especially considering the novelty of the new Agile Coretime concept. As we move forward, it will become clearer how to enhance the designs further. Throughout the grant development, we will be actively collaborating with our design team, gathering feedback, and doing more research to ensure a successful delivery of RegionX.

[takahser]

@Szegoo sounds good. Thanks for the note. 👍

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/decentralized-futures-portico-lowering-the-barriers-for-builders-on-polkadot/4999/1