Cadmos under Swiss DLT law

Switzerland's DLT Act gave tokenized securities a clean legal home. The 2021 amendment introduced Article 973d of the Code of Obligations (CO), which lets ledger-based securities — including fund units — be issued and transferred directly on a blockchain, with the same legal effect as a paper certificate. Cadmos was built inside that home. The three things Article 973d CO actually requires — power of disposition, integrity, and transparency — aren't a regulatory veneer in our stack. They are the architecture.

This article walks through what the law asks for, the five components Cadmos is built from, and how each pillar of Article 973d CO is answered in the code. A companion piece on the FCA's recent UK guidance — PS26/7 — covers the same primitives mapped onto the British regime. The full module-by-module documentation lives at docs.cadmos.finance; this is the executive summary.

What Article 973d CO actually requires

The Swiss DLT Act is unusual among securities regimes: it is technology-neutral. It doesn't mandate a particular blockchain, token standard, or smart contract framework. It sets outcomes, and asks the issuer to demonstrate them. Three pillars define those outcomes:

• Power of disposition. Only the holder of the security has the power to transfer it. The ledger must enforce this — no one else, including the issuer, can override the holder's control by default.
• Integrity. The ledger and the security's terms must be protected against unauthorized modification. Governance must not allow silent rewrites of holder positions or token logic.
• Transparency. Holders must be able to verify their position and the security's status. The legal terms attached to the token must be reachable, and historical states must be reconstructable.

These are deliberately minimal — the law assumes the technology will evolve. The job of any tokenization platform is to satisfy each pillar in code, in a way an issuer's counsel can defend.

Cadmos at a glance

Before mapping each pillar to the code, a quick orientation. Cadmos's smart contract layer is built around five components, all open-source and documented at docs.cadmos.finance:

• The fund token. The ERC-20 unit each investor holds. Subscriptions, redemptions, and any secondary transfers all run through it.
• The administrator. A privileged module that controls who in the fund's operations team can do what — issue units, freeze accounts, force a transfer, change configuration. Permissions are fine-grained: 53 distinct flags, each individually assignable to a specific operations address.
• The whitelist. The on-chain investor register. Only addresses on the whitelist can subscribe to, hold, or transfer the fund's tokens.
• The primary market. A pair of settlement contracts — one for subscriptions, one for redemptions — that batch investor flows, price units at the published NAV (net asset value), and settle the cash and token legs in coordinated steps.
• The protocol registry. The contract that governs upgrades. New versions register here; each fund's administrator independently chooses if and when to adopt them.

Everything else — fee computation, snapshot management, distributions, e-signature integrations — sits as supporting modules on top of these five. With that orientation in mind, the three Article 973d CO pillars are easy to map.

How Cadmos satisfies each pillar

Power of disposition

Power of disposition means the holder of a token controls its transfer. On Cadmos, every routine transfer of a fund token is gated on the holder's private key — no third party can move a token by default.

Real fund operations occasionally need an exception: a court order, an inheritance, a fat-finger correction. Cadmos handles these through a single, named privilege on the administrator module — the forced-transfer flag. That flag is structurally protected: it cannot be silently assigned, removed, or renounced through normal admin pathways, and every forced transfer emits an auditable on-chain event identifying the administrator who triggered it. Holders control their tokens by default; any exception is publicly logged.

Integrity

Integrity means the ledger and the security's terms can't be silently rewritten. The usual failure mode in tokenization platforms is the platform owner pushing an upgrade that retroactively changes how an issuer's pool behaves — without the issuer's say.

Cadmos doesn't allow that. Upgrades are opt-in. The platform team can register a new contract version in the protocol registry, but each issuer's pool administrator must independently and actively adopt it for their specific pool. Until they do, the pool runs exactly the version they last approved. The activation itself goes through a 15-minute on-chain timelock so monitors and counterparties can detect the change and respond. Ownership of the protocol registry is transferred in two steps — a new owner must accept the role, not just receive it — so even at the platform level, control cannot move by accident or by a single private key. The combined effect: an issuer's holders cannot have their pool rewritten beneath them, even by Cadmos.

Transparency

Transparency means holders can verify their position and the security's terms. Cadmos answers this on three layers.

First, the legal layer. Every fund token exposes a settable URI pointing at the fund's legal documents — typically pinned to IPFS (a decentralized file system that produces tamper-evident content addresses) or hosted on the issuer's own domain. The contract itself tells you where to find the prospectus and the registration agreement.

Second, the historical layer. The fund token uses OpenZeppelin's snapshot extension — an open-source Solidity library that lets a contract take periodic snapshots of every holder's balance. Anyone can query the contract for the balance of any address at any prior snapshot, plus the total supply at that moment. That's the on-chain equivalent of a date-stamped register pulled out of the cap table — cheap to produce, impossible to forge.

Third, the operational layer. Every privileged action — a whitelist update, a forced transfer, a fee crystallization — emits an on-chain event. The set of administrators and the privileges each one holds is publicly readable. A holder, an auditor, or a regulator can reconstruct the full history of any pool — who held what, when, and which administrator approved each step — without asking anyone for permission.

Beyond the legal minimum

Article 973d CO sets the floor. Running a tokenized fund needs more: investor onboarding, primary-market settlement, NAV pricing, fees, distributions, redemptions. Cadmos provides each as a first-class module.

• Investor onboarding. The whitelist supports both batch on-chain registration (the operations team adds a list of approved wallets in one transaction) and a gasless mode where an off-chain signature from an authorized signer unlocks a wallet at the moment of subscription. Cleared wallets can be frozen if a regulatory hold is required. Subscription documents flow through DocuSign and Yousign integrations alongside KYC (Know Your Customer) checks.
• Primary market. Subscriptions and redemptions are batched, priced at the published NAV, and the cash and token legs settle in a coordinated way. Cooldowns and deposit limits are configurable per fund.
• Fees. A dedicated fee module computes management, administration, and performance fees, including high-watermark logic with crystallization — the kind of mathematics fund administrators normally rebuild bespoke for each vehicle.
• Distributions. A distribution module pays out pro-rata to holders as of a snapshot, on demand, with the same on-chain audit trail as every other privileged action.

What Cadmos handles, and what stays with the issuer

Compliance is a collaboration between code and counsel. Cadmos is the technology and operations layer. The issuer remains the regulated party. The Registrierungsvereinbarung — the registration agreement that anchors a Swiss ledger-based security to its legal terms — is drafted by Swiss counsel for the issuer, not by Cadmos. The platform's job is to make sure the registration agreement's text matches what the smart contract enforces. The issuer signs the legal record; Cadmos provides the rails. That separation is intentional: the regulated functions sit with the regulated party, while the technical primitives — power of disposition, integrity, transparency — show up in the code.

A note on CMTAT

Switzerland has a voluntary industry standard for tokenized securities called CMTAT — the Capital Markets and Technology Association Token, maintained by an industry association of Swiss banks and law firms. CMTAT is a useful reference, but it is a standard, not the law. Meeting CMTAT does not by itself satisfy Article 973d CO, and missing CMTAT does not by itself fail it.

Cadmos provides functional equivalence or superiority for every CMTAT core module: 53 individually assignable admin flags vs. CMTAT's eight role categories; opt-in upgrades vs. unilateral admin upgrades; an independent subscription/redemption pause — plus NAV transparency, batch settlement, fee management, distributions, and other fund-administration features that CMTAT does not include at all. CMTAT is a useful baseline; Article 973d CO is the actual obligation; Cadmos is built to meet the obligation directly.

Compliant by construction

A compliant stack is one where the regulator's outcomes show up in the code. Article 973d CO asks for power of disposition, integrity, and transparency. Cadmos's smart contract layer answers each one — not as a bolted-on overlay, but as the structure of the system itself. For an issuer launching a tokenized fund or private-market vehicle in Switzerland, that means fewer compliance gaps to plug, less code to write, and a defensible architecture from day one.

A companion piece — FCA PS26/7 and Cadmos — maps the same primitives onto the UK's new fund tokenisation rulebook, and shows where the two regimes are converging on the same architectural answers. For deeper detail on any module described here, see docs.cadmos.finance.