Syntalium Wiki

How to Verify a SNAP

TL;DR

Every Syntalium evaluation produces a SNAP ID — a SHA-256 hash of the canonical payload. You can submit it at /verify to confirm the archived record has not been altered. VERIFIED means the payload is intact. It does not prove a trade outcome.

What a SNAP ID is

A SNAP ID is a SHA-256 cryptographic hash computed over the canonical payload of a Syntalium evaluation record. The canonical payload is a deterministic, ordered representation of all the data and decisions recorded in that evaluation cycle.

When the evaluation is published, both the payload and its hash are archived. The SNAP ID is then displayed alongside the public-facing output: the market condition, setup state, freshness, and plan fields.

Purpose: To give any reader a way to check that the published record has not been silently changed since it was first archived.
How it works: The SHA-256 algorithm produces a unique fixed-length digest for any input. Even a one-character change to the payload produces a completely different digest. If the archived payload still matches the stored hash, the record is intact.
What it does not do: SNAP verification is a SHA-256 payload-integrity check for the recorded payload. It does not predict future prices, confirm exchange fills, or make any statement about the outcome of any trade.

Where to find a SNAP ID

SNAP IDs appear in several places on the platform:

Live page: The BTC hourly live view displays the SNAP ID for the current evaluation record in the Proof & Provenance section.
Decision record: The decision record panel on the asset detail view includes the SNAP ID for the currently displayed evaluation.
Verify page: The /verify console shows the most recent SNAP IDs that have been verified in recent sessions.
API response: The public API returns snap_id in the BTC market data response. Developers accessing the API directly can retrieve the SNAP ID programmatically.

The SNAP ID is a long hexadecimal string (64 characters). Copy it exactly — even a single character change will return NOT_FOUND or MISMATCH.

How to verify at /verify

01Navigate to /verify in the Syntalium site navigation (header: Verify).
02Locate the SNAP ID from the Live page, asset detail view, or API response.
03Copy the SNAP ID exactly — the full 64-character hexadecimal string.
04Paste the SNAP ID into the input field in the verification console.
05Click the Verify button or press Enter to submit.
06Read the result status and the details returned for the matched payload.

The verification backend receives the SNAP ID, looks up the archived payload by its hash, recomputes the digest, and compares the result to the stored hash. The outcome is returned as one of four statuses.

Result statuses

VERIFIED: The archived payload was found and the computed digest matches the stored hash. The record has not been altered since it was first archived.
MISMATCH: The archived payload was found but the computed digest does not match the stored hash. The payload has been altered. Do not rely on this record.
PAYLOAD_MISSING: The SNAP ID is recognised as a valid hash but the associated payload could not be retrieved from the archive. The record cannot be confirmed.
NOT_FOUND: No record with this SNAP ID exists in the archive. The most common cause is an incorrect or partial SNAP ID. Double-check the full string and try again.

A result of MISMATCH or PAYLOAD_MISSING means the record cannot be confirmed. Do not rely on setup information from a record that cannot be verified.

What verification proves

A VERIFIED result proves one specific thing: the canonical payload archived under this SNAP ID is the same payload that was recorded when the hash was computed. The record has not been silently changed.

SHA-256 payload-integrity check: If a stored payload changes after archival, recomputing its SHA-256 hash would no longer match the SNAP ID. The check is limited to recorded payload integrity.
Historical audit: You can verify any SNAP ID from a past evaluation to confirm the record at that point in time was accurately archived.
Provenance: SNAP verification is a chain of provenance: the evaluation happened, a canonical payload was produced, a hash was published, and the archived copy matches.

What verification does not prove

Not trade profitability: VERIFIED does not mean a trade at the published entry would have been profitable. The record is intact, but market outcomes are separate from record integrity.
Not exchange confirmation: Syntalium has no connection to any exchange. SNAP verification is a check of the published record — not a confirmation of any order fill, execution price, or trading outcome.
Not current validity: A VERIFIED record from a past evaluation is an accurate historical record. It does not mean the setup is still active, fresh, or within its validity window today.
Not suitability: A verified published setup was not assessed against your account size, financial situation, or risk tolerance. Verification is not advice.