Core architecture

VACT-P defines a unified structure for verifiable multi-agent communication. Every material request or transaction is a signed object wrapped in a universal envelope, evaluated against an explicit authority chain, and recorded as a receipt.

Five logical planes

An implementation MAY combine these planes into one service — conformance is behavioral, not topological.

Identifiers & time

Every VACT-P object has a globally unique id — a URI or URN, treated as opaque unless its scheme defines resolution, generated with at least 128 bits of collision resistance. Timestamps are RFC 3339 UTC. Digest references use urn:sha256:<base64url-without-padding>.

urn:uuid:0198f2b8-34d2-7a10-b344-6a05d967d12f
did:web:agents.example.com:researcher
https://agents.example.com/id/researcher
spiffe://example.com/prod/agent/researcher

Agent identity

A VACT-P interaction distinguishes three identities. A receiver must not assume that proof of logical identity also proves runtime integrity.

Agent Passport

Every externally accessible agent MUST publish a signed Passport describing its controller, supported versions and profiles, endpoints, verification keys, capabilities, validity interval, and revocation location. Discovery defaults to a well-known HTTP location:

GET /.well-known/vact-agent.json

A resolver MUST validate the Passport's proof, validity interval, and revocation status before relying on it.

The universal envelope

Every message in VACT-P uses the vact_p envelope. It establishes sender and recipient identity, carries cryptographic nonces for replay prevention, links causally to prior messages, and wraps the payload with a signed proof.

{
  "vact_p": "0.1",
  "id": "urn:uuid:0198f2b8-34d2-7a10-b344-6a05d967d12f",
  "type": "vact_p.task.request",
  "mode": "async",
  "sender": "did:web:client.example",
  "recipients": ["did:web:provider.example"],
  "conversation_id": "urn:uuid:0198f2b0-2840-7f89-b7de-d02838926fa0",
  "task_id": "urn:uuid:0198f2b6-41fe-7e00-918f-a59660768f4d",
  "causation_id": "urn:uuid:0198f2b5-28b3-7b00-85fc-e36e4454f8d0",
  "traceparent": "00-5b8aa5a2d2c872e8321cf37308d69df2-051581bf3cb55c13-01",
  "sequence": 14,
  "issued_at": "2026-08-01T07:00:00Z",
  "expires_at": "2026-08-01T07:05:00Z",
  "nonce": "q3op2nJQ1ufnQ-kcY8sxIg",
  "authority_chain": ["urn:uuid:0198f1f0-bf95-75a8-80e4-f06acf4b42e5"],
  "policy": {
    "required": ["urn:sha256:policyDigest"],
    "data_classification": "confidential",
    "retention": "none"
  },
  "economics": {
    "contract_id": "urn:uuid:0198f2a8-977f-78cb-b7cd-6249efb5108a",
    "maximum_amount": "5.00",
    "currency": "USD"
  },
  "payload": {},
  "proof": {}
}

Required fields

vact_p, id, type, mode, sender,recipients, sequence, issued_at, expires_at,nonce, payload, and proof are required on every envelope.

Message modes

Causal linkage & sequencing

A response sets causation_id to the message that directly caused it. Messages in the same interaction share a conversation_id; messages affecting one durable task share atask_id. Sequence numbers are scoped to (sender, conversation_id) — a receiver must detect duplicates and must not treat sequence order as proof of wall-clock order across different senders.

Signing: JCS + Ed25519

VACT-P 0.1 requires SHA-256 digests, Ed25519 signatures, and the JSON Canonicalization Scheme (RFC 8785) for deterministic JSON signing. To sign an object: construct it in full except proof, validate it as I-JSON, serialize with JCS, sign the exact canonical bytes, and attach the result.

{
  "proof": {
    "type": "VACTSignature2026",
    "alg": "Ed25519",
    "kid": "did:web:agents.example.com:researcher#key-2",
    "created": "2026-08-01T07:00:00Z",
    "signature": "base64url..."
  }
}

A verifier removes only the top-level proof, reproduces the JCS bytes, resolveskid, confirms the key was valid and unrevoked at created, verifies the signature, and separately validates every application-level timestamp and constraint.

Task state machine

A task moves through a rigid, durable state machine. Every transition is a signed, idempotent object that references the task, the actor, a timestamp, and a reason code.

If a dispute arises or execution fails, transitions lead to terminal states instead:

A receiver must reject any transition that is not valid from the current state.

Receipts & the audit chain

Each step of execution — policy decision, task transition, execution, evaluation, settlement — produces a signed receipt. Every receipt links to the previous one via prev_receipt_digest, forming a tamper-evident, hash-chained ledger any auditor or the original Principal can walk retrospectively.

See Authority model for how mandates and delegations produce the chain a receipt is checked against, and Security & threat model for transparency anchoring and audit-journal guarantees.