The filing your regulator asked for
Report families now generate from platform data on your filing schedule, and every state-changing request is recorded with the person, role, and outcome.
DALP 3.2 generates report packages from platform records and creates filing periods from published obligations. An audit trail records actors, roles, operations, and outcomes for covered requests.
From platform data to a filing package
You declare the reporting duties your organisation is subject to. Publishing one freezes an immutable version, and that version's cadence generates the filing periods you owe, with their deadlines. Reports read the same records the platform's own compliance and settlement paths write, rather than a copy assembled for reporting.
- Report families
- Ten
- Schedule
- From your published obligations
- Output
- CSV and XLSX in one package
- Audit trail
- Actor, role, route, outcome
The report is only as good as the trail behind it
On-chain signatures and platform audit records answer different questions.
A signature on a chain proves that a key authorized a transaction. It does not say which person held that key, what role they held at the time, or who read a holder's records without changing anything. That gap is exactly what a reviewer probes, and it cannot be closed with on-chain data alone.
The platform now writes an audit trail: one off-chain record naming the actor, the role they held at that moment, the operation, and the outcome. It covers two kinds of request. A state-changing request is any call that alters something, such as publishing an obligation or approving a filing. A sensitive read is a call that changes nothing but exposes records a reviewer would want accounted for, such as reading who acted on what.
Two properties make this usable as evidence rather than as a log. A state-changing request that cannot record its audit entry is refused rather than completed, before the mutation runs. A sensitive read still succeeds, because a recording failure does not block these reads, but the platform reports the recording failure instead of dropping it.
Report families, generated rather than assembled
Each report family draws from a named source and a bounded window, so the same request over the same period produces the same answer.
| What you are reporting on | Report families |
|---|---|
| Movement and events on chain | Transfer journal, settlement and fails, corporate actions |
| Who is eligible and what was decided | Compliance decision log, investor eligibility register |
| Who holds the asset | Holder register |
| What your operators did | Operator action trail |
| Backing and money | Reserve and asset backing, fees and charges, fee period closes |
A generated filing arrives as one package containing its reports in CSV and XLSX, so the file goes to a regulator or an auditor without a spreadsheet being rebuilt by hand.
The calendar comes from the obligation, not from a reminder
Published obligations determine the filing calendar.
You draft an obligation, meaning the reporting duty your organisation is subject to, and publishing it freezes an immutable version of what you committed to. That version's cadence is what generates the filing periods, each with its own deadline, onto a calendar. Nothing is typed into a calendar by hand, so nothing drifts from the obligation it came from. Around each filing sit the steps a real process needs: generation, sign-off, submission, and the acknowledgement that comes back. Each filing also records retention, legal hold, and eventual erasure. A legal hold prevents deletion while the relevant matter remains open.
Availability and compatibility
Reporting is available to every organisation and needs no flag, but it does nothing until you configure it. No obligation is switched on for you, so the calendar stays empty until you publish your first one. That is deliberate: the platform does not guess what you are required to file.
Nothing here changes an existing integration. The reporting surface and the audit trail are additive, and the v1 API stays frozen. The audit trail begins recording when the platform is upgraded; it does not reconstruct requests made before then.
Understand reporting obligations → · Publish an obligation → · Work the filing calendar → · Review who acted →
Compliance controls
Six controls close gaps found in a two-class share structure: expiring claims, a sanctions rule the subject cannot undo, a minimum holding, and a supermajority.
Weighted multisig
A participant account can now be a multisig wallet where each seat carries its own weight and the bar to clear is a total of weights rather than a signer count.