Figure out how a `maturityDate` of the bond should be stored - block #? timestamp?

[RusseII]

Figure out how to store maturity date and how we'd be able to check if the bond has matured

contract Bond {
maturityDate: type? 

function checkIfBondIsMatured () {
logic? 
}

}

[luckyrobot]

https://github.com/HonestInsurance/Smart-Contracts/blob/9b8f889eeefd48459bf131bb359c3ca6bd955641/contracts/Bond.sol#L252

[RusseII]

https://github.com/HonestInsurance/Smart-Contracts/blob/9b8f889eeefd48459bf131bb359c3ca6bd955641/contracts/Bond.sol#L252

So _currentPoolDay is passed in as a unix timestamp?

Then they have a trusted authenticated ping service that pings the auth endpoint with the current time?

Does this make sense for us? It would be nice if it was possible to do without needing the ping service

[luckyrobot]

https://github.com/HonestInsurance/Smart-Contracts/blob/9b8f889eeefd48459bf131bb359c3ca6bd955641/contracts/Bond.sol#L252

So _currentPoolDay is passed in as a unix timestamp?

Then they have a trusted authenticated ping service that pings the auth endpoint with the current time?

Does this make sense for us? It would be nice if it was possible to do without needing the ping service

that code is from 4 years ago, may be worth asking our advisors what they reocmmend

[RusseII]

@luckyrobot I assigned this to you as it's a subset of #4

[RusseII]

I think we can just use store maturtyTime as a unix timestamp and useblock.timestamp to determine if the maturity date has passed https://github.com/gnosis/ido-contracts/blob/e7a363591e3f0a8735f90a9f04f5062351559d7d/contracts/EasyAuction.sol#L24

[RusseII]

@luckyrobot has this fully been figured out? Or does it still need explored?

[luckyrobot]

the solidity linter recommends against using block.timestamp, so we may need to explore this some more to use an alternative method. would you agree?

❗ Do not rely on block.timestamp, now and blockhash as a source of randomness, unless you know what you are doing. ❗Both the timestamp and the block hash can be influenced by miners to some degree. Bad actors in the mining community can for example run a casino payout function on a chosen hash and just retry a different hash if they did not receive any money. ❗The current block timestamp must be strictly larger than the timestamp of the last block, but the only guarantee is that it will be somewhere between the timestamps of two consecutive blocks in the canonical chain.

[luckyrobot]

@Pet3ris @stuarth1 what do you think about using timestamp here? ^

https://github.com/porter-finance/v1-core/blob/main/contracts/SimpleBond.sol#L59

[Pet3ris]

I guess you can use block.timestamp since your maturity dates are well in the future. Short-term timestamp manipulation is more prevalent than long-term. And you don't want your market participants to worry about predicting block production rates to understand their cost of capital. Also you have plenty of proof-points (e.g., AAVE).