Each issuance will track pitched projects in an event.

Hash structure created with each project pitched. A hash is created both for voting for and against (two hashes). That is saved onChain to be references for voting purposes later. We the eth-sig util for signing hashes. See Voting section for more details.

https://medium.com/zastrin/how-to-save-your-ethereum-dapp-users-from-paying-gas-for-transactions-abd72f15e14d

[ ] Business Plan a requirement (100$) Business Plan required for each proposal Every site proposal adds 6 months to the refundable timeline

• takes in projectInfo (title, busLink, description, lat, lng, in a strigified json), capRequired, valuation, cashflow (pre-existing and projections), voteForHash, voteAgainstHash
• the reason we include various datapoint in projectInfo is that the EVM limits the number of arguments for a function. to get around this, we simply store string data in one argument in the form of a strigified json object. to access the data, we simply parse the string back into a javascript object on the frontend.
• Calls a subfunction titled _pitchProject, which executes the main functionality. We differentiate between to two so we can seed contracts on the test network with projects without hitting a revert in extend dooms day. this will need to be updated soon. *reverts if the sender is not the developer
• before minting new tokens to the developer, it activates any pending token activations in the developers account. if we do not do this, the next time we try to activate pending tokens for the developer, the wrong amount will activate because activation depends on information about how many inactive tokens an account had at the time the last project deployed. moreover, this error will cause a domino effect, compromising the accuracy of future token activations for all accounts. for more, see documentation on how token activation works.
• Token distribution
  • the developer should receive the amount of tokens proportional to the valuation - capitalRequired
  • the contract should receive the amount of tokens proportional to the capitalRequired
• doomsday should be extended by 90 days
• executes a function in projectFactory that actually creates an instance of the project contract. we separated this logic to reduce the size of the crowdsale contract contract because it was not deploying.
• it adds the project to the voting contract. we needed to create a separate contract for voting to reduce the size of the contract as well
• it tells the projectLeaderTracker to handleProjectPitch. Inside handleProject pitch, the tracker increments the number of candidates by 1. The reason we separately increment this variable apart from our total project count is because the number of candidates is not necessarily the same as the total number of projects (projects can activate)
• if the project requires no capital, it activates automatically via the activation contract (we separated this logic out to reduce the crowdsale contract size). automatic deployment allows developers can add projects that already exist to the portal

• as in pitchProject, we need to activate the pending tokens of the sender to maintain the integrity of token activations
• inactive tokens are transferred from the crowdsale contract to the sender (this logic is handled by the transferInactive function in Token) based on the amount sent.
• weiRaised is incremented by the amount *TokenPurchase event is emitted *dooms day is extended by 90 days