ICO Proxy
allows token buyers
to participate in Ethereum ERC20 based token crowdsale safely from trusted wallet providers
(eg: myetherwallet, status.im, mist, metamask) by paying premium
through a proxy smart contract. The proxy smart contract will be assured by group of people (called validators
) with deposit
so that validators pay the deposit to token buyers if token address end up transferring money to wrong address. The validators earn premium if everything goes safely and wallet providers earn part of the premium as referral fee from the proxy contract. ICO companies
can protect their reputation risk (from their users getting scammed) as well as promote their ICO through popular Ethereum wallet providers.
Many ICO companies are easy scammed/phished targets mainly because most of them are new and hence neither security nor credential of their communication channels (website, social media, chat room) have been established.
- InsureX halts crowdsale after hack = InsureX social media gets hacked.
- $7 Million Lost in CoinDash ICO Hack = Coindash website gets hacked
On the other hand, wallet providers (notably MyEtherWallet are more secure and have credential of supporting large number of Ethereum users yet it is difficult for them to prevent their users sending money to wrong ICO contract address misinformed by other communication channels or landing to phishing sites of their own.
(Example of scam slackbot navigating users to phishing site )
What if there is a trusted data feed which each wallet can share and easily integrate into so that their users can discover and invest into ICOs without leaving their trusted wallet?
Such trusted data feed will not only decrease the chance of token buyers receiving misguided token sale information from untrusted source (including the social media/webpage of ICO companies themselves) but also allows each wallet provider chance to acquire referral fee.
The biggest question is how do you establish such trusted data feed, and there are two solutions, both of which are complementary to each other. The first solution is crowdsource verification of the sales data by staking some deposit which they will lose if the information turns out to be false.
The second solution is allow token buyers to invest via proxy smart contracts which automatically check the validity of crowdsale contract address (eg: address has been deployed by pre verified contract owner address. The address has not been changed duration of crowdsale) against the verified fact and only proxy through the transaction if these conditions are met.
-
An ICO company(called
icobaby
in this example ) announces their ICO schedule and detail by purchasingicobaby.icoproxy.eth
sub domain ENS (Ethereum Name Service). -
Point
icobaby.icoproxy.eth
to a smart contract containing the following information about the token sale.{ /* Mandatory when announced */ "sales_facts":{ "owner_name": "ICO baby inc", "contract_owner_account":"0xabc...", "start_at": "2017 08/15 20:00:00", "end_at" : "2017 08/22 20:00:00", }, /* Mandatory by the sale starts */ "deployment_info":{ "contract_address" : null, "function_name": "invest()", }, /* Dynamically updated */ "assurance":{ "number_of_people)": 20, "deposits_in_eth": 500 } } }
-
Validator (eg: ICO company themselves, researchers, security auditors, and their supporters) will validate the
sales_facts
by paying some deposits. The more deposit gets attracted,assurance
will increase. The deposit will be locked until the end of crowd sale. -
Each wallet provider (eg: myetherwallet, aka mew) receives their own proxy contract for the ICO as a ENS sub domain.
eg:
mew.icobaby.icoproxy.eth
-
Proxy contract becomes active only when
deployment_info.contract_address
is deployed bysales_facts.owner_address
x days prior tosales_facts.start_at
and the address has not been changed until the end ofsales_facts.end_at
. -
Wallet provider announces upcoming ICO of
icobaby
and allows token buyers to send token including the premium within their wallet. -
When token buyers send Ether to the proxy address, part of ether goes to an escrow contract as a premium and sends the rest to
deployment_info.contract_address
by callingdeployment_info.function_name
function with caller address as an input argument. -
When token sale ends (+ some cooling period), the total premium in the escrow contract are split among wallet provider , validator, and ICO Proxy.
-
When crowd sale address turned out to be false, token buyers open a claim. When claims reach certain percentage, then the deposit of validators will be split among token buyers as compensation (the compensation amount will NOT exceed the total ether lost per token buyers).
-
If validators think that token buyers are making false claim, they can also counter claim. Failing to resolve the case will lead deposits to be locked until the dispute become resolved.