> ## Documentation Index > Fetch the complete documentation index at: https://docs.walletsuite.io/llms.txt > Use this file to discover all available pages before exploring further. # Audit Trail > A WalletSuite-operated, hash-chained record of every signing decision and operation — tamper-evident and exportable to your SIEM. WalletSuite operates the audit trail. You run nothing and store nothing — every signing decision and every sign/broadcast operation is recorded on the platform as it happens, and you can export the record to your own systems. It has two complementary layers: the **platform decision records** that capture what the policy engine authorized (including every denial), and the **hash-chained signing-layer receipts** that record what was actually signed and broadcast. See also [Security Overview → Audit Trail](/security/overview#7-audit-trail--signing-layer). ## Platform decision records The primary artifact. Every signing intent that reaches WalletSuite is evaluated before any signature is produced, and each evaluation writes a durable decision record to the signing-intents ledger — allowed and denied intents alike. This is what a compliance or treasury reviewer asks for: not just what your agents signed, but every request the policy stopped and the exact rule that stopped it. Each record carries: | Field | What it records | | ------------------ | --------------------------------------------------------------------------------------------------------- | | `policyDecisionId` | Fresh identifier for this one evaluation; ties the decision to the receipt and to any resulting signature | | `decision` | `allow` or `deny` | | `reason` | Stable reason string for the outcome | | `matchedRuleId` | The allowlist rule that admitted the operation, when one did | Denials are first-class rows, not dropped requests. The stable deny reasons include `chain_not_entitled`, `no_matching_rule`, and `unclassified_operation`. See [Policy Decisions](/core-concepts/policy-decisions) for the full field and reason contract. ## Signing-layer receipts Every `sign_transaction` and `send_transaction` operation also produces a receipt in a hash-chained log, recording what was signed and the outcome: | Field | Description | | ------------------------ | ---------------------------------------------------------------------------------------------- | | `receiptId` | Unique receipt identifier | | `timestamp` | ISO 8601 timestamp | | `operation` | `sign_transaction` or `send_transaction` | | `chain` | Chain id (e.g., `eip155:1`, `tron:mainnet`) | | `txDigest` | Truncated transaction hex (first 8 + last 8 chars) | | `txHash` | On-chain transaction hash, when broadcast succeeded | | `policyDecisionId` | The decision record that authorized this operation | | `counterpartyCheck` | Counterparty screening result: `not_performed`, `performed` (`clear` / `flagged`), or `failed` | | `outcome` | `success` or `error`, with `errorCode` / `errorMessage` on error | | `contentHash` | SHA-256 of the receipt content | | `prevHash` / `entryHash` | The hash-chain links (see below) | The receipt references the decision that authorized it by `policyDecisionId`, so a signed operation is always traceable back to the exact policy evaluation that admitted it. ## Hash chain Each receipt carries a `contentHash` (SHA-256 of the receipt data) and an `entryHash` that links it to the previous receipt. The first receipt's `entryHash` is the SHA-256 of its `contentHash`; every later receipt's `entryHash` is SHA-256 of `prevHash + ":" + contentHash` — `prevHash` first, a literal `:` separator, then the current receipt's `contentHash`. ``` Receipt 1: contentHash = SHA-256(receipt_1_data) entryHash = SHA-256(contentHash) Receipt 2: contentHash = SHA-256(receipt_2_data) entryHash = SHA-256(receipt_1.entryHash + ":" + contentHash) Receipt 3: contentHash = SHA-256(receipt_3_data) entryHash = SHA-256(receipt_2.entryHash + ":" + contentHash) ``` This makes the record **tamper-evident**: altering any receipt breaks the chain link of every receipt after it, so any modification is detectable by walking the chain and recomputing each `entryHash`. Export the record to your own SIEM (below) to hold an independent copy. ## Secret redaction Credentials, bearer tokens, mnemonics, and private-key material are redacted before any receipt is written, and transaction hex is truncated to first 8 + last 8 characters so serialized payloads cannot leak key material. ## Export The record is exportable as structured JSON. Forward it to your SIEM or log-aggregation pipeline for long-term retention, alerting, and correlation with the rest of your security telemetry. The format works with any pipeline that ingests JSON. ## Non-custodial by design Every operation in the audit trail is a threshold co-signing event: no full private key ever exists, and no signature is produced without a passing policy decision. The audit trail is the durable proof of that — every authorization, every denial, and every signature, recorded as it happens. See [Key Management](/security/key-management). ## Related * [Policy Decisions](/core-concepts/policy-decisions) — the decision record on every signing intent * [Key Management](/security/key-management) — non-custodial MPC signing * [Security Overview](/security/overview) — the full trust model * [Production Checklist](/production-checklist) — go-live checklist