epochcr / sire Goto Github PK

Tests also need to be modified slightly now that the mint function will behave differently.

Should not be much of a change but creating a test-plan and documenting all the cases and creating them needs to be re-done at this point with the new methodology for minting.

It seems like revert is now the way to go when attempting to stop malicious code execution, it was introduced long after this contract was created.

It became mandatory to add context which the variables and functions should be allowed to be called, this contract was written before that rule was implemented in the latest solc

After discussion with Ben it might be a better idea to remove the Max ether cap, as more people might want to invest more/less than the pre-defined cap I set.

I am not opposed to this but after a specific period of time (1 Month) the ability to convert Ether to Sire will no longer exist and the max number of ether is what was collected and the max number of sire that exist will be <= to the amount traded during the ICO period.

Its been a few weeks since I put this on testnet, and I noticed some issues with the web-app talking to the deployed code.

Unsure what the problem is at this point, will cross this bridge after I finish solidifying the updated function behavior for mint and clean up the contracts code.

https://github.com/BaysideBitcoin/sire/blob/74205282d8cd6f41dbccd5c08d2862f87dda20bf/contracts/Sire.sol#L296

After discussion with Ben maybe the number of relics generated per sire should be in function with the number of sires that exist.

After numbers are worked out and the Sire/relic deflation rate is set, determine an acceptable Flashing scheme for Sire, to provide someone several blocks worth of Relics "instantly"destroying the Flashed Sire in the process.

It will probably be much easily adopted if atleast the sire portion adheres to the convention of regular erc-20 token naming conventions

The relic functions unfortunately will have some sort of prefix like relicX etc.

It should not be necessary to use wrapper functions to access the contracts state variables, I recall seeing some code that does this some further research might be necessary.

Reason this is important is it offloads some of the code in the contract, to the JS app, and the number of functions we need to validate and secure in the contract will drastically drop, this will cut out like 100 lines of code and comments.

After a lengthy Contract Audit with Ben C. this afternoon it was discovered the version of the contract I currently have contains a possible attack using the mint function with the same coins across multiple addresses over different time-spans.

I did have mitigation for this attack but removed it for some specific reasoning hence an unused variable containing block number to lock sends of sire for. It should be pretty straight forward to ensure this attack does not occur. But in order to fix this a number of aspects of the mint need to change. It does add some neat features with providing benefits to long holders etc.

After talking with the team, even though I would rather be Altruistic and not take anything for the creation of the contracts currency.

Having some coins will help us grow Sire and get it and relic listed on exchanges. It will be used to pay for marketing of the coins benefit, and web-server/web-app development costs. If ether increases in value enough or more than expected ether is contributed during ICO period, an IOS mobile app could possibly be funded by this effort as well or a simple fireproof hard-wallet for long-term minters.

Research Using the safe math libraries, its pretty self explanatory. During relic mint function ensure we use safe math practices.