How to Reconstruct a CASP Incident from Conflicting System Clocks

A CASP incident timeline should preserve what each system recorded, then separate supported event order from uncertain physical time. Sorting exported timestamps into one column can reverse a withdrawal workflow when hosts disagree about UTC. The useful result is an evidence packet that explains each correction, identifies the relationships it can prove and leaves unsupported comparisons unresolved.

This guide is for engineering, incident response and compliance evidence teams at crypto-asset service providers. It works through seven fictional records spanning an API gateway, risk service, ledger, custody adapter and administration service. The example includes overlapping time intervals, a verified message chain and a freeze record whose relationship to custody submission remains uncertain. None of these records describes a customer incident.

Start with the question the incident review must answer

Assume the review asks whether a withdrawal was submitted to a custody provider before a freeze became effective. That wording already hides two distinctions. A freeze request is different from the control becoming active, and submission is different from provider acceptance or blockchain settlement. Name the exact system transitions being compared before collecting a large volume of logs.

In our fictional packet, W1 records the custody adapter sending a request. U1 records an administrator submitting a freeze request. The packet has no control-activation event. It can reconstruct the withdrawal's internal path, but those two records cannot establish whether an effective freeze should have prevented submission. The review needs both a timing answer and a missing-evidence answer.

Write the question at the top of the worksheet, alongside the incident identifier, affected workflow, review scope and evidence cutoff. Use a cutoff to describe the material available to the reviewer, not to imply that later evidence is irrelevant. A revised export may change the conclusion, so preserve the earlier packet and its stated limitations.

Do not begin by choosing the earliest timestamp as the incident start. An alert can be generated after a failure, a dashboard can show collection time and a provider can report the time it processed a request. Each observation has a different job in the reconstruction.

Preserve the raw records before normalizing time

Retain the original timestamp string, event payload and source location in an access-controlled evidence copy. Record the exporting identity, collection time, export method, file hash and scope. A hash identifies a retained file; it does not prove that the producing system recorded every event correctly or that an earlier administrator could not alter its source logs.

Give every record a stable identifier independent of its timestamp. Keep host or service identity, process or boot identity where available, request correlation, message identity and local sequence fields. These attributes help distinguish a retry from a second business action and prevent a rebooted process from appearing to continue an earlier sequence.

Keep transformations in a derived worksheet. If a parser corrects a timezone, or an analyst applies a measured clock offset, retain the input and the transformation version. Overwriting the raw timestamp destroys the evidence needed to explain why the final timeline differs from the original export.

MiCA compliance software development at Pharos Production includes audit-trail and evidence integration across exchange, ledger and custody systems. The relevant commissioning problem is whether those records remain inspectable across system boundaries. That service scope is not a claim that the fictional incident here occurred in a delivered project.

Distinguish timestamp representation from clock error

A timezone conversion changes representation. Clock correction addresses disagreement between the recording clock and a reference. Treating the two as one operation makes errors difficult to audit. A timestamp with an explicit offset can identify an intended instant while still coming from a host whose clock was several seconds fast.

RFC 3339, sections 4 and 5 defines an Internet timestamp format and its offset conventions. For reconstruction, parse the recorded value and preserve its offset before producing a common UTC representation. Consistent formatting helps comparison; it supplies no evidence that the host's physical clock was accurate when the event happened.

Also identify what the field measures. Event time describes the source's observation. Collection time describes when a collector received or processed the record. A database commit timestamp may describe transaction completion, while an application timestamp may have been generated before the write began. Their labels must survive the export.

If a legacy record contains a local time without enough information to resolve its offset, mark that limitation. A daylight-saving transition can make a local clock label ambiguous. Do not select one interpretation merely because it produces a more convenient sequence. Seek configuration, neighboring records or another verified identifier that constrains the interpretation.

Build the fictional clock worksheet

All seven events use the fictional date 2026-10-04. The raw labels below have already been parsed into UTC notation. Each offset means source clock minus reference time. Positive values mean the source runs ahead. The uncertainty values are stipulated bounds for this example, not measured production accuracy or universal limits for NTP.

For each record, subtract the offset from its source time, then expand the corrected center by the uncertainty bound. The result is an interval, not an exact reconstructed instant. The arithmetic was executed locally for this article; the input assumptions remain fictional.

• G1, gateway request accepted: raw 12:00:02.100Z; offset +2.000 seconds; uncertainty 0.050 seconds; corrected interval 12:00:00.050Z to 12:00:00.150Z.

• R1, risk request received: raw 11:59:58.240Z; offset -2.000 seconds; uncertainty 0.080 seconds; corrected interval 12:00:00.160Z to 12:00:00.320Z.

• R2, risk permit emitted: raw 11:59:58.500Z; offset -2.000 seconds; uncertainty 0.080 seconds; corrected interval 12:00:00.420Z to 12:00:00.580Z.

• G2, ledger command sent: raw 12:00:02.620Z; offset +2.000 seconds; uncertainty 0.050 seconds; corrected interval 12:00:00.570Z to 12:00:00.670Z.

• L1, ledger transaction committed: raw 12:00:00.700Z; offset +0.100 seconds; uncertainty 0.040 seconds; corrected interval 12:00:00.560Z to 12:00:00.640Z.

• W1, custody request submitted: raw 12:00:01.150Z; offset +0.300 seconds; uncertainty 0.150 seconds; corrected interval 12:00:00.700Z to 12:00:01.000Z.

• U1, freeze request recorded: raw 12:00:00.820Z; offset 0.000 seconds; uncertainty 0.120 seconds; corrected interval 12:00:00.700Z to 12:00:00.940Z.

A raw timestamp sort places the risk events before the gateway accepted the request. Sorting corrected centers still puts L1 before G2. Neither sorted list is the final evidence-backed ordering. The example deliberately requires the reviewer to use more than one source of ordering information.

Explain where each offset estimate came from

A real worksheet needs provenance for every offset and uncertainty assumption. Record the reference source, measurement method, observation time, source host and period for which the estimate is considered usable. Retain synchronization status and any clock-adjustment records that help characterize the incident window.

An offset measured after an incident is not automatically valid during it. A host could have restarted, lost synchronization or stepped its wall clock in between. Mark the affected period separately and seek observations closer to the event. Interpolation is an analyst's model whose assumptions need to be visible, especially when the monitoring interval is long.

The uncertainty bound must describe what the method actually supports. Network asymmetry, measurement resolution, logging delay and missing observations may affect the interpretation. A synchronization tool's reported value is one input to the analysis; do not silently turn it into a guaranteed bound on every application event emitted by that host.

NIST SP 800-92, Guide to Computer Security Log Management, discusses synchronizing logging hosts to a common time source. Synchronization supports future correlation. It cannot retroactively provide the missing clock history for an old record. Keep unknown bounds visibly unknown instead of substituting zero because a spreadsheet requires a number.

Add causal relationships that the records can support

A matched message establishes more than two similar timestamps. In the fictional packet, the request identity links G1 to R1. The risk service's own sequence places R1 before R2. A matched response and the gateway's verified processing path place R2 before G2. The ledger command identity links G2 to L1, and the committed outbox relationship links L1 to W1.

Each edge needs its own evidence reference. A shared customer identifier or nearby time does not establish that two records describe the same message. Verify request, attempt and payload relationships, including whether a correlation identifier was reused across retries. The edge should mean something specific, such as this command caused this transaction to be committed.

Leslie Lamport states in Time, Clocks, and the Ordering of Events in a Distributed System, published in July 1978:

In a distributed system, it is sometimes impossible to say that one of two events occurred first.

His paper formalizes event relationships through process order and message transmission. Applied to this packet, the lesson is to preserve a supported partial order. A convenient display order can put every row somewhere on a page, but it must not promote that arrangement into evidence that unrelated events caused or preceded one another.

Resolve overlapping intervals without inventing precision

G2 has a corrected interval of 00.570 to 00.670 seconds after noon. L1 spans 00.560 to 00.640. Their intervals overlap, yet the matched command and commit establish G2 before L1. The interval model permits that relationship even though the corrected centers appear reversed. Keep the causal edge and both bounds.

R2 and G2 also have a small overlap. Their verified message path supplies the sequence that physical-time estimates alone cannot settle. Do not move one center by a few milliseconds to make the picture look orderly. Such a cosmetic correction would add a new assumption without improving the underlying evidence.

For two bounded events, a strict physical-time ordering is supported by this model when the first event's latest possible time is earlier than the second event's earliest possible time. Equal endpoints leave room for equality. Overlap means the intervals alone do not resolve their order; another valid relationship may still constrain it.

U1 and W1 overlap substantially, and this packet contains no verified relationship between them. Report their relative order as unresolved. Their corrected centers are 00.820 and 00.850 seconds, but the apparent 0.030-second difference is smaller than the stated uncertainty. It is not a measured delay between freeze activation and custody submission.

Two calculated witnesses illustrate the ambiguity. U1 at 00.710 and W1 at 00.900 fits both intervals; W1 at 00.710 and U1 at 00.900 also fits. Both can coexist with the earlier command chain. These are possible assignments under the fictional assumptions, not observations of which event really happened first.

Keep contradictions separate from ordinary uncertainty

Overlap is not a contradiction. It means several physical-time arrangements remain compatible with the bounds. A contradiction arises when trusted causal evidence requires one order while the proposed bounds exclude that order. For example, a command cannot be committed before it was sent if those labels describe the matched send and resulting commit.

Do not resolve that conflict by deleting the inconvenient row. Recheck the event definitions, correlation match, source identity and offset validity. A log label might refer to enqueue time instead of transmission, or a commit might belong to an earlier attempt. The uncertainty model might omit a clock step that occurred during the window.

Record the rejected interpretation alongside the evidence that rejected it. If two sources remain in conflict, state which conclusion is blocked and which additional observation would resolve it. This keeps an investigator's judgment distinguishable from a source fact and makes a later revision easier to review.

In the fictional fixture, the arithmetic check permits the complete chain from G1 through W1 within the stated intervals. That is a consistency result for these supplied inputs. It does not validate a production clock, prove that every workflow event was captured or establish the outcome of the provider request.

Use local sequence and monotonic measurements within their scope

A source sequence can help explain order where wall-clock readings repeat or move backward. Check what allocates the sequence and whether it represents event execution, log enqueue or export order. A collector's row number is not necessarily the source process's execution order.

Preserve the identity and boundaries of the sequence domain. Process restart, failover or a new stream partition can create a new domain. Two partitions numbered 100 and 101 do not establish a cross-partition business sequence simply because the integers are consecutive. A complete reconstruction names the domain alongside the value.

Monotonic measurements can support elapsed-time analysis within their documented clock domain. They do not automatically supply a common UTC reference across hosts or survive restart as one continuous scale. Pair them with host and boot identity, and explain how any mapping to wall time was obtained.

Logical clock values also need interpretation. A system that actually propagates logical timestamps can preserve useful ordering properties. Assigning logical numbers after the incident is an analyst's representation of known edges, not evidence that the original application enforced those edges. Keep generated labels separate from source fields.

Trace provider responses and blockchain observations independently

W1 is a local submission record. To extend the timeline, collect the provider request identity, response status, acknowledgment semantics and any later state transitions. A timeout cannot by itself show that the provider rejected the action; the result may have become available through a separate query or callback.

Preserve the provider's own timestamp semantics and stated precision. A timestamp rounded to a whole second cannot justify a millisecond comparison merely because the local system stores three decimal places. If the provider does not expose enough clock information, use supported request relationships and mark the physical-time limit.

For an on-chain transfer, record the transaction hash, network, observed inclusion and the observation source. Keep block metadata separate from the local time a node or indexer noticed it. A block timestamp is not a direct replacement for the time at which an application submitted a request or a provider decided to sign it.

If the review spans changing chain state, preserve the observation context and later changes in separate records. The incident's business question may concern submission, signing, inclusion or the configured finality decision. Select the relevant transition explicitly rather than allowing whichever timestamp is easiest to retrieve to define the outcome.

Tie the timeline to control state and review responsibility

Return to the original freeze question. U1 records a request, so the packet needs evidence of activation at the enforcement point before anyone can judge the control's behavior. Seek the policy version, activation acknowledgment and the version evaluated when the withdrawal passed through its decision point.

Even a resolved request ordering would not answer that second question automatically. A workflow might be required to recheck state before dispatch, or it might use a previously granted authorization under a documented policy. Record the actual rule and the source establishing when it applied. Have the control owner evaluate behavior against that rule.

DORA ICT risk-management logging rules in Commission Delegated Regulation (EU) 2024/1774, Article 12 include reliable reference-time synchronization and logging safeguards within their stated scope. This engineering worksheet does not determine an entity's regulatory classification, reportability or applicable deadline. Those decisions require the entity's responsible legal and compliance process.

Separate the technical finding from the incident decision. Engineering can establish that a command chain is supported and freeze timing is unresolved. The incident lead decides what that finding means for the investigation, while the control owner identifies the missing state evidence. Record each decision with its author, source references and revision.

Choose source authority when exports disagree

Two exports may describe the same workflow at different levels. A gateway log can establish that an application accepted a command; a ledger record can establish that a transaction committed. Neither should silently replace the other. Put the disputed fact first, then identify which source is authoritative for that particular transition.

An operational dashboard may apply a filter, round a timestamp or update its status after the initial event. Preserve the export settings and the observation time. If the dashboard disagrees with the retained event stream, inspect how it derives its display before treating the difference as a source-clock problem.

Use an evidence register for these disagreements. Name the claim, competing records, source semantics, interpretation and reviewer decision. A reconciliation entry might explain that one record measures request acceptance while another measures commit completion. A second entry might remain open because the provider's timestamp definition is unavailable.

Prefer an explicit unresolved entry over a narrative that quietly mixes sources. The final reader needs to know whether a conclusion came from a source-of-record transition, an independently matched message or an analyst's timing model. This register also prevents a later team from repeating an interpretation that the incident review already rejected.

Deliver a packet another reviewer can reproduce

The final packet should contain the preserved exports, source inventory, parser version, clock worksheet, relationship register and finding log. Include access instructions that let an authorized reviewer reach the retained records. Keep credentials and unnecessary personal information out of the review copy; the evidence store's permissions belong to the normal access process.

For every worksheet row, retain raw time, timestamp semantics, normalized representation, offset provenance, uncertainty, sequence domain and evidence references. Add the corrected interval and interpretation as derived fields. Where a field is unavailable, name it as unavailable rather than allowing an empty cell to look like a completed check.

The finding for this example has three parts. The withdrawal chain from G1 through W1 is supported by the fictional relationships. U1 versus W1 is unresolved within the supplied bounds. Freeze effectiveness is not established because the packet lacks an activation record. Each part points to a different next action.

Ask a second reviewer to reproduce the interval arithmetic and inspect the edge references. They should be able to explain why G2 precedes L1 despite reversed centers and why U1 cannot settle the freeze question. This is an acceptance procedure proposed for a real handoff, not a claim that an independent reviewer tested the article's fictional incident.

Turn the remaining gap into an engineering deliverable

A useful incident reconstruction ends with specific work. Missing clock history calls for improved synchronization evidence. Reused correlation identifiers call for better attempt identity. Unclear activation calls for an observable control-state transition. These are different changes and should not be bundled into a vague request for better logging.

Pharos Production's CASP audit-trail software integration is relevant when evidence is scattered across exchange, ledger and custody boundaries. A bounded brief can request one reproducible incident packet, documented timestamp semantics and explicit unresolved relationships. Acceptance should depend on inspecting those artifacts, with no promise that integration alone establishes regulatory compliance.

For the next review, select one contested comparison and ask what would change the answer. If a matched message already proves the order, preserve it. If bounded intervals exclude an order, show the calculation. If neither resolves the comparison, keep the unknown and identify the missing source. That leaves the commissioning team with an inspectable conclusion and a precise next task.

More insights to read

• What Did the Ledger Know at Cutoff? Build a Reconciliation Snapshot

• How to Choose a Blockchain Integrator for an Existing FinTech Ledger

• Blockchain Ledger Integration Hub: Contracts and Acceptance Evidence

• How to Specify a Blockchain Ledger Integration Contract

• How to Scope a FinTech Blockchain Discovery Sprint

About the author

Written by Dmytro Nasyrov PhD, software architect with 24 years of production experience. Dmytro is the founder and CTO of Pharos Production. He works on production software architecture for FinTech, AI, Web3 and blockchain systems.