Skip to content
Warrantv0.1

Confidentiality

Requests are sealed to the TEE key. Evaluation is not yet attested, and the trace says so.

The request is sealed with HPKE to the live TEE key; the evaluation runs on the host; and the attestation string on every trace tells you which of those you are getting.

rialo:host-evaluated:1786788003:2418:b1946ac92492d2347c6235b4d2611184

The claim, split honestly

ConcernStatus
The spec and credentials in transit to REXSealed. HPKE to the live TEE key, fetched from the node.
The evaluation itselfOn the host. Not inside an attested enclave.
What the trace claimsrialo:host-evaluated:, never rialo:enclave:.

If you need "the payload was never visible to the operator", that is not supported for the evaluation step today. The attestation prefix is how you tell, and it will change only when the fact changes. See REX.

Evidence is hashed, not hoarded

Raw third-party payloads are never stored in full. What evidence keeps is:

  • content_hash — a digest of the bytes fetched
  • redacted_preview — a trimmed extract for a person reading an escalation
  • expires_at — which retires the preview while the hash stays

The two lifetimes are the design. Months later you cannot re-read a supplier's response, but you can still prove whether bytes someone shows you are the bytes that were checked — which is the claim a dispute turns on. A system that retains every response it ever fetched is a data-retention problem wearing a verification system's clothes.

The public trace redacts a person

/t/:id is a receipt anyone can open without an account, so it is deliberately narrow:

  • only settled warrants resolve — a held warrant is live operational state
  • the organisation is never named, and neither is any person
  • actor.id is stripped, because a public receipt naming who approved a payment would let anyone holding two links work out who approves what

payload_hash still covers the full unredacted record, and the response states which fields were removed. The hash will therefore not match the redacted body you can see — that is intended, and naming the removed fields is what makes it checkable rather than mysterious.

Secrets never reach a browser

The console is a backend-for-frontend. The session is an httpOnly cookie on the console's own origin, forwarded server-side; no token reaches client JavaScript. Nothing sensitive is in localStorage, and NEXT_PUBLIC_ is lint-enforced against anything that looks like a secret, because that prefix inlines a value into the browser bundle permanently.

Notifications carry facts, not authority

A push or Telegram message about an escalation carries four things: amount, payee, which clause failed, and time remaining. Enough to decide from a lock screen.

It carries no ability to act. The Telegram bot cannot release funds — it can only hand off to the console, where a passkey signs the decision — and there is a test asserting no Telegram-scoped route can settle anything. The one-time approval link resolves only for the person it was minted for, and burns on first use, so a forwarded message is worth nothing.

What is not claimed

  • No end-to-end encryption between you and a payee.
  • No confidential compute for the evaluation, yet.
  • No recipient screening.
  • No onchain custody — see contracts.