Multi-Witness Anchoring

Asqav anchors every receipt to more than one witness, so the "when" of a receipt does not rest on a single party's word. Each receipt carries an anchors[] array. One entry is a quantum-safe timestamp token Asqav signs itself. The other is anchored to the Bitcoin blockchain, which no operator and no vendor controls. An auditor checks the time a receipt claims by checking those witnesses, not by taking anyone's word for it.

What it is: two timestamp witnesses on every receipt, recorded in the anchors[] array.

What it proves: when the receipt existed, established by two parties with different trust properties.

The independent one: the Bitcoin anchor, which holds even if someone later distrusts Asqav.

Two witnesses ship today

Every receipt is anchored to two witnesses with different trust properties:

Each is described in full below.

• A quantum-safe RFC-3161-shaped timestamp token, signed by Asqav. Asqav operates its own timestamp authority and signs each token with ML-DSA-65 (NIST FIPS 204), the post-quantum signature scheme, so the time attestation survives into the same retention horizon as the receipt itself. This token is tamper-evident: it binds the signing time to the receipt digest, and any change to either is detectable. It is signed by Asqav, so it is not independent of Asqav. The token is preserved on the receipt as the rfc3161 anchor entry.
• OpenTimestamps anchored to the Bitcoin blockchain. The receipt digest is submitted to the OpenTimestamps calendars, which fold it into a Bitcoin transaction. Once the calendar upgrades the stamp into a confirmed block, the receipt's opentimestamps anchor entry carries the inclusion proof and the anchoring block hash. Bitcoin is a public chain that no single entity governs, so this witness is independent of both the operator running the agent and Asqav.

The genuinely independent witness here is the Bitcoin anchor. Asqav's own timestamp token adds a post-quantum, tamper-evident record of when Asqav signed. The Bitcoin anchor adds a record that holds even if someone later distrusts Asqav. The two witnesses cover different failure modes, which is why both ship.

The anchors array

The two witnesses project into the receipt as a spec-shape anchors[] array. Each entry names its type and carries the proof:

{
  "anchors": [
    {
      "type": "rfc3161",
      "value": "<base64 TimeStampToken, ML-DSA-65 signed>"
    },
    {
      "type": "opentimestamps",
      "value": "<base64 OpenTimestamps proof>",
      "status": "anchored",
      "anchor_block_hash": "<bitcoin block hash>"
    }
  ]
}

The conformance suite validates both anchor types. A receipt that claims an anchor it cannot prove is refused, the same way a receipt that claims a policy decision it never made is refused.

Why a public-chain witness matters to regulators

Two regulations turn independent integrity evidence from a "nice to have" into a written control:

• DORA Articles 28 to 30 (EU Regulation 2022/2554) require an in-scope financial entity to keep auditable evidence of the services its ICT third parties provide, and to give regulators and the entity itself the means to verify that evidence over the contract lifecycle. Evidence whose timeline rests on one party's word is weaker than evidence anchored to a party outside that party's control. The Bitcoin anchor gives the entity a timeline element it can defend without asking the regulator to trust Asqav.
• EU AI Act Article 12 (Regulation (EU) 2024/1689) requires high-risk AI systems to keep automatic, tamper-evident records of their operation over the system lifetime. A record whose timestamp can be rewritten after the fact is not tamper-evident in the sense Article 12 asks for. Asqav's signed timestamp token makes the receipt's own time tamper-evident, and the Bitcoin anchor adds a witness outside Asqav's control, so the "when" of the record resists after-the-fact rewriting.

See DORA Articles 28-30 and the EU AI Act profile for the full regulation-by-regulation mapping.

The third-party-notary connection

A first-party logger is a vendor signing its own logs, including the time those logs claim. The party producing the record and the party attesting to it are the same party. That is the structural weakness Asqav's third-party-notary posture is built to remove: Asqav is unaffiliated with the agent vendor and with the regulated entity, so the receipt it signs is not the vendor's account of itself.

Multi-witness anchoring adds a second, independent layer at the timestamp level. Asqav's signed token says when Asqav recorded the action, with post-quantum protection over the retention window. The Bitcoin anchor says the digest existed no later than a named public block, and that statement holds even if someone later distrusts Asqav. The timeline does not collapse to one trusted party.

How verification works

A verifier checks each witness's proof on its own terms. The proof for each witness is stored inside the receipt:

• For the rfc3161 anchor, the verifier validates the timestamp token and confirms the ML-DSA-65 signature over the receipt digest, so any change to the signed time or the digest is detectable.
• For the opentimestamps anchor, the verifier replays the inclusion proof against the named Bitcoin block, confirming the receipt digest was committed to the chain at or before that block's time, with no dependence on Asqav.

Neither check requires a call to Asqav. The receipt's own signature is checked against the public verify key published at GET /.well-known/jwks.json, and the wire format and verification procedure are published in draft-marques-asqav-compliance-receipts on the IETF Datatracker. The verifier trusts the math and the public-chain witness, not the operator.

Explicit N-of-M witness policy

A caller can declare an explicit N-of-M witness quorum on the signed action through the witness_policy wire field. An operator or a regulator can then require that a configurable number of independent witnesses anchor each receipt before it counts as durably anchored.

The field carries the shape {"required": <int>, "witnesses": ["rfc3161", "opentimestamps"]}:

• required sits in the range from 1 to the length of witnesses
• witnesses is a non-empty subset of the two shipped witnesses, rfc3161 and opentimestamps
• a witness named rekor is rejected.

A receipt reaches witness_quorum_met only when required of the named witnesses hold a real inclusion proof. The flag is server-computed, not caller-asserted, so the quorum reflects what the witnesses actually attest rather than what the caller declared.

In the SDK, the Python client takes the policy as the witness_policy= keyword argument and the TypeScript client takes it as the witnessPolicy: property. Both project to the same witness_policy wire field.

agent.sign(
    "payment:transfer",
    witness_policy={"required": 2, "witnesses": ["rfc3161", "opentimestamps"]},
)

The witness_policy_required_exceeds_confirmed guard fires when a receipt claims durable anchoring without meeting its declared quorum: witness_policy receipts that claim durable anchoring must have at least required witnesses holding an inclusion proof. A receipt that claims a quorum it cannot prove is refused, the same way a receipt that claims an anchor it cannot prove is refused.