Liquidity Pool

Screenshots

Problem Statement

More about SpaceCoinSpaceCoin (SPC)Inherits from OpenZeppelin’s ERC-20 contractIt is to be deployed by the ICO contract instead of an external account (more on that later)notesmethodsconstructor()sets the treasury and owner of the contract (both which are external accounts) and mints 150k and 350k SPC_transfer(address from, address to, uint256 amount) internal overrideoverrides the equivalent ERC-20 virtual methodthis _transfer function is called in the public facingtransfer()functionit is basically a wrapper around the superclasses’s_transfer()function in order to charge a tax when applicablenote that if you are transferring to the treasury when tax is effective, you can skip the usual tax calculation because everything is going to the treasury anyway

Solution

SpaceCoinICOSpec that I implementedICO will deploy the SPC token. This is mainly to save gas in one single deployment and reduce any user error from setting the SpaceCoin address incorrectly in the ICO contract. Also it mitigates developer hassle from deploying two contracts separately which are otherwise going to be used closely togetherThe ICO is smart enough to accept as much as it can in a given funding round or given an individual’s contribution limit. It will accept as much as it can up to but not exceeding the limit and refund the rest to the user. For example, if the seed phase fund is at 14,000 ETH and Alice sends 1,001 ETH, she will be refunded 1 ETH, 1000 ETH will be accepted by the contract, and the seed phase limit will be reached. Similar logic holds if a contribution would exceed the individual limit.I added extra functionality to be able to remove seed investors from the allow lisDuring the open phase, SPC is redeemed for ETH contributions automatically. In other words, by the end of the contribution transaction during the open phase, the user will have SPC belonging to their addressNotesmethodscontribute()Given the refund functionality, the contribute function has a decent amount of logic in it. I’ll try to boil it down to basic steps so the code is easier to audit 1. Check if the fund or individual limit has been reached and some other checks in_checkValidityOfContribution()2. Set a contributionLock so that this and other functions cannot be re-entered via the .call method that transfers the refund 1. if there was no contributionLock, an attacker could re-enter the contribute function, which isn’t a huge vulnerability but it would corrupt some of the events emitted 3. Calculates two different values, valid contribution adjusted for the individual limit vs. valid contributions adjusted for the fund limit, picks the lower of the two, and refunds the excess. For example, speaking generally, if individual contribution is 9, individual limit is 10, current fund is 3, and fund limit is 5 and amount to contribute is 9, valid contribution adjusted for individual limit is 1 (10-9) and valid contribution adjusted for fund limit is 2 (5-3). We would pick the former so we’d effectively contribute 1 and be refunded 8 4. At the end of the function, if we are in the open phase, we redeem SPC for the user automatically. Note that there is an internal version of redeem which does not check for the contribution lock