Finding Status

A validly signed lower epoch still fails at the floor

The feed records one status value, retracted. A finding is live at an epoch when that epoch proves no leaf holds its key, so absence is the live state. The buyer accepts an epoch only at or above the floor it has recorded for the same pinned feed and operator authorization.

In this run the buyer has accepted epoch 12. A proof at epoch 11 is rejected even with a valid signature. An epoch 12 with a different epoch ID or root conflicts with the floor. A valid epoch 13 with the exact key absent passes and advances the floor; the same epoch carrying a retraction leaf makes the finding non-live. Once a retraction is observed, an absence proof at a later epoch is rejected as a revival.

Passing the status check lets the other purchase checks continue. Paid reveal rechecks current finding status before capture and output release.

The proof travels inside the purchase

A status answer is a set of bytes anyone can recheck. The feed is a 256-bit sparse authenticated map whose key path comes from the finding ID and a fixed numeric nonce, so a finding keeps one position for the life of the feed. A non-inclusion path carries one sibling hash per level, and a verifier recomputes the root from it without asking the operator.

{
  "chio_finding_status_proof_b64": "<base64 of the canonical status proof>"
}

The buyer places the canonical proof, base64 encoded, under the reserved governed-intent key chio_finding_status_proof_b64, and a purchase-marked reveal without it is refused. On a matched delivery the kernel stamps what it checked into the finding_delivery receipt block as status_proof: the feed ID, the nonce, the map epoch, the signed-epoch envelope digest, the proof digest, the root hash, and the trusted-time observation the proof bound. Each value comes from the proof and its epoch, never from caller metadata.

The floor survives restarts and key rotation

An operator that keeps signing a superseded root, or signs two roots at one epoch, produces records that each verify alone. Every acceptor therefore stores a durable high-water mark for the admission-pinned feed and operator authorization: the feed ID, the operator ID and rotation policy, the key domain nonce, the operator key epoch, and the tuple (map_epoch, epoch_id, root_hash). Five observations are rejected against it.

• Regression. A map_epoch below the floor, even with a valid signature.
• Equivocation. The same map_epoch with a different epoch ID or root.
• Key equivocation. The same operator key epoch with a different operator key.
• Authorization regression. An operator key epoch below the recorded one.
• Revival. A non-inclusion proof for a finding already observed retracted.

A locally observed retraction is sticky and is stored beside the floor. An authenticated retraction whose epoch sits below the floor still rejects as a rollback, and the retraction is retained, so a later higher-epoch absence proof cannot revive the finding. A restart that finds no floor for a feed the deployment declares established fails closed. Rotation keeps the feed identity, the key domain, the map semantics, and the floor.

Every trust input of chio finding status is a required flag, because each supplies something the proof cannot establish about itself. The command fetches the venue-verified portable status proof for one finding.

chio finding status \
  --id "$FINDING_ID" \
  --feed "$STATUS_FEED" \
  --operator-authorization operator-authorization.json \
  --service-bond service-bond.json \
  --rollback-floor status-floor.json \
  --max-epoch-age-secs "$MAX_EPOCH_AGE"

chio finding verify applies the same rule to finding verification: --status-rollback-floor is required whenever the evidence bundle carries a portable status proof, and it may point at the same floor file. Command flags describes each input.

A retraction stops later sales and quarantines later reads

A retraction comes from the seller, or from a final enforcement decision after the seller impairment is confirmed. A bare challenge outcome or a reversible hold never inserts one; the challenge and appeal path ends in that final decision.

Publication is coupled to enforcement. The appeal-final transition atomically persists its outcome, a publication_pending marker, and one idempotent retraction outbox item before any external effect, and pending status refuses new sales. The item stays dispatch-ineligible until the exact seller impairment is confirmed final, and the liability settles only after publication is confirmed, so a failed, ambiguous, or quarantined impairment never publishes an irreversible retraction.

After appeal finality, SlashBond distributes the slashed collateral pro rata to the verified harmed purchases, with the remainder to the registered community fund, and the outbox inserts the finding's key and publishes a new signed epoch.

For a buyer that already holds the finding, an opt-in profile of MemoryGovernanceGuard governs later reads. The profile pins a resolver instance and the admission-pinned feed ID, and the guard refuses to build without the resolver it names. For one exact memory key the resolver composes three durable boundaries.

1. Provenance. The kernel's verified memory-provenance chain resolves the store and key to the governed write receipt and capability.
2. Lineage. A verified typed lineage edge resolves that write to its parent finding-delivery receipt and finding ID.
3. Status. An authenticated local status cache, built only from an authorized signed epoch and a verified portable proof, resolves the finding to Live, Pending, or Retracted against that feed.

A missing, unavailable, stale, or cross-bound value at any boundary fails closed. When the resolver is unavailable or the finding is no longer live, the guard refuses the read and marks that key quarantined locally, and the stored value stays in place for audit.

A transient resolver failure can clear after a verified live result; an observed retraction stays durable. The guard derives no new state and leaves untouched any entries the buyer later derived from the payload; tracing those is downstream work over the receipt trail. Outside this profile, memory behaves as it does by default.

A fresh root proves the keys it includes

A fresh signed root proves consistency with the keys it includes. Whether the operator inserted every intent it owed is outside what any proof over one root can show, so the completeness of voluntary and cross-operator retractions rests on the signed intent, the inclusion window, alerts, and a slashable service bond.

• Signed intent. Each voluntary or cross-operator request carries an authenticated retraction-intent receipt and a bounded inclusion service level. A fresh root that omits a known pending intent is censorship and stays refused.
• Service bond. A qualified operator keeps a live service bond allocated to the feed. Its signed policy names the objective missed-inclusion and equivocation conditions, the inclusion window, the evidence source, and the penalty path. Admission rejects a missing, expired, revoked, underfunded, or differently allocated bond.
• Race window. A retraction published between a buyer's proof check and the close of its sale lands too late for that sale. The freshness window and the maximum epoch age set how wide the window is.

An operator job publishes epochs on the operator's own schedule, such as an external cron job. Anchoring cadence and status cadence are configured and monitored separately.

Read more in the Cognition Market threat model, which ranks selective omission and equivocation with the market's other residual risks.

Next: buy against a status proof