Review who acted on what in the DALP Console

Audit trail lists your organisation's operations, such as publishing an obligation, approving a submission, or opening a participant's KYC record, with who performed each one, their role at the time and its outcome. A publish or an approval changes something. Opening a KYC record changes nothing but is still recorded, because the platform records some reads on their own as sensitive reads. Use this screen to confirm that an operation happened, who performed it and whether it succeeded.

An entry also shows the old and new values a change recorded, such as a venue announcement's text before and after an edit. An amount, such as a supply cap, shows in the asset's units with its symbol and digit grouping, for example 1,500 ACP. An amount recorded without its asset's decimals shows in smallest units and says so, for example 150,000 (smallest units). For a maker-checker approval it shows who proposed it and who approved or rejected it. The Console does not show request bodies. Each entry is linked to the previous one by a hash chain, and its final outcome is linked when the request closes. The audit trail concept page explains how to check that chain and what the check cannot detect.

The trail is read-only, opens on the last 30 days and lists operations. It holds no ledger activity, so open the affected asset's page for on-chain activity. Reading the trail is itself a sensitive read, so it adds an entry that names you as the actor.

Audit trail entries in a table with the Operation, When, Operator, Checker and Outcome columns — The audit trail table with the “Operation”, “When”, “Operator”, “Checker” and “Outcome” columns.

Each entry names the action in words, such as “View KYC profile”, and reads “Success” under “Outcome” when it succeeded. An opened entry shows the target and the reason where present.

Steps

Open Audit trail

Open “Reporting”, then Audit trail. The “Actions” tab lists recorded operations from the previous 30 days, newest first, 200 entries to a page. The columns are “Operation”, “When”, “Operator”, “Checker”, “Outcome”, “Target” and “Reason”. A caption under the table gives the range the page shows, for example “Showing 201 to 400, newest first”. An entry names the action in words, in the language the Console is set to, and shows the time the operation started.

The window ends when you open the page, so entries recorded after that, including your own reads of the trail, do not shift the pages. The tooltip on the window button gives that time. To include newer entries, apply the window again or reopen the page.

Narrow the list

Use the toolbar above the table:

Search resources matches the entry's target.
Action limits the list to one operation. It reads “All actions” until you choose one.
Channel limits the list to “Admin” entries for an operator, “Participant” for an investor or trader, or “System” for a scheduled job or a request with no signed-in session. It reads “All channels” until you choose one. An action that an assistant agent ran has the Agent channel, which its entry sheet shows. The “Channel” select does not offer it, so filter those entries through the API with actorChannel=agent.
Entry type reads “All entries”, “Writes” or “Sensitive reads”. “Writes” shows the operations that changed something. “Sensitive reads” shows the reads the platform records on their own.
The window button, which reads like “27 Sep - 27 Oct 2026”, opens “From” and “To” dates with Apply. “Last 30 days” restores the default. An empty “From” gives the 30 days that end on “To”. An empty “To” ends the window at the time you open the page, apply the window or change a filter. “From” and “To” refuse a “From” after the “To” or a typed day that does not exist, such as 2026-02-30, and show a message under that field. “Apply” stays unavailable until you correct or clear that date.

When an operator acted as another user, the Operator column names the operator and says “Acting as” the user. When an operator acted under delegated authority on your organisation's behalf, the entry names the operator and the role they held in that session. It does not name the party the operator worked for.

Select Next page to go back in time and “Previous page” to return. The last page holds the oldest entry of the window. When nothing matches, the screen reads “No recorded actions match”, and “Clear all” removes the filters.

Open an entry

Select an entry's operation to open its sheet, Audit entry. From the sheet, “Show actions by this operator” adds an “Operator” chip to the toolbar, and “Show history for this resource” searches for the entry's target. Compare the entry's actor, “Role at the time” and outcome with the event you are investigating.

Continue the investigation

The sheet shows the operation's target. The Technical block, folded by default, holds:

the operation identifier
the Target path, with credentials such as passwords and tokens in its query string replaced by REDACTED
the Status, the “Entry ID” and the “Request ID”
the Approval ID, for an entry that proposed or decided a maker-checker approval.

For a decided approval the sheet names the Maker, the user who proposed it, and the “Checker”, the user who decided it. The “Checker” column of the list names the same user for a trade bust, a desk limit or a filing.

For a consolidated transition, one request that moves a record to a new state, the reason is the requested destination state. A failed transition records the state it was asked to reach. A reason that reads “From an assistant question” marks a read the assistant made.

The target does not always name the affected resource. GET /api/v2/reporting/trail/resource returns every actor and route that touched one resource. For a change that recorded no values, the operation's owning page holds its history, such as Obligations for an obligation publish.

Read an entry's outcome

An entry's outcome is one of three values:

Outcome	What it means	What to do
Success	The operation completed and its response carried no error.	Nothing further.
Failure	The request returned an error. The entry alone does not prove that every side effect was rolled back.	Read the error and check the affected resource before retrying. Follow that operation's retry and idempotency rules.
Pending	The platform recorded that the operation started but never recorded that it finished.	Treat it as unresolved. Open the operation's own owning page, such as Obligations for an obligation publish, and check its current state there, since only that page knows whether the write finished.

For a write to on-chain access, a smart wallet or an add-on that the platform accepted and queued, the badge shows the chain's result instead of “Success”. The badge reads “Queued” while a transaction is still open, “Confirmed” when every transaction completed, and “Reverted” when any transaction did not take effect. The entry sheet shows the roles or settings “Before” and “After”, and the Technical block lists each transaction with its hash and, for a reverted one, the revert reason. A request that failed keeps the “Failure” badge. An open sheet for a queued entry refreshes every five seconds until the chain settles it.

Export the trail as CSV

Select Export in the table toolbar to download a CSV file of the window and filters the page shows. The file holds every entry that matches, oldest first, however many pages that is. Spreadsheet formulas in a cell are written as text, so the file is safe to open in a spreadsheet. Every export adds its own sensitive-read entry to the trail that names who exported and the filters. If the platform cannot write that entry, it refuses the export and sends no rows. API routes gives the export route.

Read assistant questions

When the assistant is on for your organisation, or the window holds at least one question, the screen shows two tabs under the title, “Actions” and “Assistant questions”, each with a count. The Assistant questions tab lists every question people in your organisation asked the assistant, newest first. The columns are “Question”, “When”, “Asked by”, “Outcome”, “Asked about” and “Rating”. The question is shown as the person typed it. The date range carries over when you switch tabs.

Each question ends with one outcome: “Answered”, “Refused”, “Timed out”, “Failed”, “Stopped”, or “Started” while the answer is still running. Narrow the list with “Person”, “Outcome” and Rating, which takes “Helpful” or “Not helpful” and shows how people rated the answers. The detail of a “Not helpful” answer shows the reason and the note the person wrote, when they sent one.

Select a question to open its detail, Assistant question. It shows the “Question”, the “Answer”, what it was asked about and the person's “Role at the time”. Its “Technical” section shows the “Model”, the “Time taken”, the “Tokens”, the “Refusal code” when there is one, and the “Reads made”, the operations the assistant read. The reads name the operations, never their input or the data they returned. “Show questions from this person” adds the person filter.

Sent to the model shows only when it differs from the question. Before the question reaches the model, the platform replaces the names it recognises, email addresses and 0x addresses with handles or placeholders. A name it does not recognise, such as one typed in lower case, is sent as typed, so check this field when the question named a person.

An entry on the “Actions” tab whose reason reads turn=<id> is the record of one of these questions. Its detail has an Open this question button that opens the same detail on the other tab.

Select Export to download every question in the window and filters shown, oldest first, as assistant-questions-<from date>-<to date>.csv. The file holds the id, start time, person, asset, question and outcome of each question, and follows the same rules as the trail export.

The same roles can read this tab as the Actions tab, and every list, detail and export read adds its own entry to the trail. Questions are kept under the assistant's retention rule. Removing a person's account removes their questions, while the “Actions” entries that recorded them stay on the trail without the question text.

Troubleshooting

What you see	What it means and what to do
No matching operation appears	Confirm the organisation. The screen opens a 30-day window, so older operations are outside it until you set From and To in the window button. Inside the window, the first page holds the newest 200 entries. Select Next page until you reach the time of the operation, or clear the Action, Channel, Entry type and search filters if one of them hides it.
The entry has no changed values	The entry sheet shows Before and After values only for an operation that records them, such as a configuration change, and it never shows request bodies. The target keeps ordinary query parameter values, with credentials redacted, but not the fields an operation changed. Use the owning operational record when you need field-level history.
An entry stays Pending long after it should have finished	Two failures produce Pending, and the entry does not say which: a request lost to a crash before it finished, or a request that ran to completion whose closing write failed. Open the operation's owning page and check its current state there. Do not assume Pending means the work is still running.
The Assistant questions tab is missing	The tab shows when the assistant is on for your organisation, or when the window holds at least one question. Widen the window to find older questions.

Frequently asked questions

Can I change an obligation's requirements from here?

No. This screen only reads. An organisation owner or platform administrator prepares or edits a draft on Obligations, and can publish it there.

Can I look further back than 30 days?

Yes. Thirty days is the default. Open the window button, set “From” and “To”, and select Apply. “Last 30 days” in the same panel restores the default. The window reaches back only as far as the deployment's audit retention, which the audit trail concept page describes. For a one-off file, use the CSV export with the window you need.

Does opening this screen put an entry on the trail itself?

Yes, whenever the platform can write the entry, and the same is true of a call to the reporting endpoints. When that write fails, the platform still serves the read and logs the failure. Only the CSV export refuses to run without its entry.

API routes

The screen uses these routes of the Platform API. Each takes a time window, and the API reference defines the request and response fields.

GET /api/v2/reporting/trail reads the organisation's entries. Each entry carries targetName, the name of the resource it targets: the token, member, venue or add-on name, or the symbol of the token a sale sells. The platform resolves it for the caller and answers null when the target has no name or the caller may not read it.
GET /api/v2/reporting/trail/resource returns every actor and route that touched one resource.
GET /api/v2/reporting/trail/integrity checks the hash chain of a date range.
GET /api/v2/reporting/trail/operator returns the entries of every organisation on the deployment to a platform administrator. That read is itself recorded. GET /api/v2/reporting/trail/operator/integrity verifies the platform chain, the entries that belong to no organisation, over a date range of up to 31 days.
GET /api/v2/reporting/trail/export returns the CSV export.

The export returns the same fields as the trail read, one row per entry, with transactions, a JSON list, and transactionOutcome as the last two columns, as a UTF-8 file with a byte order mark so spreadsheets read it correctly. The filename is audit-trail-<from date>-<to date>.csv.

curl "https://your-instance.example.com/api/v2/reporting/trail/export?from=2026-09-01T00:00:00Z&to=2026-09-30T23:59:59Z" \
  -H "X-Api-Key: <your api key>" \
  -o audit-trail-2026-09-01-2026-09-30.csv

from and to are required ISO 8601 timestamps. Both bounds are inclusive, so start the next window after the previous to to avoid repeating an entry. A to later than the moment of the export is treated as that moment.
target, actorUserId, actorChannel (one of admin, participant, system or agent), kind (mutation or sensitive-read) and route are optional and filter the export the same way they filter the trail read. The export has no paging parameters.
The access rules match the trail read. An export never includes another organisation's entries.
The platform streams the file, so a large window starts downloading at once.
A cell that starts with =, +, -, @, a tab, or a carriage return is written with a leading apostrophe. A cell in which a comma, semicolon, tab, or pipe comes before one of those characters is written in quotes. A spreadsheet then shows the cell as text and does not run it as a formula.
The export's own trail entry has the reason export rows=<n> from=<from> to=<to>, plus target=<target>, actor=<user id>, channel=<channel>, kind=<kind> and route=<operation> for each filter you gave.
The export reads the Audit trail as it stands and adds no retention rule of its own.