ZSP Shield — the secure-payload protocol
ZSP (Zeq Secure Protocol) is a layered shield for a payload. Where HITE encrypts, ZSP runs a pipeline — several protections in sequence — and hands back a signed envelope with six independent verification tags, so a receiver can check not just that the payload decrypts, but that every stage of its protection holds.
Protect — four layers, one envelope
POST /api/zsp/protect runs the payload through, in order:
Compress
A spectral compression pass — smaller, and the first transform in the chain.
Scan
The payload is scored through the HF forensic operators — the same anti-hallucination spectrum the Forensic Dashboard uses.
Authenticate & encrypt
A temporal authentication layer, then encryption — sealing the result under the clock.
The output is a signed envelope carrying six verification tags, each attesting a different property of the protection.
Unprotect — reverse, and verify all six
POST /api/zsp/unprotect doesn't just decrypt — it reverses every layer and verifies all six tags
before returning anything: the temporal, chaos, and spectral transforms, the tether, the
authentication, and a conservation check (NM27 — conservation of momentum) that confirms nothing was
altered in transit. If any check fails, you don't get a best-effort payload — you get a refusal, in
keeping with the framework's honesty doctrine. Both endpoints are public, so ZSP is usable without a
key.
Where it fits
ZSP is the heavier sibling of HITE: reach for HITE when you want fast, clock-bound encryption; reach for ZSP Shield when you want a payload wrapped in a verifiable stack of protections with a proof for each layer. It's what backs the framework's own secure-payload handling.
Open it
Read next
- HITE encryption — the single-layer clock-bound cipher.
- Forensic Dashboard — the HF operators ZSP scans through.
- The Zeq envelope — how signed envelopes and their tags are checked.