Guidelines for Case Timelines

General Guide on Timelines

The default timezone if none is specified is presently "America/Edmonton" which switches between MST and MDT. Timezones must be specified on all new entries into timelines. If existing entries exist in the timeline, then the new entries must comply with the same timezone. The following is a helpful list of offsets for timezones:

Table of Timezone Offsets

Code	Name	Offset From UTC	Region Used
UTC	Coordinated Universal Time	UTC + 0 hours	Europe
MDT	Mountain Daylight Time	UTC - 6 hours	Alberta, Colorado, Montana, New Mexico, Utah, Wyoming
MST	Mountain Standard Time	UTC - 7 hours	Alberta, Colorado, Montana, New Mexico, Utah, Wyoming

There is presently some debate over which timezone to use. The following are currently accepted:

• Coordinated Univeral Time
• Mountain Time
• The timezone of the exchange or platform which is primary in the case.

Choosing The Specific Date of a Case

It is important for the organization of cases and to prevent duplicates that all cases be assigned to a specific date when they occurred. This date is used to organize information on the public case lists. It is often desirable to use an exact timestamp. If the exact time of day cannot be determined, then noon on the specified date will be assumed.

The guidelines vary slightly depending on the type of case involved:

Hacking

For hacking events, the timestamp of the first blockchain transaction that actually removes funds from the individual or service facing the loss. Every effort should be undertaken to find the actual blockchain transactions. However, if no blockchain transactions can be found due to the limited available information, then the timestamp of the very first public report of loss should be used.

Rug Pull

For rug pull events, the timestamp of the first blockchain transaction that removes funds from the individual or service facing the loss. If no blockchain transactions can be found, then the timestamp of the very first public report.

Ponzi Schemes

To avoid the potential for libel or speculation, Ponzi events must have concluded before they can be covered. For Ponzi events, in this order:

• The timestamp of the first public declaration of bankruptcy, guilt by a founding member, or announcement that the platform is shutting down.
• If there was no such announcement, the time at which the platform ceased to honour all user withdrawals. This is the time of last withdrawal, not counting withdrawals by operators of the scheme. Applying limits or restricting larger withdrawals do not count.
• If information about withdrawals cannot be obtained, or no withdrawals were ever performed or allowed, the timestamp of the first public report that a participant is unable to withdraw their funds.
• Failing all of the above, the date of the most comprehensive investigation can be used.

If further information is discovered, then the timestamp of a Ponzi scheme may be moved around to improve the accuracy.

Lost Funds

For lost funds, the time at which the individual or organization first publicly reports the funds inaccessible.

Privacy Breaches

For privacy breaches, the date at which the information was first accessed by an unintended party. If the circumstances of the access have not been publicly revealed, then the time of the first announcement.

What Constitutes Multiple Events

Often times, there will be many events that are closely related to one another. For example, Mt. Gox went through multiple events leading up to their ultimate demise, or the same hacking event may have multiple affected users. In these cases, the following considerations should be made to determine when events are the same:

• If the actual date and platform/wallet/service/contract of the events are within three days (72 hours), these will be considered as one event and included together, even if there may have been multiple separate "incidents" that happened on that single day.
• Each separate event or incident must be fully compliant with the Criteria For Case Inclusion on their own. If they are not, then the minor events won't get their own article and should instead be included in the history or aftermath timeline of the main event/incident.
• Details from related events will often still be included in the timelines of other events, even if they were both major events.

Some discretion may apply, and it can be challenging to make the right call. Please use the Discussion page if you believe that the original decision was made incorrectly.