Guidelines for Case Timelines - Revision history

Azoundria: Working on timeline guidelines.

2023-03-07T18:26:55Z

Working on timeline guidelines.

← Older revision		Revision as of 12:26, 7 March 2023
Line 1:		Line 1:
	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 ~~UTC~~ on the specified date will be assumed.		== 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:
			{\| class="wikitable"
			\|+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:		The guidelines vary slightly depending on the type of case involved:

	== Hacking ==		=== 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.		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 ==		=== 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.		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 ==		=== Ponzi Schemes ===
	Ponzi events must have concluded before they can be covered. For ~~ponzi~~ events, in this order:		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.		*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 withdrawals. This is the time of last withdrawal, not counting withdrawals by operators of the scheme.		*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 allowed, the timestamp of the first public report that a participant is unable to withdraw their funds.		*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 ~~that~~, the date of the most comprehensive investigation can be used.		*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 ==		=== Lost Funds ===
	For lost funds, the time at which the individual or organization first publicly reports the funds inaccessible.		For lost funds, the time at which the individual or organization first publicly reports the funds inaccessible.

	== Privacy Breaches ==		=== 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.		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 ==		== What Constitutes Multiple Events ==
	Often times, there will be many events that are related to one another. For example, Mt. Gox went through multiple events leading up to their ultimate demise. In these cases, the following considerations should be made to determine when events are the same:		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.		* 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 should be included in the history or aftermath timeline of the main event/incident.		* 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.		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.

Azoundria: Azoundria moved page Guidelines For Dating Cases to Guidelines for Case Timelines

2023-03-03T20:21:22Z

Azoundria moved page Guidelines For Dating Cases to Guidelines for Case Timelines

← Older revision	Revision as of 14:21, 3 March 2023
(No difference)

Azoundria: What Constitutes Multiple Events

2023-01-24T18:44:43Z

What Constitutes Multiple Events

← Older revision		Revision as of 12:44, 24 January 2023
Line 17:		Line 17:

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

	== Privacy Breaches ==		== 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.		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 related to one another. For example, Mt. Gox went through multiple events leading up to their ultimate demise. 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 should be included in the history or aftermath timeline of the main event/incident.

			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.

Azoundria: Create the guideline page.

2023-01-19T20:13:18Z

Create the guideline page.

New page

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 UTC 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 ==
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 withdrawals. This is the time of last withdrawal, not counting withdrawals by operators of the scheme.
*If information about withdrawals cannot be obtained, or no withdrawals were ever allowed, the timestamp of the first public report that a participant is unable to withdraw their funds.
*Failing that, the date of the most comprehensive investigation can be used.

== 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.