Security & compliance
Controls first. Everything else follows.
Tokenisation does not remove the obligations of a securities operation — it makes them enforceable in software. Thidon is built around that idea.
Explainable transfer rules
Every transfer is checked against a named rule catalogue — token state, KYC, whitelist, investor category, jurisdiction, balance, holding limits, escalation thresholds. Failures say why, and which role can resolve them. The same engine re-runs inside the settlement transaction.
Maker-checker everywhere
No single person can move the register. Approval rights come from an explicit role matrix; the checker must differ from the maker; decisions are status-guarded so a race or double-click cannot execute twice.
An append-only system of record
Balances and supplies are derived caches over an immutable movement log. The registrar re-derives them before every confirmation — if anything drifts, the confirmation is refused.
Operational separation
Issuer, control-agent-style registrar, paying agent and account records are separate functions with separate permissions — mirroring Luxembourg's dematerialised-securities framework for DLT-based issuance accounts.
Evidence, not assertions
KYC decisions, NAV publications, failed checks and every approval leave durable records: who, what, when, outcome, note. Blocked attempts are kept — they are compliance evidence, not noise.
Permissioned by design
The market is a private, permissioned environment in the spirit of the EU DLT Pilot Regime — order interest, RFQs and operator matching inside the perimeter. No public order books, no anonymous flow.
Standards alignment
The compliance model mirrors ERC-3643 (T-REX): identity registry, claim-based eligibility, transfer pre-checks, freezing, pausing and agent roles. The registrar and paying-agent workflows keep room for an ERC-1450-style transfer-agent-controlled adapter. In the demonstration environment the ledger is simulated; the control logic is the product.
See a transfer get blocked — on purpose