See what it returns.

01Screening a deposit address

Before crediting, you send the addresses involved. Each comes back with one of three verdicts, the evidence behind it, and the health of the collector that would have seen a freeze against it.

The second address has an outstanding freeze on record. The match carries when it executed, the block, the transaction, and the hash of the stored response it was read from. The first address is clear, and the collector that would have seen a freeze against it is reporting and current.

What each verdict does to the deposit

• FROZEN An outstanding freeze is on record against the address. The deposit is not credited; the match and its snapshot are where review starts.
• CLEAR Nothing outstanding, and every collector for that chain is inside its freshness threshold. Both halves are required. It is the only verdict from this check that does not stop the deposit.
• UNKNOWN HOLD Anything else: a collector that is stale or blind, or a signal that cannot be interpreted. Treated as HOLD.

02Coverage health

Every response states what the system could see at the moment it answered. That is the difference between "no alert" and "we cannot see", two situations that look identical in a product that does not say which one you are in.

The second authority is not observable right now, and its last verification is well behind the first. A deposit in its scope is held until that changes.

The same statement travels with address readings, one line per capability. Here transfer collection is STALE and says since when; account and freeze collection are current.

A change of status is delivered as its own event, so a client learns of a blind spot without polling for it.

The statuses

OK

The collector is reporting and inside its freshness threshold.

STALE

The collector's data is older than its threshold. A property of the collector, never of a signal, and never an all-clear: it is a known blind spot.

BLIND

An authority is registered, and no collector is reporting for it at all.

Since

When the current status began. An interruption notice that cannot say since when gets ignored, so the time is part of the answer.

03Monitoring your own addresses

The addresses you hold are watched continuously. Five readings come back for each: the account as it stands, its transfers, each day of its ledger, roll-ups across addresses and periods, and how much of its history is proven loaded.

The account as it stands

A balance that could not be read is marked unavailable. It is never shown as zero.

Transfers

Each transfer is published the moment it is seen and then followed to finality. The states:

provisional

Seen at one confirmation and published at once. It may still change, so it is never presented as settled.

final

Past the chain's finality threshold, and no longer expected to change.

reverted

Removed by a chain reorganisation. The record is kept and announced as its own event. It is never silently deleted, because a client that only saw a deletion would never learn of it.

One day of the ledger

"Everything seen" includes transfers that are still provisional; "final only" counts those past finality. Near the head of the chain the two differ, and the difference is not an error. A total that has to be right is read from the ledger, never added up from alerts.

Until history is loaded, the day is marked incomplete. It is never shown as a settled total.

Roll-ups

Each address carries its own completeness. An address that cannot be included is listed with the reason, not dropped from the total without a word. Net is arithmetic on one asset: different assets are never added together, and no price is applied. The same figures are available by day, week or month for a single address.

How much history is proven

Completeness is stated per asset, not per address. Where an asset's past can be read from only one independent source, there is nothing to check it against, so its history is never reported as complete. It stays marked as not proven rather than becoming "complete" because nothing contradicted it. Asset identifiers in this panel are generic placeholders.

04Evidence

The external responses a verdict or a ledger line rests on are stored once, under the hash of their content. Records point to that hash rather than restating what it says.

1. 01 The hash is computed over the stored response, byte for byte as it was received.
2. 02 Storage is append-only. A stored response cannot be rewritten, including by us.
3. 03 Given the bytes, anyone can recompute the hash and compare. If it matches, the record points at exactly what it says it points at.

How evidence is kept and exported →

Where to go next

The product pages explain each readout and its limits. The API reference is the contract these panels follow.

• Product overview →
• API reference →
• Documentation →
• Research · the execution window, quarter by quarter →

Questions about any panel on this page: hello@4shock.xyz