InvoanceInvoance
Log inGet access
Traces

Group events into a sealed, verifiable proof of an entire process.

A Trace groups independently anchored events into a single auditable sequence. When the process is complete, seal the trace — permanently. The result is a composite cryptographic proof that covers every event from start to seal. Exportable as JSON or PDF. Verifiable by anyone.

Full event content included — not just hashes. Auditors read the process. Engineers verify the math.

Start for freeView API docs

Traces are free to create — events within them count against your existing quota.

What a Trace is

A Trace is a named, ordered grouping of anchored events under a single identifier, representing a complete business process from start to seal. It is not a workflow engine. It does not enforce steps, approvals, or sequencing. It groups independently verifiable events into one auditable unit and produces a single exportable proof artifact when sealed.

Named grouping

A human-readable label and optional metadata tie together any number of events into one logical process.

Ordered sequence

Events within a trace are ordered by ingestion timestamp. The sequence is preserved in the proof bundle and composite hash.

Permanently sealable

Once sealed, a trace cannot be reopened, modified, or deleted. The seal is itself a cryptographically signed event.

Composite hash

SHA-256 computed over the ordered concatenation of all event hashes. One hash proves the entire sequence is intact.

Exportable proof bundle

JSON for programmatic verification. PDF for auditors, lawyers, and executives. Both contain the full cryptographic proof.

Publicly verifiable (when enabled)

Sealed traces are private by default. Enable public access in the dashboard to allow anyone to verify without authentication. Recompute the composite hash from individual events and verify the seal signature.

No expiration

Open traces stay open indefinitely. There is no timeout, no auto-seal, no forced closure. Your application seals when the process is complete — on your timeline, not ours.

Trace lifecycle

Four steps. No branching, no conditions, no approvals. Your application decides what events to anchor, in what order, and when to seal. Invoance groups, hashes, signs, and exports. That is the entire scope.

1
Create

Open a trace

Name the process. Attach optional metadata. The trace begins accepting events.

2
Anchor

Add events

Anchor events to the trace via trace_id. Each event is independently hashed and signed.

3
Seal

Close permanently

Compute the composite hash. Sign the seal event. The trace is permanently closed.

4
Export

Proof bundle

Export the complete proof artifact. JSON for machines. PDF for humans. Verifiable by anyone.

CREATE → ANCHOR EVENTS → SEAL → EXPORT PROOF BUNDLE

Open trace — events accumulating

After creating a trace, Invoance returns a server-generated trace_id. Your application stores it and includes it when anchoring events via the existing event API. Each event is independently hashed, signed, and timestamped. The trace is a grouping reference — your app controls which events belong to it.

Vendor Onboarding — Acme Corp
OPEN
vendor.created
a3f2b1c9d4...
12:00:00Z
document.anchored
c7d4e9a1b2...
12:05:00Z
approval.recorded
f8a1c3d2e5...
13:00:00Z
compliance.checked
b2c7d8e3f4...
13:45:00Z
payment.authorized
d9e2f1a4b5...
14:15:00Z
Awaiting more events...

Sealed trace — permanently closed

When you seal a trace, Invoance fetches all events in order, computes the composite hash over their hashes, creates a signed seal event, and permanently closes the trace. No more events can be appended. The seal event is the cryptographic commitment to the full sequence.

Vendor Onboarding — Acme Corp
SEALED
vendor.created
12:00:00Z
document.anchored
12:05:00Z
approval.recorded
13:00:00Z
compliance.checked
13:45:00Z
payment.authorized
14:15:00Z
trace.sealed
14:30:00Z
composite_hash: sha256:def456...5 events + seal

The composite hash is SHA-256 computed over the ordered concatenation of all individual event hashes. Any missing, reordered, or altered event invalidates the composite hash.

Proof bundle — the exportable artifact

A sealed trace produces a proof bundle — a self-contained artifact that reads top to bottom like a chronological record. The trace header, then each event in order with its full readable payload and cryptographic proof underneath, then the seal with composite hash and verification. An auditor reads the content. An engineer verifies the math. Both use the same document.

Invoance persists the full event payload alongside the content hash. The proof bundle includes the exact data the client sent — not just hashes. This means the bundle is independently verifiable without requesting the original data from anyone.

JSON proof bundle

Machine-readable. Each event includes its full payload, content hash, signature, and public key. The composite hash and seal signature close the bundle. Feed it into automated compliance pipelines or verify programmatically.

PDF proof bundle

For auditors, lawyers, and executives. Readable payloads front and center, cryptographic proof in monospace underneath. Horizontal dividers between events. QR code to the public verification URL. Black and white. Certificate, not a report.

Proof bundle previewv1.0
Trace header
Vendor Onboarding — Acme Corp
Tenantacme.com
Domain verifiedYes
Trace IDtr_abc123...
Event count5
Created2026-03-17T12:00:00Z
Sealed2026-03-17T14:30:00Z
Composite hashsha256:def456...a3b1c9d4
1 of 52026-03-17T12:00:00Z
vendor.created
Payload
vendor_nameAcme Corp
initiated_byj.smith@tenant.com
departmentprocurement
Content hashsha256:a3f2b1c9...d4e7f8a2
Signatureed25519:7b1c...a4f9
Public keyed25519_pk:9c2d...b8e1
Signature valid
2 of 52026-03-17T12:05:00Z
document.anchored
Payload
document_refcontract_v2.pdf
signed_bylegal@acme.com
pages12
Content hashsha256:c7d4e9a1...b2f3c8d5
Signatureed25519:3d9f...c82e
Public keyed25519_pk:9c2d...b8e1
Signature valid
3 of 52026-03-17T13:00:00Z
approval.recorded
Payload
approved_bym.chen@tenant.com
rolecompliance_officer
decisionapproved
Content hashsha256:f8a1c3d2...e5b7d9f1
Signatureed25519:a2c4...d7f3
Public keyed25519_pk:9c2d...b8e1
Signature valid
+ 2 more events (4 of 5, 5 of 5) — same structure
Seal
Sealed at2026-03-17T14:30:00Z
Composite hashsha256:def456...a3b1c9d4
Seal signatureed25519:e8f2...b4a1
Event count5 confirmed
Composite hash recomputed and matched
All 5 signatures valid
Verify at invoance.com/proof/trace/tr_abc123...QR

What businesses trace

Any multi-step business process where the complete sequence matters — not just individual events. These are real categories of processes that become provable with traces.

Vendor onboarding

Application received → documents collected → compliance checked → approval recorded → payment authorized → vendor active

Loan origination

Application submitted → credit check → income verified → underwriting decision → terms accepted → funds disbursed

Incident response

Incident detected → team notified → investigation started → root cause identified → remediation applied → post-mortem published

Audit preparation

Scope defined → evidence gathered → controls tested → findings documented → remediation tracked → report finalized

What Trace is not

Trace is a proof layer, not a workflow engine. It does not manage your process — it proves what happened during it. This distinction is architectural, not a limitation.

No step definitions

Invoance does not define what steps a process must contain. Your application decides what to anchor.

No ordering enforcement

Events are ordered by timestamp, but Invoance does not reject based on sequence or missing steps.

No approval workflows

No conditional logic, no gates, no role assignments. The trace records — it does not orchestrate.

No status beyond open/sealed

No 'in progress,' 'pending review,' or 'approved.' A trace is open or sealed. That's it.

No re-opening

Sealed traces cannot be reopened under any circumstance. This is a structural guarantee, not a policy.

No branching or forking

One trace, one linear sequence, one seal. If your process branches, use multiple traces.

No expiration or auto-seal

Open traces stay open indefinitely. Invoance never forces a seal. Your application decides when the process is complete.

No retroactive modification

Once an event is anchored to a trace, it cannot be removed, replaced, or reordered. The sequence is permanent from the moment of ingestion.

Create, manage, and seal traces

Create traces and anchor events via API or from the dashboard. Create a trace — Invoance returns the trace_id. Anchor events using that ID. Seal when done. The proof bundle generates itself from the cryptographic evidence already recorded. Below is an example using the API.

1
Create the trace

Invoance generates the trace_id. Store it in your system.

POST /v1/traces
{
  "label": "Vendor Onboarding — Acme",
  "metadata": {
    "department": "procurement",
    "initiated_by": "j.smith@acme.com"
  }
}

// Invoance returns:
→ trace_id: "tr_abc123..."  ← server-generated
→ status: "open"
2
Anchor events

Reference the server-issued trace_id from step 1.

POST /v1/events
{
  "event_type": "document.anchored",
  "trace_id": "tr_abc123...",  ← from step 1
  "payload": {
    "document_ref": "contract_v2.pdf",
    "signed_by": "legal@acme.com"
  }
}

→ event_id: "evt_001..."
3
Seal the trace

Permanently close. Composite hash computed automatically.

POST /v1/traces/tr_abc123.../seal

→ status: "sealed"
→ composite_hash: "sha256:def456..."
→ event_count: 7
→ seal_event_id: "evt_xyz789..."

When process proof matters

Individual event proofs answer "did this happen?" A trace answers "here is everything that happened during this entire process, in order, cryptographically proven."

Dispute resolution

A vendor claims the onboarding process was incomplete or steps were skipped.

You manually reconstruct the timeline from scattered logs across multiple systems.
Export the sealed proof bundle. Every step is hashed, signed, and ordered. The composite hash proves the complete sequence.
Regulatory audit

A regulator asks you to prove your loan origination process followed required procedures.

Weeks assembling evidence. Admissibility questioned because records are editable.
One proof bundle per loan. Sealed and verifiable. Each step independently signed. The sequence is cryptographically proven.
Audit preparation

An auditor asks you to prove that every control was tested and every finding was documented before the report was finalized.

Spreadsheets, shared drives, and email threads. No guaranteed ordering, no proof of completeness.
One sealed trace per audit cycle. Every step — scoping, evidence gathering, testing, remediation — anchored in sequence and cryptographically proven.
Post-incident review

After a security incident, you need to prove exactly what response actions were taken and when.

Ticketing system logs — editable, no cryptographic proof, no guaranteed ordering.
Every response action anchored in sequence. Sealed when the incident is closed. Tamper-evident by design.

Technical guarantees

These are structural properties of how traces work — not policy commitments. They hold regardless of plan, tenant, or circumstance.

Composite integrity

The composite hash is SHA-256 over the ordered concatenation of all event hashes. Any missing, added, reordered, or altered event invalidates it.

Seal immutability

The seal event is itself hashed, signed with Ed25519, and appended to the ledger. It cannot be forged, backdated, or reversed.

Individual event proof

Every event in a trace retains its own independent hash, signature, and verification URL. Trace membership does not weaken individual proof.

Append-only guarantee

No UPDATE or DELETE on traces or events. The seal transition (open → sealed) is the only mutation, and it is irreversible.

Offline verification

The proof bundle contains everything needed to verify the entire trace — public keys, signatures, hashes — without contacting Invoance.

No vendor lock-in

Export the proof bundle. Verify it yourself. The cryptography is standard Ed25519 + SHA-256. No proprietary formats.

No extra cost. Traces are a grouping mechanism.

Traces themselves are free to create. Each event anchored to a trace counts against your existing event quota — already billed. No new pricing tier, no add-on fees, no per-trace charges.

All plans include traces. See full pricing

Make your business processes provable

If a process matters enough to track, it matters enough to prove. Group events. Seal the trace. Export the proof. That's it.

Start for freeAPI referenceEvent Ledger

Traces — Verifiable Process Proof

Group events into a sealed, verifiable proof of an entire process. A Trace groups independently anchored events into a single auditable sequence. When the process is complete, seal the trace permanently. The result is a composite cryptographic proof that covers every event from start to seal. Exportable as JSON or PDF. Verifiable by anyone.

Invoance

Neutral digital proof infrastructure for business. Tamper-evident, independently verifiable records.

Subscribe to our newsletter

Products
Platform
How It Works
Developers
Verify
Resources
Help & Legal
Products
  • Event Ledger
  • Document Anchoring
  • AI Attestation
  • Traces
Platform
  • Why Invoance
  • For Compliance Teams
  • Pricing
  • Security
How It Works
  • Overview
  • Event Ledger
  • Document Anchoring
  • AI Attestation
Developers
  • Overview
  • Endpoints
  • Authentication
  • Concepts
Verify
  • Verify Document
  • Verify AI Attestation
  • Verify Event
  • Verify Trace
Resources
  • All Resources
  • SOC 2 Guide
  • HIPAA Guide
  • ISO 27001 Guide
Help & Legal
  • Support
  • Verification Help
  • FAQ
  • Legal Notice

Invoance provides technical verification and proof infrastructure for digital records. Invoance does not issue legal, financial, or regulatory advice.

Records anchored through Invoance are cryptographically signed and tamper-evident by design. Invoance does not verify the accuracy, legality, or authenticity of document contents — only that a record existed in a specific form at a specific time. Verification links are publicly resolvable and do not require authentication. Invoance does not act as a custodian of funds, a legal authority, or a regulated financial entity. Use of Invoance does not constitute legal compliance. Consult qualified counsel for your specific obligations.

© 2025 – 2026 Invoance. All rights reserved.•