Create XPredictMarket.md

[XPredictMarket]

Grant Application Checklist

• The application-template.md has been copied, renamed ( "project_name.md") and updated.
• A BTC or Ethereum (DAI) address for the payment of the milestones is provided inside the application.
• The software of the project will be released under the Apache license version 2.0 as specified in the terms and conditions.
• The total funding amount of the project is below USD $30k for initial grant applications and $100k for follow-up grants.
• The initial PR contains only one commit (squash if needed before submitting your PR).
• The grant will only be announced once we've successfully delivered the first milestone.

[CLAassistant]

All committers have signed the CLA.

[Noc2]

Just to double check: This application is related to your previous application: #299, correct? Why did you set up a new github account?

[Noc2]

Btw. did you consider to use smart contracts instead of runtime modules: https://stackoverflow.com/questions/56040779/when-should-i-build-a-substrate-runtime-module-versus-a-substrate-smart-contract and do you have any previous code, that you could share?

[XPredictMarket]

Just to double check: This application is related to your previous application: #299, correct? Why did you set up a new github account?

Yes, these two applications are related. We were not so sure of the name changing process so we created a new github account, of which the content is consistent with the former one except for the project name. Sorry if we have caused you any misunderstanding.

[XPredictMarket]

Btw. did you consider to use smart contracts instead of runtime modules: https://stackoverflow.com/questions/56040779/when-should-i-build-a-substrate-runtime-module-versus-a-substrate-smart-contract and do you have any previous code, that you could share?

The reason why we adopt runtime is that we want to implement cross-chain functionalities for various assets by ourselves in the future to meet the needs for diversified assets supported in our forecast process, so we need to use the chain to realize this goal. On the other hand, the scalability of chain is stronger, and we may have more new ideas to deliver them in the future, and we hope to retain more possibilities in terms of better scalability. We have submitted tokens-pallet code on github, and this part of the code is open-sourced. Other functions are under development.

[Noc2]

Thanks. Sounds good to me. I will share the application with the rest of the team. I have one more question: I took a quick look at your tokens implementation and noticed that it is referring to XRC20. I think chainx originally used this. Are you in contact with chainx?

[XPredictMarket]

Thanks. Sounds good to me. I will share the application with the rest of the team. I have one more question: I took a quick look at your tokens implementation and noticed that it is referring to XRC20. I think chainx originally used this. Are you in contact with chainx?

Thanks for your reply! We have no reference to ChainX. Just to clarify: We decided to develop an asset management module by ourselves to enable the support of multiple assets in the future. And we did refer to some technical details of ERC20 standard because we have been doing development under the framework of Ethereum for years. Another reason is that there is an “X” in our project name, thus we put it “XRC20”. But considering that our major use case is to Predict, the team changed the name to PRC20. 

[mmagician]

@XPredictMarket In general I would like to support your project, but before proceeding I have a few questions regarding the resolution mechanism.

1. From your technical overview:

When the voting ends, we use Doublemap(pid, account, oid) to count the result and the Doublemap(pid, did, vote) to count the votes of the proposal

If I understood correctly, users themselves vote for the outcome of a market? How safe is that and how do you plan to prevent Sybil attacks?

2. But then you use Oracle-as-a-Service reference, to be fetched via an off-chain worker. First of all, this seems to contradict your earlier idea of users voting for the outcome. Which is correct?
3. Still regarding OaaS: when a user creates a new market, they need to decide on the resolution source, correct? I imagine that every source will have a different API, response format etc. How do you plan to do the integration of all these different APIs into the OCW? Presumably, the market creator needs to be enough technically apt to understand the source's format and code it into the OCW, right?

[XPredictMarket]

@XPredictMarket In general I would like to support your project, but before proceeding I have a few questions regarding the resolution mechanism.

1. From your technical overview:

When the voting ends, we use Doublemap(pid, account, oid) to count the result and the Doublemap(pid, did, vote) to count the votes of the proposal

If I understood correctly, users themselves vote for the outcome of a market? How safe is that and how do you plan to prevent Sybil attacks?

1. But then you use Oracle-as-a-Service reference, to be fetched via an off-chain worker. First of all, this seems to contradict your earlier idea of users voting for the outcome. Which is correct?
2. Still regarding OaaS: when a user creates a new market, they need to decide on the resolution source, correct? I imagine that every source will have a different API, response format etc. How do you plan to do the integration of all these different APIs into the OCW? Presumably, the market creator needs to be enough technically apt to understand the source's format and code it into the OCW, right?

Thank you Mmagician, we appreciate your reply !
Regarding the Question 1:
The phrase “When the voting ends, we use Doublemap(pid, account, oid) to count the result and the Doublemap(pid, did, vote) to count the votes of the proposal” means that we will count the number of tokens of each option using Doublemap(pid, account, oid) & Doublemap(pid, did, vote). As supplementary: during the transaction/trading process, users can purchase the token of his predicted option while at the same time, the amount of tokens held by each address can be obtained accurately, hence it’s able to prevent any possibility of Sybil attacks. The voting at this phase does not determine the final prediction result.

Regarding the Question 2
The final prediction result is determined by nodes, which will upload the results through the off-chain worker module. In the initial stage, a governance committee will be formed by the project team (as in the team) and community members, who will also act as a governance node that can upload the result with a tag ‘trustworthy’ to avoid Sybil attacks. Later, users who stake certain amounts of governance tokens can become nodes. The result supported by more than 50% of the nodes will be the candidate result which will be submitted to the test of a period of publicity. The publicity period was originally set for 3 days, which can be modified through community vote. Users can report the wrong nodes who upload results inconsistent with the reality. It is required to stake more than twice the staked amount of governance tokens of the reported node, if the reporting node can not raise that amount of tokens, it can initiate a report asking for the support of other users (by staking their tokens). Once the staking succeeded, the report is officially established and will be accepting the voting verdict by the whole network within 3 days.
When more than 50% of the votes support the reporter, the report succeeds, and vise versa. When the report succeeds, half of the staked tokens of the reported node will be given to the reporter, and the other half of the tokens will be distributed to the supporters of the reporting nodes according to the voting ratio, and vice versa.
A new round of publicity period begins after a successful report. During this period of time, users are also allowed to report, but the staked tokens required that the tokens to be staked for reporting will be doubled under this circumstance. The result of this period will become the final one if no one files a report in the publicity period.
Before the release of the governance result, the tokens participating in the governance will be locked up, also avoiding the Sybil attacks.
Theoretically speaking, the result from reality is already a given fact before the verdict. Users always tend to vote for the correct option. If there are the whales collude to act evil, then they first need to hold the vast majority of governance tokens, which means a lot of costs, then if they jointly tamper with the results and cause errors, it also means that the project has been kidnapped and lost justice. Therefore, the governance currency of such a project will lose value, which will eventually cause them to lose money and lose long-term cash flow, which is not worthy. On the other hand, after a successful report, the staked governance tokens will be lost, which is also a loss. Therefore, from the perspective of direct and long-term interests, nodes will be biased towards submitting correct results, which ensures that the project can maintain the birth of a fair result.

Regarding the Question 3
①When creating a new market, users don’t need to care about the source of data, which is uploaded by the nodes who staked their governance tokens. Each node has their own trusted data source, which should not be provided by the market creator, thereby avoiding the suspicion of cheating. The market may be completely in the control of the market creator if it provides the data source.
②Regarding the OCW working mechanism : OCW obtains the final result by some sort of technical manner (for example: http request, database query request, Binary protocol request based on tcp, the sensor transmits data through the serial port and parallel port), then we use unsigned transactions with signed payloads ( a way that can verify who sent the data without transaction fee, reducing greatly the cost of data uploading) to write the data into the pallet’s storage by calling pallet call function. Therefore, the OCW we are talking about is not limited to the OCW in the substrate. The OCW mentioned refers to an application that provides unsigned transactions with signed payloads. This will ensure that after the market is created, they will respond to the result data source in a timely manner, so that they can upload the corresponding data using OCW without changing the code of the substrate. In this way, the response format and source issues of different APIs can be avoided, and there is no need to integrate a specific API into OCW.
③Based on the ② theory, the market creator doesn’t need sufficient technology, nor does it need to be programmed into OCW. The essence of OCW is to use the result to initiate a transaction after obtaining the data. We use the unsigned transactions with signed payloads that saves massive amount of transaction fee. We do not limit the need to upload results by OCW, so the creator does not need to understand the source format in the technical aspect, and only needs to get a result, and ensure that this type of transaction is initiated normally, so it is not necessary to have OCW.

[mmagician]

It is required to stake more than twice the staked amount of governance tokens of the reported node

This might be infeasible for most of the small players if they are up against a larger attacker - even when asking for the support of other users. If I'm not mistaken, this actually lowers the barrier for the attacker, allowing them to control the result with only 33% of the network (since the others would need at least 2x).

---

Therefore, from the perspective of direct and long-term interests, nodes will be biased towards submitting correct results, which ensures that the project can maintain the birth of a fair result.

I see your point regarding the long term and I agree. Still, I think anyone who's trying to game the system could do so with only a short-term profit in mind. Attackers could sell the tokens they used to perform the attack.

---

Nevertheless, I am happy to give this a shot, I hope you can figure out the solution to the mentioned problems in the later stages of your project. Good luck!

[mmagician]

It is required to stake more than twice the staked amount of governance tokens of the reported node

This might be infeasible for most of the small players if they are up against a larger attacker - even when asking for the support of other users. If I'm not mistaken, this actually lowers the barrier for the attacker, allowing them to control the result with only 33% of the network (since the others would need at least 2x).

---

Therefore, from the perspective of direct and long-term interests, nodes will be biased towards submitting correct results, which ensures that the project can maintain the birth of a fair result.

I see your point regarding the long term and I agree. Still, I think anyone who's trying to game the system could do so with only a short-term profit in mind. Attackers could sell the tokens they used to perform the attack.

---

Nevertheless, I am happy to give this a shot, I hope you can figure out the solution to the mentioned problems in the later stages of your project. Good luck!

[github-actions]

Congratulations! As part of the Open Grants Program, we want to help winning teams acknowledge their grants publicly. To that end, we’ve created a badge for projects that successfully delivered their first milestone. Please observe the foundation’s guidelines when making any announcements; in particular, don’t announce the grant publicly before you've completed at least the first milestone of the project.

At that point, we will be happy to collaborate on an announcement about the work you’re doing. Please get in touch with us at grantspr@web3.foundation in case you're interested (at least two weeks notice is preferred).

[XPredictMarket]

It is required to stake more than twice the staked amount of governance tokens of the reported node

This might be infeasible for most of the small players if they are up against a larger attacker - even when asking for the support of other users. If I'm not mistaken, this actually lowers the barrier for the attacker, allowing them to control the result with only 33% of the network (since the others would need at least 2x).

Therefore, from the perspective of direct and long-term interests, nodes will be biased towards submitting correct results, which ensures that the project can maintain the birth of a fair result.

I see your point regarding the long term and I agree. Still, I think anyone who's trying to game the system could do so with only a short-term profit in mind. Attackers could sell the tokens they used to perform the attack.

Nevertheless, I am happy to give this a shot, I hope you can figure out the solution to the mentioned problems in the later stages of your project. Good luck!

Thank you very much for your support, we will continue to optimize the project.