Add stepped function helpers about openzeppelin-contracts HOT 7 CLOSED

@maraoz have a look at my draft prototype of this function.

I analysed several ICOs, only few of them used stepped function for token price and for bonuses. Inside function they use such param as timestamp, startDate, endDate, deadlines, amounts. Most efficient way to check it is simply make an array of deadlines, as amount of them is
small (no binary search, mapping etc.).

    enum timeType {
     second, minute, hour, day, month, year
    }


// pre: startDate < endDate, startDate < deadlines[i] <= endDate, every deadlines[i] < deadlines[i + 1] 
// pre: amounts.length > 0 and deadlines.length > 0
// startDate and endDate in seconds 
function get_amount(
    uint256[] deadlines, 
    uint256[] amounts, 
    uint256 startDate, 
    uint256 endDate, 
    timeType time_type) returns (uint256) {
 if(now < startDate && now > endDate)
  throw;
 if(amounts.length == 0 && deadlines.length == 0 && deadlines.length != amounts.length)
  throw;
 for(var i = 0; i < deadlines.length; i++){
  if(i + 1 < deadlines.length)
   if(startDate > deadlines[i] && deadlines[i] > endDate && deadlines[i] >= deadlines[i + 1])
    throw;
 }

 uint256 convertedMeasure = 1;
 uint256[] timeValue; //can't be memrory, as push operates in storage
 timeValue.push(60);
 timeValue.push(60);
 timeValue.push(24);
 timeValue.push(30);
 timeValue.push(365);
  
 timeType[] timeTypeArr;
 timeTypeArr.push(timeType.second);
 timeTypeArr.push(timeType.minute);
 timeTypeArr.push(timeType.hour);
 timeTypeArr.push(timeType.day);
 timeTypeArr.push(timeType.month);
 timeTypeArr.push(timeType.year);
 
 for(i = 0; i < 6; i++){
  convertedMeasure *= timeValue[i];
  if(time_type == timeTypeArr[i])
   break;
  // maybe check if enum type is wrong 
 }

 for(i = 0; i < deadlines.length; i++){
  if(now < convertedMeasure * deadlines[i])
   return amounts[i];  
 }
 // never reached, but should ensure to prevent this
}
}

I don't like timestamp type, we might use just seconds and leave convertation on user's side. Also we can move "check bounds" logic to modifiers.

from openzeppelin-contracts.

@maraoz do you like design of contract?

from openzeppelin-contracts.

I'd do it with block heights, not timestamps, to be consistent with our security recommendations.

from openzeppelin-contracts.

@maraoz won't this be harder for avarage developer?

from openzeppelin-contracts.

@misteraverin possibly. But our focus with OpenZeppelin is security over ease of use.

Some extra feedback: consider writing this contract not as a standalone function, but as other helper contracts we used, with state and a constructor. I'd do this as a contract one can inherit from and which gives you access to a getSteppedValue() or something

from openzeppelin-contracts.

We have an IncreasingPriceCrowdsale that grows linearly, but shows how getCurrentRate can be used for more interesting functions. @misteraverin are you still interesting in contributing here? If so, let us know how we can help you.

FTR, there's also some experimentation with BondingCurves, which adjust the rate of the token and can be used to incentivize or disincentivize different things. This could be more interesting than a hard-coded stepped rate.

from openzeppelin-contracts.

Closing due to staleness. There was some talk about bonding curves a couple months ago, but it doesn't seem to have caused large repercussions.

from openzeppelin-contracts.