Shipping Matter
Matter's Distributed Compliance Ledger (DCL): The Source of Truth for Device Attestation
Abu
7 min read
A device is only as real as the record that says it’s certified. We’ve watched devices fail onboarding because the Distributed Compliance Ledger (DCL) said nothing about them. The DCL is that record - a permissioned blockchain holding every product’s certification status, every vendor’s PAA root certificates, and every compliance record. Get it wrong and a commissioner can’t tell your certified product from a clone.
What problem does the DCL solve?
Matter devices join ecosystems run by Apple, Google, Amazon, and Samsung. No single company owns the certification authority. A central database run by one entity would be a single point of failure, a single point of censorship, and a trust bottleneck. The DCL solves all three:
| Problem | DCL solution |
|---|---|
| Single point of failure | Distributed across validator nodes run by Alliance member companies globally (10 validators on mainnet as of mid-2026) |
| Single point of censorship | Byzantine Fault Tolerant (BFT) consensus - no single node can block a transaction; safety holds as long as fewer than one-third of validators are malicious |
| Trust bottleneck | Permissionless reads, permissioned writes - anyone can verify, only authorized roles can publish |
The DCL is the canonical record of which devices are certified, which PAA certificates are trusted, and which certifications have been revoked. Commissioner tooling pulls its PAA roots from the DCL before commissioning (see how attestation actually works ).
Why a blockchain?
The DCL is built on Cosmos SDK and CometBFT (Tendermint) . It’s not a cryptocurrency - no token, no mining, no gas fees. Blockchain gives it three specific properties:
Immutability. Once a block commits, it can’t be altered. Each block hashes the previous one. Tamper with a record and every block after it breaks, so tampering is cryptographically detectable.
Byzantine Fault Tolerance. Safety holds as long as fewer than one-third of validators are Byzantine; liveness needs more than two-thirds online. Consensus is CometBFT (Tendermint) BFT. Proof-of-Authority governs which nodes validate - trustee-approved Alliance members - but the consensus algorithm itself is BFT, not PoA.
Decentralized verification. Any node can independently verify the entire ledger state. No trust in a central server required.
What the DCL stores
Four categories of records:
1. Vendor records
Each Alliance member gets a Vendor account: Vendor ID (VID), company name, contact info. The VID is the same identifier stamped into every DAC your devices carry.
2. PAA root certificates
Product Attestation Authority (PAA) certificates are the trust roots for device attestation. Before a commissioner can verify a device’s DAC chain (PAA -> PAI -> DAC), it has to trust the PAA. PAA roots are proposed by the Alliance’s Trustee and approved by the other DCL Trustees - that’s how they enter the trust store commissioners validate against (matter-handbook DCL guide ).
This is why the DCL matters for commissioning. If your PAA isn’t approved and listed, no trusted commissioner validates your DAC chain. Your device fails attestation. Period.
3. Product models and versions
Each product entry includes Model, Model-Version, software version, firmware information, and OTA update metadata. Commissioners use this to check that the VID/PID in the device’s DAC matches a certified product in the DCL.
4. Certification status
After certification passes, the CSA Certification Center writes the Certification Declaration (CD) reference into the DCL: certification ID, date, compliance status. If a certification is revoked, the status updates here, and commissioners see it on the next attestation check.
How the DCL fits into device attestation
Device attestation is the cryptographic handshake that proves a Matter device is genuine and certified. The DCL underpins three checks:
Step 1 - Trust the PAA. Commissioner tooling pulls approved PAA roots from the DCL into a local trust store - the Matter SDK ships a script for exactly this (credentials/fetch_paa_certs_from_dcl.py
). At commission time the commissioner validates the device’s chain against that local store; it doesn’t query the ledger live on every onboarding.
Step 2 - Verify the chain. The commissioner checks that the device’s PAI was signed by a trusted PAA and the DAC by that PAI, and cross-checks the VID/PID in the DAC subject against the CD’s dacOriginVendorId/dacOriginProductId and the Basic Information cluster. A VID that was never registered in the DCL means no trusted PAA ever signed the chain.
Step 3 - Verify the CD. The commissioner cryptographically verifies the Certification Declaration - signed by the CSA Certification Center, binding VID/PID, certificate ID, and (since Matter 1.1) the list of authorized PAAs. Certification status, including revocation, is what the CSA records in the DCL; a revoked certification is visible to ecosystems that check the ledger.
Node types and roles
The DCL network has a defined set of roles:
| Role | Permissions |
|---|---|
| Trustee | Approve/reject new PAA certificates, disable validator nodes, approve other roles |
| Node Admin | Instantiate and manage a single validator node |
| Vendor | Write vendor info, product models, and software versions to ledger |
| Vendor Admin | Add and update vendor account information |
| Certification Center | Submit, update, or revoke certification status of products |
Three node types exist (plus a Light Client Proxy and Seed node type):
- Validator Nodes (VN) - participate in BFT consensus, run by Alliance member companies, write transactions.
- Sentry Nodes (SN) - wrap validators, provide DDoS protection and access control, don’t participate in consensus.
- Observer Nodes (ON) - serve public reads and authenticated writes; the entry point for commissioners and client apps.
For manufacturers, the practical interface is the DCL WebUI (browser-based vendor/product management) or the dcld CLI for automation.
Main-Net vs Test-Net
Main-Net. The production ledger. Real products, real certification data. VID, model, and version entries must be complete before CSA certifies your product.
Test-Net. A parallel network for development. Validate your vendor account, product models, and PAA submissions here before touching Main-Net. Identical API and tooling.
What manufacturers must do
Before shipping:
- Create a Vendor account. Request a Vendor role through the CSA for write access to vendor and product records.
- Add your VID and company info. Register your VID - the same one that appears in every DAC your factory provisions.
- Add product models and versions. List each Model and Model-Version that will ship. The VID/PID in your DAC must match a DCL entry.
- Submit PAA certificates. Running your own PAA? Propose it; Trustees must approve. Using a third-party PAA (recommended for most)? Confirm it’s already listed.
- Complete certification. After certification passes, the CSA Certification Center writes your status to the ledger. Now it’s publicly verifiable.
- Update on firmware changes. Ship a new certified firmware version, update the Model-Version entry. Commissioners check this field; a version not in the DCL can fail attestation depending on ecosystem policy.
What happens if you skip the DCL
Your device fails commissioning. Valid DAC chain, valid CD, passed certification - none of it matters if your PAA was never approved and listed. The DCL is how the ecosystem decides which PAA roots to trust at all.
Ecosystems block onboarding. Apple, Google, and Amazon commissioners all validate against PAA roots published in the DCL. No listing, no trust, no fallback - the DCL is the authoritative registry.
Certification is not complete. CSA doesn’t issue a Certification Declaration until your product records exist in the DCL and match your application. The DCL listing is a prerequisite, not an afterthought.
DCL and the DAC provisioning pipeline
The DCL is the trust anchor for the whole PKI chain in the DAC provisioning pipeline . Every certificate - PAA, PAI, DAC - is only as trustworthy as the commissioner’s ability to verify it against the DCL.
The sequence for a production run:
Get the DCL entries wrong and devices fail end-of-line testing . Get them right and every commissioner on the planet can verify your device without you running a single server.