Refundable Investments Basics¶
This section describes the basic principles and functionality of the dApp. The documentation is still in progress and is subject to regular changes and updates.
This section of the documentation implies that you will be using the official UI of the dApp - ICO-Refund.com to interact with the dApp
Reaching a Consensus Over a Project Status in a DAO¶
The dApp is fully open source and transparent, managed entirely by smart contracts and all of the data is stored on the blockchain. It’s run by the participants in it and they have different roles, based on their actions and goals.
Because of the fact that it is built as a decentralized autonomous organization, the decisions for its governance are made not by a single individual or centralized group of people in power but by the collective consensus of the participants.
The main form of governance in the dApp is the investors’ control over a project status - which project they will mark as ‘failed’ - to be refunded. The voting model (methodology) used for accomplishing that is created and implemented as a mean for achieving the most objective decisions possible, in a decentralized manner.
That includes protecting the different types of participants in the platform’s ecosystem, like investors and project owners, from collective errors/inadequate decisions, malicious activity and/or organized manipulation attempts.
The consensus algorithm of the dApp is based on a 3-layer voting mechanism over a project status that utilizes all participants in the ecosystem.
- Moderator’s vote - a moderator can set a refund state to a project single-handedly that meets one or more requirement of a failed project from the dApp’s community guidelines;
- Investors’ vote - internal voting over a project status among the investor that have active investment insurances for the project in question;
- Public dispute - open community voting over a project status that can be invoked after an internal vote or forced by a moderator refund state;
To further understand the description of the voting methodology it’s necessary to get familiar with the basic concept of its main components - the different voting types:
Although in most use cases, a project’s status will be settled just after the first or at most the second one of them, the public community voting is in place in order to ensure the most accurate results, mitigating the risk of organized internal vote manipulation.
While in internal voting the voters (investors) are a certain limited number of people and organized collusion is possible by a group with a lot of available resources, in an open public dispute can participate anyone with an Ethereum account. In other words, the public vote relies on the number of people as opposed to the internal vote.
The fact that the result of the internal vote can be overturned on a higher instance prevents cases, where a group of people tries to manipulate an internal vote result by colluded, conspiratorial voting, as in such case they will lose their funds (see ‘Unsuccessful internal votes’).
The dispute is a higher instance of voting in our DAO. You can compare a dispute to an appeal of a court case (the internal vote) on a higher instance, where the jury is the whole outside crypto community.
Conditions for a successful internal vote¶
An internal vote by the investors is considered successful when the conditions needed for reaching a consensus that the project has to be refunded are met.
These requirements defer based on the size of the project - the amount of funds secured in it and the number of investors with active investment protections:
|Total secured ether (ETH)||Number of active insurances||Percentage needed*|
|< 188.0000||< 24||90%|
|> 188.0000 & < 812.0000||> 24 & <= 88||85%|
|> 812.0000||> 88||80%|
*The percentage needed from both the total secured ether and the number of investors with active insurances, in order for a refund state to be assigned after the results of the internal vote is processed.
- If the total secured ether for the project is less than 188 and the active insurances are less then 24 - the required percentage of investors that have to request a refund state (vote that the project has been failed) and their combined secured ether is 90;
- If the total secured ether for the project is more than 188 but less than 812 and the active insurances are more then 24 but less than 88 - the required percentage of investors that have to request a refund state and their combined secured ether is 85;
- If the total secured ether for the project is more than 812 and the active insurances are more then 88 - the required percentage of investors that have to request a refund state and their combined secured ether is 80;
- In case of other combination of an overall active number of insurances and Ether secured for them - the required percentage is 95, as such values will mean that a small number of investors has a huge amount of funds secured;
Unsuccessful internal votes
An unsuccessful internal vote means that according to the general consensus (of the investors) there are no issues with the project and there’s no need for the investments in it to be refunded.
Because of the necessity for malicious actions and/or manipulation attempts to be penalized in a DAO environment, voting in an unsuccessful internal vote and in other words, requesting a refund state on a project that is not considered failed by most of the investors, is penalized by a suspension of the investment protection. This rule also applies if the result of a successful internal vote is overturned in public voting by the community.
For an easier consensus over a project status and avoiding the risk of penalty, please follow the community guidelines about which projects are safe to be considered unsuccessful.
Invocation of a public dispute¶
An open, community voting can be requested by the following type of participants and in the DAO and in the following cases of the project lifecycle:
- By the investors that have active investment protections, in case of an unsuccessful major internal vote;
- By owners and supporters who have deposited collateral pool contributions, in case of a successful internal vote by the investors;
- By owners and supporters who have deposited collateral pool contributions, in case of a refund state forced by a moderator;
- By the moderators, in case of a successful internal vote by the investors;
Conditions for a successful public vote (dispute)¶
A public vote is considered successful and will set a refund state to a project when the people who have voted that the project must be refunded are more than the ones that have voted for the opposite. In case they are an equal number - the refund state will not be assigned.
The dispute will be extended if too few people have participated. Currently required by the dApp minimum number of voters is 112. If that threshold isn’t reached during the dispute period of 2 weeks - it will be extended with another 2.
Project States & Indicators¶
A project’s state is a stage of the project lifecycle depending on how much time has passed from his coverage and the condition, determined by the actions (governance) of the investors in it.
In the UI of the dApp at ICO-Refund.com the project state and its short description is displayed on the project page under the ‘Insurances’ tab - in the ‘Project Tracker’ box.
Details for all possible project states in the dApp:
Open- When the project is initially added to the dApp it gets assigned an
Openstate. That means it is open for new insurance requests. That state continues until about 2 weeks after the end of its token sale, then it is switched to
Active- the default status of a covered project if it’s not under some type of governance (voting). During an Active state, if there is something wrong with the project, the investors can vote for a refund state.
Vote in Progress- gets assigned when 15% of the investors that have active insurances for that project request a refund state (vote that the project has been unsuccessful). It continiues for a period of 3 months in the end of which the results are processed and a new state will be assigned according to it.
Freezetime- The freeze state is a 1 week timeout period set after a major internal vote or forced by a moderator refund state. During that time a public community vote can be requested to dispute the results from the investors’ voting. If no dispute is invoked during that time - the project coverage lifecycle continues as determined by the result of the internal vote.
In Dispute- the project is set to that state after a public voting (dispute) over a project status has been invoked and lasts until the dispute period ends.
Refund in Progress- this is the official name of the ‘refund state’ of the dApp. Gets assigned to a project after a successful internal vote, public dispute that settles the project as failed or is manually forced by a moderator if the project meets one or more of the indicators of ‘project failure’ listed in the community guidelines. If it’s not overturned by a public vote the state continues for 6 months during which the investors must withdraw their refunds.
After a successful internal vote or forced refund state, the
Freezetimestate is assigned simultaneously with the
Refund in Progressstate for a period of 1 week during which the project status can be disputed.
Refund Complete- assigned after the 6-month refund period expires. By that time every investor that has an active (non-canceled or suspended) insurance must have withdrawn the secured funds of his investment.
Suspended- the project coverage gets suspended in case of a second major internal vote that is unsuccessful. As opposed to that - a project can go through an unlimited number of minor internal votes.
Expired- set to the project when its 2-year coverage policy duration expires and it has not been refunded or suspended.
The project’s state is also shown along with other stats and indicators in the ‘Project Stats’ section - under the ‘Dashboard’, where you can find:
- The current state of the project;
- Is the project open for new insurance requests;
- Is the project currently in a refund period
- Total amount of secured ether for all active (non-canceled) insurances for the project;
- Total amount of supporters and owners contributions;
How to vote in an internal vote¶
When an investor requests a refund state for a project,
he is voting that it has been unsuccessful. When 15% of the other investors
do the same - the project state will be set to
Vote in Progress for a period of
3 months until the internal vote finishes and its results are processed.
How to create a new dispute¶
To create new public voting over a project status go to the project page, click on the ‘Controls’ tab and then on ‘Create Dispute’ button. In order to be able to invoke a dispute, you must be either an investor in that project, owner or supporter.
In the form submit the details of your dispute:
- Dispute URL - public address of this dispute page with information and/or discussion on the actual state of the project. Will be assigned to the project and stored on the Ethereum blockchain forever. By default is the URL of the official ICO-Refund.com dispute page, but if you create another, back up one - like a Reddit thread - you can change the address to point to it.
- Additional Link (optional) - address with additional information for the disputed project. It can be a page from its official website, git repository, social media accounts, posts, tweets, or any other evidence for that the project is or isn’t failed.
- Project Info - information for the current status of the disputed project. Why the project will be disputed? If it was settled as failed provide information on why it isn’t. If an internal investor’s vote was conducted but unsuccessful include arguments on why the project should be publicly voted as failed, such as official website data, git repository, or other evidence for that the project has been failed and requires a refund state.
- Screenshot (optional) - Image related to the actual state of the disputed project. It can be a screenshot from its official website, git repository, or other visual evidence for that the project has or hasn’t been failed.
A collateral payment is required for the creation of a new dispute to prevent malicious activity:
- For investors: 1 ETH - it is repaid back if the dispute settles that the project has ‘failed’ and has to be refunded;
- For owners & supporters: If the owner or the supporter has a deposited a supporter’s collateral amount less than the dispute lottery prize, he must send the difference with the call of the request.
How to vote in a public dispute¶
The voting process of a dispute¶
The dispute is divided into 2 separate stages in order to prevent manipulation attempts - a “Voting phase” and a “Revealing phase”. A user’s vote is valid only if it is submitted during both stages - at the first one, it will be sent by the UI encrypted (hidden) with a password code, during the revealing stage the vote is submitted by the UI decrypted. The dApp will then hash it on-chain and compare its hash to the encrypted one sent earlier and if the hashes match - the vote will be valid.
The duration of the first stage is around 10 days, the revealing period is around 4. As a precautionary measure, the number of voters is displayed after the voting phase and the result is shown only when both of them has been completed.
Submitting your vote¶
To submit your vote go to the dispute page, either from the big top alert on the project page that is displayed when the project is under public voting, or from the disputes list ink in the site’s footer. After you get familiar with the information about the project status provided by the dispute creator click on ‘Submit your vote’ or just scroll down to the voting form.
Enter a number that will be your vote encryption password - it will be used by the UI to hash your vote client-side and will send it encrypted. Then click on one of the 2 choices that you have depending on that if the project meets one or more of the indicators of ‘project failure’ listed in the community guidelines and send your vote.
A collateral amount of 0.024 ETH must be sent with the vote, it is repaid back to you when the dispute finish if the user’s vote matches the collective consensus of the dispute.
After the first phase of the dispute passes and the revealing one begins, go to the dispute page again to send your vote once again to reveal it to the dApp. In order to be valid, you have to submit the exact same choice (vote) and password as in the first stage of the voting.
There is a voter verification system is implemented when voting in disputes in order to prevent automatic voting and other forms of manipulation.
If this is your first vote in a public dispute, your account will be validated on the blockchain during the first stage of the dispute, that’s why the cost of around 50 000 gas needed for validation token to be mapped to your Ethereum account, must be sent with the vote. This is a one-time procedure done only with your first vote. After that, your account will be verified on the blockchain for all disputes that you choose to participate in.
Calculation of Protection Rate¶
A protection rate is the percentage from the whole investment that will be secured (insured). Every project has a floating protection rate between 95% and 75% depending on the total amount of funds secured for it at the moment, and the amount of the collateral deposit made to the refund pool by its owners/supporters.
Every project starts with 95% protection rate. When new insurances are requested, that percentage goes down. The project owners and supporters can boost that percentage by depositing collateral to the collective pool of funds.
The current protection rate percentage of a project is recalculated after every new insurance requests and supporter/owner collateral deposits, based on the amount of funds currently secured in investment insurances for the project and the size of the new insurance/collateral deposit made.
In the case where the PR is decreased after new investment protection, the value used for the percentage recalculation is its pool contribution (fee) amount.
In the case where the PR is increased after new owner/supporter collateral deposit, the value used for the percentage recalculation is the whole amount of the deposit.
In both cases, if the value used for recalculation of the PR % is not enough to increase or decrease it with 1 full percent, it will be added to the next value, when one is provided (on the next insurance request or collateral deposit).
In the table below are displayed the values for the amount of new insurance fee ETH needed to decrease the protection rate with 1% and the amount of collateral/owner deposit needed to increase the protection rate with 1% depending on the overall net amount of the pool contributions collected for the project.
|Total amount of fees in ETH||Pool contribution (fee) in ETH||Collateral deposit in ETH|
|> 88.0000 & < 288.0000||5||7|