Business Records That Cross Every Boundary

Verify your Workflows with IOTA Audit Trails

TL;DR:
Business records fragmented across databases and spreadsheets can be altered, backfilled, or disputed. IOTA Audit Trails anchors governed, ordered histories onchain so every record (and the authority behind it) can be independently verified. Available now as an alpha release with a Move package, Rust SDK, and WebAssembly bindings.

Every business process leaves a trail. A product moves through suppliers, a clinical trial collects study events, a customs workflow gathers approvals, and a compliance team reviews the evidence behind a decision. These records often live across fragmented databases, spreadsheets, internal logs, and manual reports.

That fragmentation creates a trust problem. Records can be altered, deleted, backfilled, or interpreted differently across systems. Access controls are usually local to one application, and external parties often have to trust exported reports instead of verifying the underlying history themselves.

IOTA Audit Trails, a new open-source solution from the IOTA Notarization toolkit, brings these histories onto a shared, tamper-resistant ledger layer. It doesn’t replace private business systems or require organizations to expose sensitive documents on-chain. Instead, it provides a structured way to anchor the events, hashes, metadata, and operational proofs that need to be verifiable across organizational boundaries.

With IOTA Audit Trails, organizations gain a transparent way to record who did what, when, and under which permissions. Developers can integrate it through Move smart contracts, a Rust SDK, or WebAssembly bindings for JavaScript and TypeScript applications.

When Trust Doesn't Travel: Why Audit Trails Matter

Many audit systems are designed for internal visibility. They help teams investigate incidents and satisfy reporting obligations, but they rely on a central administrator, a single database, or a trusted export. That model breaks down the moment a workflow crosses organizational boundaries.

What if a regulator, partner, insurer, customer, or downstream system needs to verify that a record was added at the right time, by the right actor, with the right authority?

IOTA Audit Trails makes that verification explicit. Roles define which actions are allowed, capabilities delegate those roles to wallets or services, and records are written to an ordered onchain history. Verifiers can inspect the trail state and record sequence directly through read-only clients without needing write permissions.

What Goes Onchain… and What Shouldn't: Data Visibility and Privacy

IOTA Audit Trails runs on the IOTA public ledger, so teams should treat onchain data as publicly readable. For sensitive documents, personal data, proprietary reports, or medical records, applications should store the original content off-chain and write only hashes, references, or non-sensitive metadata to the trail.

This approach gives organizations a verifiable record of existence, order, and integrity without exposing confidential source material. Public ledgers provide integrity and availability; application design must still handle privacy, encryption, and access to the underlying off-chain data.

From Individual Proofs to Governed Histories

IOTA Notarization already allows developers to anchor individual records on the IOTA ledger. Audit Trails extends that foundation from a single notarized object to an ordered record history with in-built governance.

An audit trail is a shared onchain object that stores records in sequence. Each record can contain text or binary data, optional metadata, and an optional tag. The trail also stores immutable creation metadata, updatable operational metadata, locking configuration, roles, capabilities, and tag rules.

This makes Audit Trails useful when the question isn’t only "has this data changed?" but also "who added this record, under which role, in what order, and under which lifecycle rules?"

Who Can Do What, and When

IOTA Audit Trails is designed for environments where different actors have different responsibilities. A product manufacturer may write lifecycle events, an auditor may inspect records, a compliance officer may manage retention rules, and a system operator may manage tags or metadata.

The solution supports this separation through role-based access control:

• Roles define named permission sets for actions, such as adding records, deleting records, managing tags, updating metadata, configuring locks, issuing capabilities, or deleting the trail.
• Capabilities are owned on-chain objects that grant a role for a specific audit trail. They can be restricted to a specific address or validity window.
• Record tags organize records by category and can limit which roles may write to which parts of the trail.
• Locking rules control when records can be written, when records can be deleted, and when the trail itself can be removed.

Together, these controls let teams model practical governance without building a custom smart contract for every audit workflow.

A Trail From First Record to Final Lock: How It Works 

Developers can create and manage audit trails through the Rust SDK, WebAssembly bindings, or the Move package directly.

A typical flow looks like this:

1. Create an audit trail: An administrator creates a trail with optional immutable metadata, mutable status metadata, initial records, and tag registry (the trail-owned list of tags that records may use. Tags help organize records and restrict writes by role), and locking configuration (rules that control write access, record deletion windows, and trail deletion).
2. Receive Admin capability: The creator receives an Admin capability object that authorizes trail administration. The Admin capability gives the creator administrative authority over the trail.
3. Define roles: The administrator creates roles (a named permission set stored in the trail that defines what a capability holder can do) such as RecordAdmin, LockingAdmin, TagAdmin, or custom roles with specific permission sets.
4. Issue capabilities: The administrator delegates roles by issuing capability objects to users, services, or operational wallets. A capability is an owned object that grants one role for one audit trail. Capabilities can be bound to an address or limited by time.
5. Add records: Authorized actors append records to the trail. A record is a single entry in the trail, stored at a sequence number with data, optional metadata, and an optional tag.Tagged records must use tags registered on the trail and allowed for the writer's role.
6. Read and verify: Verifiers inspect metadata, roles, locking state, record counts, and paginated records through read-only APIs.
7. Lock or retire the trail: Teams can enforce write locks, record deletion windows, or trail deletion locks according to policy.

This process gives developers a reusable pattern for creating append-oriented histories with explicit authority and lifecycle controls.

Developer Tooling

IOTA Audit Trails ships as part of the IOTA Notarization toolkit with three integration paths: a Move package for on-chain contract logic, a typed Rust SDK for backend integrations, and WebAssembly bindings for JavaScript and TypeScript applications. The repository also includes ready-to-run examples covering customs clearance, clinical trials, and digital product passports. Transaction construction is kept separate from submission, so you can plug Audit Trails into your own wallet, signing, or gas station flow.

Where Shared Verification Changes Everything

IOTA Audit Trails is general-purpose and can support any workflow that needs a verifiable, ordered history. It is particularly well-suited to industries where records cross organizational boundaries, carry regulatory weight, or need to be verified by parties outside the system that created them. 

In supply chains and digital product passports, manufacturers can record lifecycle events, maintenance updates, inspections and certifications that follow a component from production to end use. Legal and compliance teams can build verifiable histories for approvals, filings, contracts, and regulated operational records. Customs and trade workflows benefit from coordinated clearance steps, inspections, declarations, and role-scoped updates across several parties. IoT and automation systems can use the trail to record machine events, sensor attestations, maintenance actions, or system state changes with clear provenance.

In all of these cases, the value-add of IOTA Audit Trails comes from shared verification. Each participant can rely on the same ordered history instead of reconciling separate logs after the fact.

Get Started with Audit Trails

Explore these resources to begin using IOTA Audit Trails:

• IOTA Notarization product page: Learn how Notarization anchors, updates, and verifies data onchain.
• IOTA Notarization GitHub repository: Access the open-source IOTA Notarization Toolkit and contribute to development.
• Audit Trails Rust SDK: Build typed Rust integrations for creating and managing audit trails.
• Audit Trails Wasm SDK: Add audit trail flows to JavaScript and TypeScript applications.
• Audit Trails examples: Run basic, advanced, and real-world examples for role delegation, tagged records, locking, customs clearance, clinical trials, and digital product passports.
• Audit Trails on IOTA Docs: Follow setup guides and learn how Audit Trails fits into the broader IOTA Notarization toolkit.
• #notarization-dev on Discord: Share your progress or questions and get feedback from the IOTA builder community.
• Audit Trails webpage on the IOTA website

IOTA Audit Trails is available now for teams that want to experiment, validate their architecture, and share feedback with the IOTA builder community. Deploy on the IOTA Testnet or Mainnet when you are ready to move from experimentation to production.

Audit logs are only as trustworthy as the system behind them. When that system is a single database or a central administrator, trust doesn't travel well across organizational boundaries. IOTA Audit Trails changes that by turning record histories into shared, verifiable objects that any authorized party can inspect, regardless of where they sit in the workflow.

Run the examples, model your first trail, and verify your own records, roles, and governance rules. We're excited to see what you build.