Verify every request without trusting the dashboard.
HashIQ is the proof surface for TaskQ. Use the Chain API to look up signed entries, confirm request and response hashes, inspect placement proof references, verify external anchors, and export evidence.
Look up proof by request ID.
Relay responses and Queue jobs return a request ID and chain key. Use them to fetch the signed proof entry and related placement, credential, worker, usage, and settlement references.
curl https://api.taskq.xyz/v1/chain/req_01J... \ -H "authorization: Bearer $TASKQ_API_KEY"
{
"request_id": "req_01J...",
"chain_key": "sha256:...",
"event_type": "request.closed",
"plane": "relay",
"policy_hash": "sha256:...",
"placement_proof_hash": "sha256:...",
"credential_fpr": "sha256:...",
"worker_ref": "worker_blind:...",
"anchor_status": "verified"
}Understand a chain entry.
A chain entry stores hashes, references, signatures, and replay data. It does not store raw provider credentials, raw PHI, or raw privileged matter names.
Verify an entry.
The verifier checks the signature, previous hash, entry hash, request/response canonical hashes, placement proof hash, settlement reference, and anchor membership.
curl https://api.taskq.xyz/v1/chain/verify \ -H "authorization: Bearer $TASKQ_API_KEY" \ -d '{ "request_id": "req_01J...", "include_anchor": true, "include_placement_replay": true }'
signature — who signed it?
Confirms the entry was signed by the expected HashIQ key.
hash chain — was it rewritten?
Checks prev_hash and entry_hash continuity across the range.
anchor — was it witnessed?
Confirms the entry belongs to an externally anchored range.
Follow placement proof references.
The chain does not need to dump the entire worker universe into each entry. It records a placement proof hash and registry snapshot reference so an auditor can replay the decision when permitted.
Eligible set — no cheaper compliant worker skipped
Replay confirms the chosen worker satisfied hard constraints and won under deterministic selection rules.
Refusal proof — no compliant capacity means no execution
Blocked requests can still write proof that TaskQ refused to violate policy.
Verify external anchors.
Hash chaining alone is not enough if nobody else sees the chain head. Anchor records publish range roots to witnesses so silent rewrites become detectable.
{
"range_start_seq": 184000,
"range_end_seq": 184999,
"range_root": "sha256:...",
"published_at": "2026-06-12T00:05:00Z",
"witnesses": ["taskq:ed25519:...", "customer:ed25519:...", "tsa:..."]
}Export a signed chain segment.
Exports include chain entries, placement proofs, credential access events, registry snapshot proofs, anchor proofs, and verifier metadata. Export is the honest moat: customers can leave with their evidence.
curl "https://api.taskq.xyz/v1/chain/export?from=2026-06-01&to=2026-06-12&format=bundle" \ -H "authorization: Bearer $TASKQ_API_KEY" \ -o taskq-chain-export.bundle
Portable — evidence moves with the customer
The customer can export their signed segment without losing verifiability.
Non-backfillable — history cannot be bought tomorrow
A competitor can store exported history, but cannot witness yesterday's chain.
Keep sensitive identifiers out of recoverable chain form.
Use HMAC-peppered references for PHI and privileged matter references. The chain can prove consistency without exposing raw names or making dictionary attacks easy.
bad: sha256(patient_name_or_matter_id) good: HMAC(customer_private_pepper, normalized_reference)
Proof should survive outside TaskQ.
The chain is valuable only when the customer, auditor, or partner can verify the record independently. That is why exports include enough metadata to verify signatures, range roots, anchor membership, and placement proof references.