Canton Data Services (Beta)
Query Canton positions, settlements, exceptions and ledger activity over REST, without indexing the ledger yourself.
BetaCanton Data Services is in Beta. Endpoints and response fields can change as the product evolves.
Real-time delivery of ledger events is planned and is not available yet.
Canton Data Services gives you the data you need from a Canton ledger through a REST API. Blockdaemon hosts, deploys and manages the data plane, which is built on Digital Asset's Participant Query Store (PQS). On top of it, Blockdaemon exposes REST endpoints for positions, settlement activity, issuance, compliance records and the full ledger update feed.
Architecture
Blockdaemon hosts and manages the data plane. It is built on Digital Asset's Participant Query Store (PQS), which reads from the validator. The REST API reads from the data plane, and your systems call the REST API.
flowchart LR V["Canton validator<br/>settles transactions"] --> D["Blockdaemon data plane<br/>built on PQS"] D --> A["Canton Data Services<br/>REST API"] A --> C["Your systems"]
Reads of ledger data are served from the data plane, so queries do not compete with the validator for settlement capacity.
Why a data plane
Canton validators are built to settle transactions. They are not built to answer questions about balances, settlement history or audit. Each row below is a gap that Canton Data Services fills.
| Need | The challenge on Canton | What Canton Data Services provides |
|---|---|---|
| Positions | Canton holds assets as individual holding contracts. Answering "what do we have, and how much is usable?" means indexing them yourself. | Positions arrive already computed as total, locked and available, stamped with the ledger offset they are as of, and ready for an availability check. |
| The business record | The validator's active view holds only the present. Settled transfers leave it, and a rejection reason appears only as it happens. | Records the ledger commits, including settled transfers and rejections, are exposed as REST resources. Closed records stay readable with status: closed. |
| History | Validators are settlement engines, not archives. | A feed of ledger updates in order, which you can resume from any ledger offset you have processed. Position responses are stamped with the offset they are as of, for audit and reconciliation. |
| Validator capacity | Every query competes with the node's real job, which is writing transactions. | All reads are served from the data plane. The validator keeps its capacity for settlement. |
| Integration | The Ledger API speaks gRPC and Daml records. Bank systems speak settlements, exceptions and deadlines. | REST resources in settlement language: transfers, rejections, allocations and their deadlines. Real-time delivery is planned. |
| Assets | Every token and every client is integrated separately. | One normalised integration for DTCC registry securities, Canton Coin and any asset that implements the Canton Token Standard. Raw contract payloads cover your own Daml templates. Access is party-scoped, so one deployment serves each client its own view. |
What you can query
The API is served in three independently licensed tiers, plus wallet-centric Portfolio views.
| Tier | Path prefix | Use it to |
|---|---|---|
| Canton core | /native | Check dataset freshness, follow every ledger update, read raw contract payloads, list parties and validator rewards. Works on any Canton participant. |
| Token standard | /token | Read positions, holdings, allocations and transfer instructions for any Canton Token Standard asset. |
| DTCC registry | /dtcc | Read settled transfers, issuance activity, rejections, compliance delegations and party credentials. |
| Portfolio | /portfolio/v1 | Read a wallet's balances and transaction history. |
Tiers are additive. When the DTCC registry tier is also licensed, token standard endpoints add registry-specific fields. See the API Overview for tiers, authentication, offsets and pagination.
Beta status
- Real-time delivery is planned. Today the API is query-based. To stay current, poll the update feed as described in Audit & Incremental Sync.
- Instrument reference data endpoints are in the API specification but are not served yet.
- The API specification is version
0.1.0and is updated as the product develops.
Next Steps
Updated about 3 hours ago