Are there any downsides to using unix_timestamp vs slot to time lock programs?

Question

Let's say I want to restrict access to my program up until a certain time. Given some future time I can either:

• Use Clock::get()?.unix_timestamp to check if my future time has occurred yet
• Assuming each slot is ~400ms, predict which future slot will encompass my start time (and compare using Clock::get()?.slot

I know that there can be clock drift issues with both of these strategies, however using the unix_timestamp property seems a lot easier to reason about. Are there any downsides to using it (security or otherwise) instead of trying to predict the slot?

Answer 1

The two approaches are roughly equivalent in an ideal world, however, unix_timestamp is based on stake weighted median vote timestamps with drift capped by slot time estimate from epoch_start_timestamp.

In other words, both will be at most equally wrong during major desynchronisation, while the unix_timestamp can be less affected by intermittent changes in slot time.