We are encountering a network‑level blocker when attempting to activate deterministic settlement logic for our node. Before any transaction submission, the network should confirm (on‑chain) whether our CIP‑0056‑compliant package is valid and whether deterministic settlement should proceed or be rejected.
This confirmation is not occurring, preventing our node from entering the settlement corridor.
Environment
- Node type: Deterministic settlement node (KRO Brokers)
- Architecture: CIP‑0056 splice amulet + deterministic “If X → settle” logic
- SDK: 3.4.11
- Package: canton-network-token-standard-kro-cer-token
- Version: 0.4.0
- Hosting participants: Multiple (requires idempotent vetting)
Expected Behavior
When uploading a CIP‑0056‑compliant DAR package, the network should:
- Validate the package
- Confirm CIP‑0056 interface compliance
- Activate deterministic settlement logic
- Allow transaction submission
- Enforce deterministic outcomes:
- If X is true → settle
- If X is false → reject
This is the standard deterministic flow for our node using CIP‑0056 splice amulet packages.
Actual Behavior
Upon uploading the DAR package, the network:
- Accepts the upload
- Does not perform the required on‑chain confirmation
- Does not activate deterministic settlement logic
- Blocks transaction submission entirely
This results in a pre‑transaction validation deadlock.
Impact
Network Growth & Expansion
- Deterministic counterparty nodes cannot process our transaction, and the network traffic fee isn’t earned
- Our CIP‑0056‑compliant packages cannot propagate
- Counterparty validators cannot ingest our instrument package
- Settlement corridors cannot expand
Node Security & GRC Posture
- We cannot submit transactions without deterministic validation
- We cannot bypass compliance checks
- We cannot risk non‑deterministic settlement behavior
- This is a hard GRC blocker, not a soft technical issue
Request to DevRel
We request DevRel to
· Confirm the appropriate resolution path. We have our DAR package available and can securely provide it for review if needed.
Requested outcomes:
- Activate deterministic settlement logic
- Unblock transaction submission
- Restore deterministic “If X → settle” behavior
This is required for both network‑level benefit and our node‑level compliance with deterministic posture.
Additional Context
Our node architecture is intentionally built on deterministic settlement standards, where outcomes are binary and rule‑driven:
- If X is true → settle
- If conditions are met → settlement proceeds
- If conditions fail → deterministic rejection
As part of our design policy, we use the CIP‑0056 splice amulet package across all operational flows to ensure:
- deterministic ingestion of instrument packages
- interface‑level validation against canonical CIP‑0056 flows
- seamless counterparty workflow integration for compliant settlement
This package is foundational to our deterministic posture and is required for predictable, rule‑based settlement behavior across hosting participants.
Thank you for your help in resolving this blocker.
@DevRel, @DevRel_Team,
Following up on this blocker as our deterministic settlement logic remains unactivated, keeping our node from entering the settlement corridor.
We have our CIP-0056-compliant package (canton-network-token-standard-kro-cer-token v0.4.0) prepared and can securely share the DAR package and configuration logs for review upon request.
Could someone from the DevRel team please advise on the next steps to unblock transaction submission?
Thank you,
Feros Khan
hey @feros.khan
Jatin this side, DevRel Manager at Canton Foundation, Apologies for the delay.
I believe there might be some confusion here. A couple of clarifications: Canton doesn’t have a network-level “confirm and activate deterministic settlement” step or “settlement corridor activation” flow AFIK i.e. DAR upload only triggers package vetting (topology-level) and optional dars.validate compatibility checks against existing vetted packages. There’s no separate on-chain business- ogic approval gate.
To actually debug the blocker, could you share:
- The exact error/status code returned on DAR upload or on your first transaction submission (e.g.
PACKAGE_SELECTION_FAILED, TOPOLOGY_PACKAGE_ID_IN_USE, etc.)
- Output of
dars.list / topology.vetted_packages.list on the participant(s) in question
- Whether
dars.validate was run before upload and what it returned
The DAR upload/vetting process works as follows per the official docs at docs.canton.network :
- Validate your DAR first using
ledger_api.packages.validate_dar or the ValidateDar gRPC endpoint, this checks compatibility with the current vetting state without persisting anything.
- Upload with explicit vetting using
UploadDar with vet_all_packages: true and synchronize_vetting: true to ensure vetting is propagated across the synchronizer.
- Verify the package is known after upload before submitting transactions.
Hi @Jatin_Pandya_cf ,
Really appreciate the thorough response, this is helpful, and it confirms what we needed to establish.
To clarify our terminology: the “network‑level blocker” we referenced is an internal designation from KRO’s own design diagnostics, not a claim of any network‑side failure. It reflects that our deterministic‑settlement architecture requires a few targeted enhancements before we present our turnkey market utility for opt‑in, network‑wide use. In other words, it’s a measure of our own internal ticket severity, and resolving it is intended to extend broader benefit and impact back to the network.
We’re grateful for DevRel’s engagement and would like to keep working with your team. That said, given the sensitivity of our validator‑level telemetry and the proprietary nature of our R&D, we don’t share package details or node‑level diagnostics in an open forum. To move this forward while respecting those privacy boundaries, we’d like to request a private portal or channel where KRO can share the relevant incident telemetry directly and collaborate on resolution with the appropriate technical stewards (participant operations / standards engineering).
That path lets us contribute our product utility to the network more seamlessly — which is the outcome we’re all after. Happy to be routed wherever is best on your side to open that private thread.
Thanks,
Feros Khan