ACTIS v1 — Compatibility and Verification Algorithms

Version: 1.0
Status: Normative
Entrypoint: ACTIS_STANDARD_v1.md

This document defines the normative algorithms for ACTIS v1.0 verification: envelope hash construction, round and transcript hashing, signature verification, and the actis_status decision tree. Implementations MUST follow these algorithms to be conformant.

Normative: The algorithms and decision rules in this document are normative. Formulas and worked examples are labeled informative.

1. Normative Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as in RFC 2119 and RFC 8174.

2. Envelope Hash Construction

envelope_hash is a round-local digest. It is the hash of a canonical JSON serialization of the round’s envelope object. The signature in the round is computed over this digest (the 64-character hex string), not over the raw envelope. The envelope object MUST NOT include the signature or the envelope_hash field itself.

2.1 Envelope Object (round-local)

The envelope object is a JSON object containing only the following round fields, with all other round fields excluded:

Included (if present in the round):

• round_number
• round_type
• message_hash
• timestamp_ms
• previous_round_hash
• round_hash (optional in round; include in envelope object only if present in the round)
• agent_id (optional; include only if present)
• public_key_b58 (optional; include only if present)
• content_summary (optional; include only if present)

Excluded:

• envelope_hash — excluded so the digest is not self-referential.
• signature — excluded; the signature is over the digest of the envelope, not part of the envelope.

No transcript-level fields (e.g. transcript_id, intent_id) are part of the envelope. The envelope is round-local only.

2.2 Serialization and Digest

1. Build the envelope object from the round by taking only the included keys listed in §2.1 (with the same values as in the round). Omit any key not present in the round.
2. Serialize the envelope object to canonical JSON per RFC 8785 (JSON Canonicalization Scheme, JCS): deterministic key ordering, no unnecessary whitespace, deterministic encoding of numbers and strings. Implementations MUST use an RFC 8785–compliant canonicalizer (or equivalent that produces the same output). Strings MUST be interpreted exactly as encoded in the JSON document without Unicode normalization.
3. Compute SHA-256 over the UTF-8 encoding of the canonical JSON string.
4. Encode the digest as exactly 64 lowercase hexadecimal characters (no prefix, no spaces).

Formula (informative):

envelope_object = { round fields except "envelope_hash" and "signature" }
envelope_hash = to_lower_hex( SHA-256( utf8( canonical_json( envelope_object ) ) ) )

2.2.1 Encoding Rationale (Informative)

ACTIS v1.0 uses RFC 8785 (JCS) as the canonical serialization for all hash inputs. JCS was chosen for the following reasons:

• Human-readable without a decoder. JSON transcripts can be inspected by auditors, legal reviewers, and compliance teams using any text editor, without tooling dependencies.
• Low integration barrier. JSON parsers are available in every major language and runtime. Enterprise integrators can adopt ACTIS without introducing binary encoding dependencies.
• Deterministic under RFC 8785. JCS defines unambiguous key ordering, number encoding, and string handling. Implementations that follow RFC 8785 produce byte-identical output for the same logical input.

CBOR as a tracked v2 path. Deterministic CBOR (RFC 8949 + RFC 8943 or CBOR Deterministic Encoding) offers stricter encoding guarantees, smaller wire size, and no dependence on a canonicalization layer over an inherently order-agnostic format. These properties make it a strong candidate for a future ACTIS v2 encoding profile. The decision to use JCS in v1 is pragmatic and intentional; implementers who raise CBOR as a concern will find this documented answer rather than silence.

Implementations MUST NOT substitute CBOR or any other encoding for JCS in ACTIS v1.0. A future version that adopts CBOR will define a new canonicalization algorithm identifier and maintain a separate conformance corpus.

2.3 Signature Binding

The signing message is the 40-byte concatenation of the UTF-8 encoding of the domain string "ACTIS/v1" (8 bytes) followed by the 32-byte binary value obtained by hex-decoding the round's envelope_hash field (64 lowercase hex characters):

signing_message = utf8("ACTIS/v1") || hex_decode(envelope_hash) // 8 + 32 = 40 bytes

Implementations MUST construct the signing message exactly as above. The domain string prevents cross-protocol signature reuse. The raw hex-decoded envelope_hash alone is NOT the signing message, and the UTF-8 encoding of the hex string is NOT the signing message.

Verifiers MAY recompute the envelope object from the round (excluding envelope_hash and signature), compute the digest, and compare it to the round's envelope_hash to detect tampering of envelope fields.

2.4 Informative example (pseudocode)

Round (excerpt):
  round_number: 0
  round_type: "INTENT"
  message_hash: "a1b2..."
  envelope_hash: "<to be computed>"
  signature: { ... }   // not part of envelope

Envelope object (input to hash):
  { "message_hash": "a1b2...", "previous_round_hash": "c3d4...", "round_hash": "e5f6...", "round_number": 0, "round_type": "INTENT", "timestamp_ms": 1709500000000 }

Canonical JSON string → SHA-256 → 64 lowercase hex → envelope_hash.
Then: signing_message = utf8("ACTIS/v1") || hex_decode(envelope_hash).  // 8 + 32 = 40 bytes
      signature = Ed25519_sign(signing_message).

3. Round and Transcript Hashing

3.1 Round 0 — previous_round_hash (genesis)

For round 0 there is no previous round. The genesis value is:

previous_round_hash = to_lower_hex( SHA-256( utf8( intent_id + ":" + created_at_ms ) ) )

intent_id and created_at_ms are the transcript-level values. The string is the concatenation of intent_id, the literal character :, and the decimal representation of created_at_ms (no leading zeros, no JSON wrapping). No Unicode normalization or trimming is applied to intent_id.

3.2 Round hash (per round)

For each round, the round_hash is the SHA-256 digest of the canonical JSON serialization of the round object excluding the round_hash and signature fields. RFC 8785 canonicalization MUST be used. The result is 64 lowercase hex characters.

round_object_for_hashing = round with keys "round_hash" AND "signature" removed
round_hash = to_lower_hex( SHA-256( utf8( canonical_json( round_object_for_hashing ) ) ) )

Invariant: hash_chain_ok MUST NOT depend on signature verification. Signatures are attestations, not structural state; they are excluded from structural hashing.

3.3 Chain linkage

For round index i > 0, round[i].previous_round_hash MUST equal the round_hash of round i-1 (or the digest computed from round i-1 as in §3.2 if round_hash is omitted).

3.4 Final hash (transcript)

The final_hash of the transcript is the SHA-256 digest of the canonical JSON serialization of the entire transcript object excluding the final_hash field. The model_context field (if present) is excluded from the object before serialization so that MRM metadata does not affect determinism. RFC 8785 MUST be used. The result is 64 lowercase hex.

transcript_for_hash = transcript with "final_hash" and "model_context" removed
final_hash = to_lower_hex( SHA-256( utf8( canonical_json( transcript_for_hash ) ) ) )

3.5 Hash Chain Framing (Informative)

A common attack against hash-chain protocols is framing ambiguity: if a chain is constructed by raw concatenation of variable-length fields, then hash("ab" + "c") equals hash("a" + "bc"), allowing an attacker to produce two different logical inputs that yield the same hash.

ACTIS v1.0 is not vulnerable to this attack. The round_hash and final_hash are computed over the RFC 8785 canonical JSON serialization of a structured object, not over raw field concatenation. RFC 8785 produces an unambiguous, length-delimited encoding for every field. Two distinct JSON objects with different field values or structure cannot produce the same canonical serialization, and therefore cannot produce the same hash.

Implementations MUST use an RFC 8785-compliant canonicalizer. The use of raw string concatenation or non-canonical serialization in place of JCS is a conformance defect and voids the framing ambiguity protection.

3.6 Replay Determinism (Normative)

Replay MUST be deterministic. Two conformant verifiers presented with the same bundle MUST produce identical hash_chain_ok and replay_ok results.

The following are forbidden sources of nondeterminism in replay:

• Timestamps and wall-clock time — Verifiers MUST NOT read the system clock during replay. All timestamps used in hash computation MUST come from the transcript fields.
• Random number generation — Verifiers MUST NOT use RNG during replay.
• Locale and collation — Verifiers MUST NOT apply locale-specific string ordering or comparison during canonicalization. RFC 8785 key ordering is lexicographic by Unicode code point, not locale-dependent.
• Floating-point serialization — Verifiers MUST NOT use platform-specific float-to-string conversion. RFC 8785 defines deterministic number encoding; implementations MUST follow it.
• Unicode normalization — Verifiers MUST NOT apply NFC, NFD, NFKC, or NFKD normalization to string values during canonicalization. Strings MUST be interpreted exactly as encoded in the JSON document.

Any input that affects replay outcome MUST be recorded in the transcript itself. External state that is not recorded in the transcript MUST NOT affect replay.

4. Signature Verification

• Scheme: ACTIS v1.0 supports Ed25519 only. The signature is a detached Ed25519 signature.
• Message signed: The signing message is the 40-byte concatenation of utf8("ACTIS/v1") (8 bytes) and the 32-byte binary value obtained by hex-decoding the round's envelope_hash field (64 lowercase hex characters → 32 raw bytes): signing_message = utf8("ACTIS/v1") || hex_decode(envelope_hash). Implementations MUST use this exact construction. The raw hex-decoded envelope_hash alone is NOT the signing message.
• Verification: The verifier MUST decode signature.signer_public_key_b58 and signature.signature_b58 (Base58), construct the 40-byte signing message as utf8("ACTIS/v1") || hex_decode(envelope_hash), and verify that the signature is valid for the public key over that message. If the round’s public_key_b58 is present, it MUST match signature.signer_public_key_b58 for the round to be considered valid.

5. Manifest and Bundle Rules

Manifest: The bundle MUST contain a manifest.json at the root (or path declared in the bundle format). The manifest MUST include a core_files array: relative paths, unique, forward slashes, no ../, no absolute or drive paths. The minimal ACTIS core set is ["checksums.sha256", "manifest.json", "input/transcript.json"]. See ACTIS_AUDITOR_PACK.md §2 and schema actis/schemas/actis_manifest_v1.json. The checksum file (e.g. checksums.sha256) MUST NOT list itself; it lists the other core files only.

Bundle security:

• Checksums apply only to paths listed in core_files. Only those paths are in the ACTIS verification surface. Unlisted files MUST NOT affect actis_status; verifiers SHOULD warn when unlisted files are present.
• Core file paths in the manifest MUST be unique. Duplicate archive entries for the same core path MUST result in ACTIS_NONCOMPLIANT. Symlinks for core paths MUST be rejected. Path traversal (e.g. ../, absolute paths, drive prefixes) in core paths MUST be rejected.
• ACTIS_COMPATIBLE means the verified core surface (transcript, hash chain, signatures, listed checksums) is intact. It does not imply that the entire archive is safe to execute or trust beyond that surface. Verifiers MAY add a warning (e.g. in warnings) when unlisted or suspicious entries are present.

6. actis_status Decision Tree

Verification MUST derive actis_status from the following (and only the following) checks:

1. Schema/layout: Transcript conforms to schema; required fields present; bundle layout valid; manifest core files present and unique; no duplicate core path entries; no symlinks or path traversal for core paths.
2. Hash chain: All round hashes and previous_round_hash linkage valid; final_hash (if present) matches recomputation.
3. Checksums: All core files listed in manifest match checksums (if checksum file present).
4. Evidence refs: All artifacts referenced in evidence_refs arrays are present in the bundle (see §8).
5. Signatures: All rounds have valid Ed25519 signatures over the 40-byte domain-separated message (see §4).

ACTIS_COMPATIBLE: All of (1)–(5) pass.

ACTIS_PARTIAL: (1)–(4) pass; one or more signatures missing or invalid. No other failure.

ACTIS_NONCOMPLIANT: Any of (1)–(4) fail, or any failure other than signature-only.

Implementations MUST NOT use blame, reputation, risk, or settlement to determine actis_status. Only the checks above are normative.

7. References

• RFC 2119: Key words for use in RFCs
• RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
• RFC 8785: JSON Canonicalization Scheme (JCS)
• RFC 8949: Concise Binary Object Representation (CBOR) (tracked v2 encoding path)
• NIST FIPS 180-4: Secure Hash Standard (SHA-256)

8. Evidence Omission Enforcement (Normative)

If a transcript round or failure_event contains an evidence_refs array, all referenced artifacts MUST be present in the bundle for the bundle to be considered complete.

Verifiers MUST check that every entry in every evidence_refs array resolves to an artifact present in the bundle. If any referenced artifact is absent, verification MUST fail with actis_status: ACTIS_NONCOMPLIANT.

This rule closes the evidence omission attack: an attacker cannot exclude unfavorable evidence from a bundle while keeping the remaining structure intact. A bundle that is missing referenced evidence is not a complete ACTIS bundle and MUST NOT receive ACTIS_COMPATIBLE or ACTIS_PARTIAL status.

Verification order (normative):

Implementations MUST check bundle integrity in the following order and MUST fail fast at the first failure:

1. Manifest present and valid (core_files listed, no path traversal, no duplicates)
2. All core files present and checksums match
3. Transcript schema valid
4. Hash chain valid (round hashes, chain linkage, final_hash)
5. Evidence refs complete (all evidence_refs resolve to bundle artifacts)
6. Signatures valid (Ed25519 over 40-byte domain-separated message)

Reporting actis_status MUST reflect the earliest failure in this order. ACTIS_PARTIAL is reserved for signature-only failures (step 6 only). Any failure at steps 1–5 MUST yield ACTIS_NONCOMPLIANT.

Emitting ACTIS Bundles: Integration Guide

Status: Informational
Version: 1.0
Scope: Step-by-step guide for producers and verifiers (example roles) to produce and verify ACTIS-compatible evidence bundles independently.

1. What Is an ACTIS Bundle?

An ACTIS bundle is a ZIP archive containing a cryptographically verifiable record of an autonomous agent transaction. It provides a deterministic verification procedure by which any independent verifier may confirm that a specific sequence of events occurred, in a specific order, signed by specific agents, without tampering. The bundle is self-contained: everything needed to verify integrity is inside it.

2. Minimum Required Files

An ACTIS bundle MUST contain exactly three core files:

bundle.zip
├── manifest.json           # Bundle metadata and file listing
├── checksums.sha256         # SHA-256 checksums of core files
└── input/
    └── transcript.json      # Hash-linked, signed transcript

2.1 manifest.json

The manifest is normative. Schema: actis/schemas/actis_manifest_v1.json. Required: core_files (array of relative paths). Paths MUST be unique, relative, use forward slashes, and MUST NOT contain ../ or absolute/drive segments. Minimal ACTIS core: checksums.sha256, manifest.json, input/transcript.json. The checksum file lists hashes for the other core files only (not itself).

{
  "standard": { "name": "ACTIS", "version": "1.0" },
  "core_files": ["checksums.sha256", "manifest.json", "input/transcript.json"],
  "optional_files": [],
  "created_at": "2026-03-03T22:00:00Z",
  "producer": "noble.xyz"
}

2.2 checksums.sha256

A text file with one line per file, in the format <sha256-hex> <filepath>:

a1b2c3d4e5f6...64chars...  manifest.json
f6e5d4c3b2a1...64chars...  input/transcript.json

Critical: The checksum file MUST NOT include a checksum of itself. Only hash manifest.json and input/transcript.json.

2.3 Bundle security (verifiers)

Verifiers MUST reject bundles that have duplicate entries for any core path, symlinks for core paths, or path traversal (../, absolute, drive) in core paths. Unlisted files in the archive MUST NOT affect actis_status; verifiers SHOULD warn when present. ACTIS_COMPATIBLE means only the declared core surface is verified—not that the entire ZIP is safe to execute. See ACTIS_COMPATIBILITY.md §5 and ACTIS_AUDITOR_PACK.md §5.

2.4 input/transcript.json

The transcript is the core evidence artifact. See §3 for the complete field specification.

3. Transcript Schema (actis-transcript/1.0)

ACTIS v1.0 uses the transcript format identified by actis-transcript/1.0.

3.1 Required Top-Level Fields

3.2 TranscriptRound Fields

3.3 Optional Top-Level Fields

4. Critical Implementation Details

4.1 Round-0 previous_round_hash

Round 0 (the INTENT round) has no previous round. Its previous_round_hash is computed as:

genesis_input = UTF-8 encode of (intent_id + ":" + decimal(created_at_ms))
previous_round_hash = SHA-256(genesis_input)  // 64 lowercase hex

Implementations MUST treat leading/trailing whitespace in intent_id as significant and MUST NOT apply Unicode normalization. The decimal representation of created_at_ms uses no leading zeros and no JSON wrapping. See ACTIS_COMPATIBILITY.md §3.1.

Example:

import { createHash } from "node:crypto";

const intentId = "intent-noble-weather-001";
const previousRoundHash = createHash("sha256")
  .update(intentId, "utf8")
  .digest("hex");

4.2 Ed25519 Signing

Each round MUST be signed with Ed25519. The signature covers the envelope_hash:

import nacl from "tweetnacl";
import bs58 from "bs58";

// Generate a keypair (or load from your agent's identity store)
const keypair = nacl.sign.keyPair();

// The signing message is 40 bytes: utf8("ACTIS/v1") (8 bytes) || hex_decode(envelope_hash) (32 bytes).
// Do NOT sign the UTF-8 envelope_hash string. See ACTIS_COMPATIBILITY.md §2.3 and §4.
const envelopeHash = "144090ff43d039c1ea7cae50824a1bc1376ca97f7fc326dfa8021315af47e077";
const message = new TextEncoder().encode(envelopeHash);

// Sign
const signatureBytes = nacl.sign.detached(message, keypair.secretKey);

// Encode for transcript
const signature = {
  signer_public_key_b58: bs58.encode(keypair.publicKey),
  signature_b58: bs58.encode(signatureBytes),
  signed_at_ms: Date.now(),
  scheme: "ed25519"
};

4.3 Hash Chain Verification

For each round n > 0:

round[n].previous_round_hash === SHA-256( canonical_json( round[n-1] ) )

Where canonical_json means JSON.stringify with sorted keys and no whitespace (RFC 8785 JCS or equivalent deterministic serialization). The round_hash field itself MUST be excluded from the canonical form before hashing.

4.4 Computing final_hash

After the last round is appended:

final_hash = SHA-256( canonical_json( transcript_without_final_hash ) )

The final_hash field is excluded from the canonical form.

4.5 Generating checksums.sha256

sha256sum manifest.json input/transcript.json > checksums.sha256

Or programmatically:

import { createHash, readFileSync } from "node:fs";

function sha256File(path) {
  const content = readFileSync(path);
  return createHash("sha256").update(content).digest("hex");
}

const lines = [
  `${sha256File("manifest.json")}  manifest.json`,
  `${sha256File("input/transcript.json")}  input/transcript.json`,
].join("\n") + "\n";

writeFileSync("checksums.sha256", lines);

Do not include checksums.sha256 in the checksum list.

5. Complete Example: 2-Round Transcript (INTENT + ACCEPT)

{
  "transcript_version": "actis-transcript/1.0",
  "transcript_id": "transcript-b7e23f8a91c04d5e6f78901234abcdef0123456789abcdef0123456789abcdef",
  "intent_id": "intent-noble-weather-20260303-001",
  "intent_type": "weather.data",
  "created_at_ms": 1709500000000,
  "policy_hash": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2",
  "strategy_hash": "b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3",
  "identity_snapshot_hash": "c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4",
  "rounds": [
    {
      "round_number": 0,
      "round_type": "INTENT",
      "message_hash": "d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5",
      "envelope_hash": "d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5",
      "signature": {
        "signer_public_key_b58": "21wxunPRWgrzXqK48yeE1aEZtfpFU2AwY8odDiGgBT4J",
        "signature_b58": "128SdR5tqs76YAyF2cxD5f2pRbmYZaTNrcA8LJugU6kTwJrJNaA3pALAS3mPwVMsL1yTbxBKtk2B4ZVSxaUmz6ca",
        "signed_at_ms": 1709500000000,
        "scheme": "ed25519"
      },
      "timestamp_ms": 1709500000000,
      "previous_round_hash": "SHA256('intent-noble-weather-20260303-001:' + decimal(created_at_ms))",
      "agent_id": "buyer",
      "public_key_b58": "21wxunPRWgrzXqK48yeE1aEZtfpFU2AwY8odDiGgBT4J",
      "content_summary": {
        "intent_type": "weather.data",
        "description": "Request current weather data for NYC"
      },
      "round_hash": "e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6"
    },
    {
      "round_number": 1,
      "round_type": "ACCEPT",
      "message_hash": "f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7",
      "envelope_hash": "f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7",
      "signature": {
        "signer_public_key_b58": "HBUkwmmQVFX3mGF6ris1mWDATY27nAupX6wQNXgJD9j9",
        "signature_b58": "3LwhuzhEt4FdM117RKYfQ5kJbPerSrH86SoiM226PDoQHyXhEN8MbNDJPJkiQAVGoEqUgYD3dDANNbmcZ4T6Fitx",
        "signed_at_ms": 1709500001000,
        "scheme": "ed25519"
      },
      "timestamp_ms": 1709500001000,
      "previous_round_hash": "e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6",
      "agent_id": "seller",
      "public_key_b58": "HBUkwmmQVFX3mGF6ris1mWDATY27nAupX6wQNXgJD9j9",
      "content_summary": {
        "price": 0.00005,
        "accepted": true
      },
      "round_hash": "a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8"
    }
  ],
  "final_hash": "b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9"
}

Note: The hashes and signatures in this example are illustrative placeholders showing the correct format and structure. In a real implementation, all hashes MUST be computed from actual content, and all signatures MUST be cryptographically valid Ed25519 signatures.

6. Submitting to a verifier (example)

ACTIS defines no network API; the following is an example only. A verifier service might accept a bundle and return a verification report.

curl -X POST https://verifier.example/v1/verify \
  -H "Content-Type: application/zip" \
  -H "Authorization: Bearer <your-api-key>" \
  --data-binary @bundle.zip

Example successful response (HTTP 200):

{
  "bundle_id": "bundle-abc123def456...",
  "actis_status": "ACTIS_COMPATIBLE",
  "actis_version": "1.0",
  "verified_at": "2026-03-03T22:00:00Z",
  "verifier_version": "0.9.0",
  "report_content_hash": "sha256-of-full-report..."
}

Status values:

7. Troubleshooting: Five Most Common Failures

7.1 Wrong transcript_version Constant

Symptom: schema_ok: false, ACTIS_NONCOMPLIANT.

Cause: transcript_version is not the required value. ACTIS bundles MUST use "actis-transcript/1.0". Common mistakes: using "4.0", "actis/1.0", or any other variant.

Fix: Set transcript_version to the exact string "actis-transcript/1.0".

7.2 Round-0 previous_round_hash Format

Symptom: hash_chain_ok: false, hash chain broken at round 0.

Cause: previous_round_hash for round 0 was computed incorrectly. Common mistakes:

• Hashing intent_id as an object instead of a plain string
• Using a different encoding (e.g., Latin-1 instead of UTF-8)
• Including surrounding quotes in the hash input

Fix: Compute SHA-256( intent_id ) where intent_id is the raw string value encoded as UTF-8 bytes. No JSON wrapping, no quotes.

7.3 Checksum File Self-Reference

Symptom: checksums_ok: false, checksum mismatch.

Cause: checksums.sha256 includes a hash of itself, creating a circular reference that always fails.

Fix: Hash only manifest.json and input/transcript.json. Do not include checksums.sha256 in its own content.

7.4 Missing Required Fields

Symptom: schema_ok: false or parse error.

Cause: A required field is missing from the transcript or round objects. The most commonly missed fields are:

• identity_snapshot_hash (top-level)
• previous_round_hash (in rounds)
• envelope_hash (in rounds — sometimes confused with message_hash)

Fix: Ensure all fields marked "Required" in §3.1 and §3.2 are present and non-null.

7.5 Signature Scheme Mismatch

Symptom: signatures_ok: false, signature verification fails.

Cause: The signature was created using a different scheme (e.g., secp256k1, RSA) but scheme is set to "ed25519", or the signature was created over different data than envelope_hash.

Fix: ACTIS v1.0 supports Ed25519 only. The signature MUST be an Ed25519 detached signature over the 40-byte message: utf8("ACTIS/v1") || hex_decode(envelope_hash). Do NOT sign the UTF-8 hex string directly. Verify that signer_public_key_b58 matches the key that created the signature.

8. Quick Start Checklist

• Generate an Ed25519 keypair for your agent
• Create a transcript with transcript_version: "actis-transcript/1.0"
• Compute round-0 previous_round_hash as SHA-256(utf8(intent_id + ":" + decimal(created_at_ms)))
• Sign each round with Ed25519 over the 40-byte message: utf8("ACTIS/v1") || hex_decode(envelope_hash)
• Compute each round's round_hash (canonical JSON, sorted keys, excluding round_hash)
• Set each subsequent round's previous_round_hash to the prior round's round_hash
• Compute final_hash (canonical JSON of entire transcript, excluding final_hash)
• Create manifest.json with standard.name: "ACTIS" and standard.version: "1.0"
• Generate checksums.sha256 (exclude the checksum file itself)
• Package as ZIP and submit to your verifier (e.g. POST /v1/verify)
  • Verify response: actis_status: "ACTIS_COMPATIBLE"

9. Next steps for implementers

• Produce real transaction transcripts (e.g. successful procurement, policy-driven rejection, terminal failure) with the structure above.
• Anonymize sensitive data while preserving hash chain and signature validity.
• Run the ACTIS conformance harness to validate your verifier. The harness exists in the ACTIS repository at actis/test-vectors/run_conformance.sh. If you are reading a vendored copy of ACTIS, ensure you have included the actis/test-vectors/ directory (including expected_results.json and the generated/ zip files). If you do not have the harness, you can still validate by running your verifier on each of tv-001..tv-008 and comparing the JSON output to the expected values in expected_results.json.

10. Transparency Log Anchoring (Informative)

ACTIS bundles are self-evidencing and offline-verifiable by design. A bundle that passes ACTIS verification is cryptographically intact without any external dependency. Transparency log anchoring is an optional layer that can be added on top of ACTIS verification to provide additional guarantees.

10.1 Why anchor?

Anchoring a bundle's final_hash to an append-only transparency log provides:

• Timestamping — Proof that a bundle existed at or before a given time, independent of the bundle producer.
• Public tamper resistance — Any attempt to retroactively alter a committed bundle hash is detectable by any log observer.
• Equivocation detection — A log that enforces unique transcript_id commitments can detect whether two different bundles have been produced for the same transaction. See ACTIS_STANDARD_v1.md §7.2 for the equivocation threat model.

10.2 How to anchor

ACTIS does not mandate any specific transparency log. Producers MAY anchor bundles by committing the final_hash (and optionally the transcript_id) to any append-only log that provides inclusion proofs. Examples include:

• RFC 6962 / RFC 9162 Certificate Transparency logs
• Rekor (Sigstore)
• Any organizational or consortium append-only ledger

The anchor commitment and inclusion proof SHOULD be stored as optional files in the bundle (e.g. optional/tlog_inclusion_proof.json) and listed in optional_files in the manifest. They MUST NOT be listed in core_files and MUST NOT affect actis_status.

10.3 The external_anchors manifest field

The manifest schema reserves the external_anchors field for future use. When present, it is an array of objects describing transparency log commitments for this bundle. This field is optional and carries no normative weight in ACTIS v1.0; verifiers MUST ignore it for the purposes of determining actis_status.

"external_anchors": [
  {
    "log": "rekor.sigstore.dev",
    "entry_id": "<log entry UUID or hash>",
    "committed_at": "<ISO 8601 timestamp>",
    "inclusion_proof_path": "optional/tlog_inclusion_proof.json"
  }
]

Questions? File an issue in the ACTIS repository.