Development Fund Proposal
Author: Maranda Harris — Founder, CompliLedger
Status: Submitted
Created: 2026-09-08
Label: regulatory-compliance
Champion: Need Champion
| From | To |
|---|
| Manual | AI-Native |
| Periodic | Continuous |
| Point-in-Time | Current / Near-Real-Time Assurance |
| Audit Prep | Audit-Ready |
| Reports | Machine-Verifiable Proof |
| One-Time Assurance | Reusable Continuous Operational Assurance |
Thesis: Canton enables institutional financial workflows to move digitally and privately. CompliLedger is designed to make the compliance and governance supporting those workflows continuously evaluated, current, and independently verifiable.
Freshness and currentness depend on supported evidence, material-change detection, authorization, and defined processing limits; verification establishes only supported checked properties.
Abstract
Financial infrastructure is becoming digital, tokenized, programmable, interconnected, and increasingly automated, yet institutional assurance is still commonly manual, fragmented, periodic, and document-driven. Organizations repeatedly reconstruct evidence and determinations for audits, regulators, counterparties, and operations even when the underlying requirements, controls, and operating conditions continue to change.
CompliLedger is AI-native compliance and governance infrastructure and AI-Powered Proof Infrastructure. It takes requirements, target, context, and operational state into a continuous process that determines applicability and applicable controls, orchestrates authorized evidence collection and validation, assesses evidence sufficiency, and produces deterministic evaluations, decisions, and portable proof. AI assists interpretation and orchestration, but it does not independently determine consequential requirement satisfaction.
CompliLedger is designed to reassess when evidence expires, approvals or authority change, operational conditions drift, controls or requirements change, or other material changes affect the supported determination. It preserves historical lineage while distinguishing current assurance from stale, insufficient, superseded, or otherwise changed states and communicates supported limitations where a determination cannot be made. Proof is the machine-verifiable output of that maintained process, not the entire product.
For Canton participants, this can make applicable assurance reusable within privacy-aware institutional workflows involving tokenized RWA, settlement, stablecoins or tokenized money, custody, eligibility checks, governance approvals, banking controls, and governed AI-agent transactions. These are qualified potential use cases subject to applicable requirements, supported controls and evidence, authorized integration, and explicit processing limits; they do not create additional funded references, blanket regulatory applicability, or universal deployment claims.
CompliLedger already exists as a functioning platform, with a limited-control proof of concept and a built ProofSync portal, while the funded work creates the reusable Canton integration layer, lifecycle handling, portable decisions and proof, independent verifier, one primary SDK and interfaces, Canton-specific ProofSync/AuditSync/RegSync/DevSync integration, the two approved references, the bounded agentic extension, security review with remediation, accepted production deployment, ecosystem adoption support, and six complete post-launch maintenance months. Licensing, deployment, and reuse remain subject to the proposal's stated distribution terms, authorization boundaries, and verified production prerequisites. $385,000 USD total; approximately nine months through accepted production launch plus six complete post-launch maintenance and adoption months.
Specification
1. Objective
The objective is to solve a structural gap between institutional assurance and the financial workflows it supports. Today, requirements, controls, evidence, and determinations are often managed through manual, fragmented, periodic, and document-driven processes that must be reconstructed for different stakeholders. As financial activity becomes more digital, tokenized, programmable, interconnected, and automated, that repeated reconstruction can leave institutions without a current basis for consequential actions when conditions change.
The intended end state is continuously maintained operational assurance rather than a static point-in-time report. Current assurance should change when evidence expires, conditions drift, authority or approvals change, controls or requirements change, or remediation produces new evidence. Historical determinations must retain their original meaning, but consumers need a clear distinction between historical proof and what is currently supported for a proposed action at the point of use.
CompliLedger's operating model begins with requirements, target, context, and operational state; determines applicability and applicable controls; identifies evidence needs; orchestrates authorized evidence collection and validation; assesses sufficiency; and then produces deterministic evaluations and decisions. AI may assist interpretation, orchestration, and contextual analysis, but consequential determinations remain grounded in machine-readable rules and versioned deterministic inputs. Insufficient, stale, conflicting, or incomplete evidence must result in explicit limitations rather than unsupported satisfaction.
For Canton, the goal is reusable authorized assurance within institutional multi-party workflows, with privacy-aware consumption, lifecycle-aware freshness, and independent verification of supported properties. Authorized consumers should be able to receive relevant current decisions, proof, and lifecycle state without broad disclosure of protected underlying evidence, while recognizing that verification, freshness, and reuse remain bounded by supported evidence, authorization, context, versions, and defined processing limits. Governed agentic actions are a bounded reuse case within that same infrastructure, not a third full reference or the primary objective.
CompliLedger already exists as a functioning platform, with a limited-control proof of concept and built ProofSync capabilities; the funded objective is the reusable Canton integration and ecosystem layer that makes those assurance capabilities consumable within Canton. The grant does not fund the invention of CompliLedger, the rebuild of the entire private commercial platform, or an implied existing production deployment. Subject to the proposal's licensing and distribution terms, supported interfaces, and verified deployment prerequisites, success means the shared Canton layer can be integrated and consumed without bespoke employee assistance for the supported path.
2. Implementation Mechanics
Implementation principle: CompliLedger performs requirements interpretation, applicability, evidence orchestration, sufficiency assessment, deterministic evaluation, decisioning, and continuous reassessment. The Canton integration makes the resulting authorized assurance, decisions, lifecycle state, and proof reusable within institutional multi-party workflows.
flowchart LR
R[Requirements] --> TC[Target + Context]
TC --> A[Applicability]
A --> AC[Applicable Controls]
AC --> E[Evidence]
E --> ES[Evidence Sufficiency]
ES --> DE[Deterministic Evaluation]
DE --> D[Decision]
D --> PDP[Portable Decision Package]
PDP --> CPP[Canonical Proof Package]
CPP --> CC[Canton Consumption]
CC --> IV[Independent Verification]
IV --> CA[Continuous Assurance]
CA -. Material Change .-> E
This is a conceptual flow, not a mandatory execution order: verification can gate consumption, continuous reassessment does not wait for consumer verification, operational state informs applicability, and requirement, control, context, or authority changes may revisit earlier stages.
Markdown fallback: Requirements → Target + Context → Applicability → Applicable Controls → Evidence → Evidence Sufficiency → Deterministic Evaluation → Decision → Portable Decision Package → Canonical Proof Package → Canton Consumption → Independent Verification → Continuous Assurance, with material change looping back to evidence.
2.1 Implementation Boundary
The implementation separates CompliLedger's intelligence and deterministic reasoning from the reusable Canton integration. The existing platform is responsible for requirements interpretation, applicability and control determination, evidence requirement mapping, authorized evidence orchestration and collection, validation, normalization, sufficiency assessment, deterministic evaluation, assessments, decisions, continuous reassessment, and proof generation capabilities. A limited-control proof of concept exists and ProofSync is built; this does not establish that every mature capability is production-hardened or implemented on Canton. An initial readiness inventory will identify available interfaces, supported outputs, and prerequisites. General commercial-platform prerequisites remain CompliLedger's responsibility; additional work specifically required for the shared Canton layer will undergo explicit scope review.
The funded layer will implement Canton/DAML integration components, assurance and package representations, proof commitments, lifecycle/version state, privacy and authorization patterns, request/result interfaces, governed consumption, independent verification, developer interfaces, portal integration, references, and operational tooling. Exact component boundaries are subject to Canton-native design; a conceptual capability need not become a separate service or contract. The private reasoning implementation is not automatically open-sourced, and Canton is not treated merely as a hash-anchoring service.
2.2 End-to-End Assurance Workflow
A request identifies requirements, target, context, and relevant operational state. Applicability determination selects the applicable control set and evidence requirements. AI-assisted orchestration locates authorized sources and collects evidence; validation and normalization produce a Canonical Evidence Package. Sufficiency assessment determines whether that package supports deterministic control evaluation. Evaluation produces an assessment and a decision addressing the requested question, with explicit limitations where the evidence cannot support a determination.
The decision is packaged for authorized downstream consumption as a Portable Decision Package and represented in a Canonical Proof Package. The Canton layer publishes or associates the appropriate assurance/proof representation, enabling supported independent verification and workflow consumption. Relevant changes return the process to evidence refresh and reassessment, including renewed applicability evaluation when needed. Versioned request/result interfaces will correlate these stages, expose processing errors separately from assurance outcomes, and support idempotent submission, event handling, replay, reconciliation, and recovery without treating an interrupted request as successful assurance.
2.3 Requirements and Applicability
The integration will not hard-code a single regulatory regime or asset class. Requirements may originate from regulation or guidance, internal policy and governance, contracts, industry standards, security and operational requirements, or asset and counterparty conditions. CompliLedger evaluates each requirement against the target, context, relevant jurisdiction, operating model, activity, and current operational state. The output identifies the applicable controls and corresponding evidence requirements, preserving relevant versions and applicability context. This permits reuse across institutional workflow classes without assuming that every requirement applies to every participant or target.
2.4 AI-Assisted Evidence Orchestration
AI may assist with interpreting and decomposing requirements, identifying evidence needs, locating appropriate sources, selecting authorized connectors, structuring information, contextual analysis, and explanation. Evidence may come from authorized enterprise systems and APIs, identity platforms, infrastructure/cloud systems, financial and custody systems, security and governance platforms, blockchain networks, and other authoritative sources. Connector use remains bounded by granted access; AI assistance does not confer authority to access a source or override evaluation rules. Sensitive source evidence remains in appropriate protected systems unless an explicitly authorized workflow requires otherwise, rather than being broadly published to Canton.
2.5 Evidence Validation, Normalization, and Sufficiency
Collected evidence is not immediately treated as proof. Validation checks source provenance and relevant authenticity, freshness, and completeness properties; normalization transforms supported evidence into a stable Canonical Evidence Package while retaining source references and transformation lineage. Sufficiency is then evaluated against the applicable evidence requirements, separately from whether a control is satisfied.
Evidence results must distinguish sufficient, partial, insufficient, stale, conflicting, and manual-review-required conditions. These findings constrain the subsequent determination: absent or inadequate support cannot become a satisfied control merely because collection completed. The package will carry the evidence state, relevant observation times, and versions required for repeatable evaluation, without implying that normalization establishes the truth of every source assertion.
2.6 Deterministic Control Evaluation and Decisions
Applicable machine-readable controls execute against validated evidence under versioned evaluation rules. AI does not independently decide that a regulated or governed condition is satisfied. Reproducibility applies to assessment and decision results for identical deterministic inputs, evidence state, and rule versions; run-specific timestamps and correlation identifiers will be distinguished from deterministic result content.
Assessments will preserve relevant requirement/control identifiers and versions, evidence references, reason codes, status, target/context references, timestamps, and correlation/provenance information. Decisions answer concrete questions: whether a control is satisfied, evidence is sufficient, an action is permitted, additional approval is required, or assurance remains current. Governed execution may use APPROVED, DENIED, or REQUIRE_APPROVAL; other assurance questions may require different structured outcomes. A decision will retain its scope and limitations rather than assert general compliance.
2.7 Portable Decision Package
The Portable Decision Package bridges reasoning and downstream consumption without requiring unrestricted access to the private reasoning system. Its versioned specification will define the supported decision identifier, target, action or purpose, outcome/status, reason codes, applicable requirement/control references and versions, evidence references or commitments, decision timestamp, validity/freshness conditions, relevant authorization context, provenance, successor relationships, and verification metadata. These are design inputs, not a prematurely fixed schema.
Authorized compatible workflows can consume the package without unnecessarily repeating the complete reasoning process. Consumption remains subject to applicability, authorization, context, freshness, purpose, and permitted reuse; possession of a valid package alone does not establish permission to execute an action.
2.8 Canonical Proof Package
The Canonical Proof Package represents the machine-verifiable output of the assurance process. Its specification will define how a decision package or its commitment relates to relevant evidence commitments/references, assessment information, requirement/control versions, provenance, timestamps, and lifecycle information. Canonical encoding and deterministic commitment rules will identify exactly which content is protected; associated verification metadata will specify the supported checks. The design must avoid an ambiguous or self-referential hashing definition.
The precise Canton-native representation will be established during architecture work. A package's recorded lifecycle context will be distinguished from subsequent lifecycle changes. Sensitive evidence need not accompany a package onto Canton, and a matching hash establishes integrity of the committed content, not the truth or continued applicability of the underlying assessment.
2.9 Canton-Native Assurance Representation
The funded design will determine the appropriate division between protected information and Canton-consumable state. Raw sensitive evidence, proprietary control logic, confidential enterprise information, credentials/secrets, and unrestricted reasoning details remain in protected systems. Subject to final Canton-native design, authorized assurance state, decision/package representations or references, proof commitments, versions, validity information, provenance references, and workflow-consumption state may be made available through the Canton integration where appropriate.
Canton/DAML components will implement the selected state and workflow patterns rather than simply publish public hashes. The design will specify which parties may issue, consume, update, or inspect relevant information, and how off-ledger packages remain associated with their authorized Canton records. Disclosure of references and metadata will also be considered in the privacy model. No universal public state access or exact DAML contract structure is assumed. Persistence, history access, and lifecycle/version handling will be validated against the selected supported Canton interfaces before production commitments are finalized.
2.10 Continuous Assurance and Reassessment
Continuous assurance will be implemented as a shared lifecycle capability. Material triggers may include evidence expiry or freshness thresholds, operational/configuration changes, requirement/control changes, identity or authority changes, governance changes, security findings, risk changes, and relevant Canton workflow/state events. Event-driven processing and scheduled checks, where appropriate, will initiate evidence refresh or new collection, reassess applicability when necessary, reevaluate controls, and produce updated decisions and assurance/proof state.
Remediation may trigger new evidence and further reassessment, restoring assurance or recording a different supported outcome. Earlier packages retain their historical meaning rather than being silently rewritten. Successor/version relationships and authorized lifecycle queries or events will distinguish current, superseded, stale, expired, insufficient, revoked/suspended where applicable, and otherwise changed assurance. Failure to obtain a current state must be reported as a limitation, not silently replaced with an older favorable result. Replay/recovery and reconciliation tests will address interrupted updates and duplicate events. Freshness and reassessment latency thresholds will be established for defined operating conditions and measured later; no undefined real-time guarantee is assumed.
2.11 Governed Canton Workflow Consumption
Reusable consumption patterns will support issuance, transfer, settlement, redemption, asset/counterparty eligibility, custody conditions, governance approvals, operational requirements, and human approval where appropriate. Advisory consumption retrieves current assurance to inform a workflow decision. Execution-gated consumption permits a consequential action only when the required current decision and assurance state satisfy the declared policy. Applications are not required to adopt execution gating universally.
Where appropriate, consumption will be bound to the target, intended action/purpose, authorized actor, applicable versions, freshness/validity conditions, and permitted reuse. The implementation will define how those conditions are checked at the point of use and how pending approval, unavailable assurance, or changed conditions affect execution. This addresses stale or misapplied decisions without assuming a particular atomic enforcement mechanism before the Canton design is validated. Reusable components and examples will cover these patterns, not bespoke integrations for every workflow class.
2.12 Governed Agentic Financial Workflows
The same consumption architecture will support a bounded agentic extension. A proposed consequential action is evaluated against identity, authority, permissions, bounded delegation, target, intent, applicable requirements, evidence, limits, and approval conditions. Governed outcomes may be APPROVED, DENIED, or REQUIRE_APPROVAL. Where human authorization is required, execution must wait for appropriately authorized approval; an approval cannot substitute for missing authority or override unrelated policy conditions.
Agent-to-agent delegation will be checked against the delegating authority, delegated scope, receiving-agent permissions, applicable time/transaction limits, and revocation state. Following authorized execution, the integration will capture the attempted action, authority context, decision, approval lineage, execution outcome, action-integrity result, resulting assurance state, and proof. Action-integrity validation compares the supported execution evidence with the approved action; unavailable confirmation must remain distinguishable from verified execution. This is an extension of CompliLedger's shared governance infrastructure, not a standalone autonomous-finance product.
2.13 Three-Level Independent Verification
The verifier will expose three distinct levels and identify which properties were checked, failed, or could not be verified:
- Level 1 — Package Integrity: Validate supported canonical structure and encoding, recompute the deterministic commitment/hash, and detect tampering. Successful integrity verification does not prove that all original evidence was true.
- Level 2 — Provenance and Canton State: Where authorized and technically supported, verify authorized origin, the relevant Canton record/state, lifecycle state, versions, timestamps, and provenance. This requires a supported access path and does not assume universal public Canton access or reproduce the underlying assessment.
- Level 3 — Assessment Reproduction Where Supported: For disclosed deterministic controls and authorized evidence or reference fixtures, rerun the assessment and compare the reproduced result with the recorded assessment/decision represented by the proof. Reproduction is not available where required rules, evidence, or access are missing.
Missing prerequisites must produce an explicit limitation rather than unconditional verification success. Trust assumptions will identify the sources and authorizations on which each check depends. A standalone library, CLI or equivalent, and verification API will support use without ProofSync or another proprietary portal. Valid, tampered, malformed, and unavailable-data fixtures will document and test these behaviors.
2.14 Stakeholder Consumption
All four portals consume the same underlying CompliLedger assurance infrastructure according to role and authorization; the grant funds their Canton-specific integration, not unrelated portal reconstruction:
- ProofSync: Client-facing live assurance and proof visibility, including authorized control/evidence status, decisions, proof lifecycle, verification, assurance changes, and history/lineage. It does not perform applicability evaluation, evidence orchestration, deterministic reasoning, or proof generation.
- AuditSync: Governed auditor access to authorized assessments, evidence lineage, decisions, proof, verification, assurance history, and audit-ready artifacts.
- RegSync: Governed regulator access to relevant assurance, decisions, proof, verification, and lineage/history within privacy and disclosure boundaries.
- DevSync: Developer access to APIs, SDK, schemas, documentation, reference implementations, proof consumption, and verification integration.
Shared query/event interfaces and permission mapping will keep stakeholder views associated with the relevant assurance versions and lifecycle updates. Portal or export access will not imply unrestricted evidence access. Missing general commercial portal prerequisites will be identified separately from funded Canton-specific work.
2.15 Developer and Reusability Model
Subject to final licensing and distribution terms, the reusable layer will provide Canton/DAML integration components, package specifications, schemas, lifecycle/provenance structures, authorization patterns, one primary SDK, APIs, the verifier, conformance tests, synthetic fixtures, reference workflows, and developer documentation. The primary SDK technology and supported Canton/API/DAML versions remain subject to technical validation; multiple SDK languages are not included.
Quickstarts, authentication examples, sample integrations, lifecycle/error handling, event interfaces where appropriate, and release/version guidance will support clean-environment integration. An authorized third-party developer should be able to consume supported packages, verify supported properties, and follow lifecycle updates without bespoke CompliLedger employee assistance. Dependencies on credentials, protected evidence, or commercial reasoning services will be documented. Reusable integration artifacts do not imply free access to proprietary services, release of private reasoning code, or unrestricted disclosure of customer data.
2.16 Reference Implementations
Institutional Continuous Assurance will demonstrate State A: current/satisfied assurance; a material operational or evidence change leading to refreshed evidence and reassessment; State B: changed, stale, insufficient, or not-satisfied assurance; and remediation with new evidence and reassessment leading to State C: restored or otherwise updated assurance. The reference will use the shared decision, proof, lifecycle, verification, SDK, and portal infrastructure so authorized consumers can observe the change. Project Atlas may inform this internal validation approach but is not an external customer or Canton adopter.
Tokenized RWA / Settlement will use the same infrastructure in a bounded privacy-preserving multi-party workflow, testing freshness, authorization, governed consumption, and multi-party verification. Assets, parties, requirements, and evidence will be synthetic unless an external integration is separately approved. The reference does not assert legal or regulatory compliance. The bounded agentic scenario adds approved, denied, and approval-required actions, authorized human approval, agent-to-agent delegation, attempted authority/delegation violation, action-integrity checks, and verifiable execution lineage. It is an additional reuse demonstration, not a third full reference implementation. Shared dependency manifests and tests will distinguish common infrastructure from workflow-specific configuration and adapters.
2.17 Security and Operational Approach
Productionization will include threat modeling, external Canton/DAML and security review, privacy/authorization testing, adversarial testing, API security review, remediation, and retesting. Review will cover the reusable Canton layer and relevant integration boundaries, not an unlimited audit of every private CompliLedger capability. It will address protected data, tenant isolation where applicable, least privilege, secrets/key management, proof integrity, stale/replayed decisions, and unauthorized workflow consumption.
Reproducible builds and automated tests will support performance and lifecycle-scale testing, multi-party validation, failure/recovery exercises, and supported upgrade testing. Deployment automation, monitoring, a compatibility matrix, runbooks, and incident/recovery procedures will support operational handover. Final review and retesting must cover the integrated release and material subsequent changes. Security severity policies, performance thresholds, and supported compatibility obligations remain to be approved rather than inferred here. External developer exercises and independent verification will test the documented integration path and feed corrections into the release and onboarding guidance.
2.18 Deployment and Maintenance Approach
Deployment will progress from local development/testing to shared Canton development/test environments where applicable, then production using the verified and approved topology. Architecture work will establish applicable hosting, participant, onboarding, sponsorship, allowlisting, access, and operating requirements from authoritative sources. No final topology, network access, or unconditional production date is assumed. Production release will follow security remediation, readiness validation, deployment checks, and operational handover under that approved architecture.
After accepted production launch, six complete months of bounded maintenance and adoption support will cover corrective fixes, security updates, compatibility updates within the supported policy, SDK/documentation upkeep, issue triage, developer/integration support, reference maintenance, and adoption measurement. The period is not consumed by implementation delays and does not imply a 24/7 SLA, unlimited managed services, bespoke integrations, broad new connectors, new regulatory frameworks, or major architectural expansion. Support capacity, response policy, operating ownership, and adoption targets will be agreed separately; release records, support/issue logs, integration feedback, and adoption reporting will document the work delivered.
3. Architectural Alignment
Why Canton
- Privacy: Protected evidence can remain in authorized systems while authorized assurance and proof are consumed where needed.
- Multi-party workflows: Institutional participants can consume authorized decisions and assurance inside coordinated workflows.
- Composability: The same reusable patterns can support multiple workflow classes without separate assurance architectures.
- Lifecycle: Canton applications can consume current assurance instead of relying indefinitely on historical proof.
3.1 Application-Layer Role
CompliLedger is proposed as application-layer assurance and proof infrastructure for Canton, not a change to the Canton protocol or a replacement for synchronizers, participant nodes, token standards, identity providers, custodians, systems of record, auditors, or regulators. Canton coordinates multi-party workflows; the shared CompliLedger layer will make applicable assurance conditions available as deterministic decisions, Portable Decision Packages, Canonical Proof Packages, lifecycle state, and supported independent verification. This contributes a reusable application implementation rather than asserting that Canton has a protocol-level assurance deficiency.
3.2 Fit with Institutional Multi-Party Architecture
Canton's multi-party application model combines privacy and authorization with workflow coordination and application composability. These characteristics fit assurance exchanges in which parties collaborate around a financial action but retain distinct information-access rights. CompliLedger's deterministic decisions are intended to inform or govern those coordinated workflows, while selective sharing allows relevant assurance to be consumed without requiring every participant to receive the same underlying information. The specific mapping to supported Canton interfaces and synchronized workflows will be verified during technical design; no particular disclosure or synchronization mechanism is presumed here. Canton is a suitable institutional environment for this architecture, not the only technically possible one.
3.3 Privacy-Preserving Assurance
Proof portability does not require evidence publicity. Enterprise, identity, financial, custody, and security systems, protected CompliLedger storage, and other authoritative sources may retain sensitive evidence while authorized consumers receive the decision, proof, provenance, and lifecycle information appropriate to their purpose. The intended stakeholder views are:
- Participant/client: Current operational assurance and proof through ProofSync.
- Auditor: Authorized assessments, evidence lineage, decisions, proof, and history through AuditSync.
- Regulator: Governed assurance, decision, verification, and permitted lineage access through RegSync.
- Developer/application: Authorized SDK/API consumption and verification integration through DevSync and the shared interfaces.
These are differentiated views of the same assurance infrastructure, not separate determinations or an assumption of universal access. Exact Canton disclosure patterns remain subject to verification, including the confidentiality of package references and provenance metadata.
3.4 Lifecycle-Aware Assurance
Programmable financial workflows need to distinguish a historical determination from assurance that remains applicable at the point of use. The proposed shared layer will maintain current assurance through material change, reassessment, updated decisions, and updated assurance/proof state, preserving historical lineage rather than attaching a static attestation indefinitely to an asset or transaction. Potentially changing conditions include asset or counterparty eligibility, governance approval, operational or custody conditions, applicable reserve-related conditions, security controls, authority/delegation, and settlement readiness. Canton applications can therefore be designed to consume current assurance and its limitations, not simply verify that a historical proof exists. This is an application-layer lifecycle capability, not a claim that network coordination establishes the truth of external evidence.
3.5 Composability Across Workflow Classes
The same decision-consumption, lifecycle, freshness, authorization, proof-verification, and human-approval patterns are intended to support multiple application classes without a separate assurance architecture for each. Potential consumers include issuance, transfer, settlement, redemption, tokenized RWA and money, custody, collateral, governance, institutional controls, and governed automated execution. These are architectural reuse opportunities, not commitments to production integrations across every category. The funded demonstrations remain the two approved institutional references and bounded agentic extension. Reuse must preserve applicability, version, purpose, freshness, authorization, and stakeholder requirements; composability does not make a determination universally acceptable.
3.6 Shared Canton Ecosystem Infrastructure
Subject to final licensing and distribution decisions, the ecosystem layer will provide reusable Canton/DAML components, Portable Decision Package and Canonical Proof Package specifications, assurance/lifecycle/provenance schemas, authorization patterns, APIs, one primary SDK, an independent verifier, conformance tests, synthetic fixtures, reference workflows, developer documentation, and deployment/integration guidance. These shared artifacts distinguish the project from a private connection usable only by CompliLedger.
An authorized third-party Canton developer should be able to integrate supported components, consume supported packages, independently verify supported properties, and follow lifecycle updates without bespoke CompliLedger employee assistance or a proprietary portal. This independence applies to the shared integration and supported verification functions; it does not imply that the entire private reasoning platform becomes open source or that commercial services are available without agreed access terms.
3.7 Participant Integration Value
Applications needing assurance may otherwise separately implement applicability consumption, evidence-state interfaces, deterministic decision consumption, lifecycle/freshness handling, proof packaging, verification, stakeholder access, and developer integration. The shared layer is intended to reduce this duplicated integration effort without assuming that every Canton participant currently builds all of these functions. It connects reusable interfaces to CompliLedger's AI-assisted evidence and deterministic reasoning capabilities rather than requiring participants to reconstruct an equivalent platform.
The intended operational shift is from manual and periodic assurance assembly toward AI-native continuous evaluation, from point-in-time reports toward real-time or near-real-time updates within defined and measured operating conditions, and from repeated audit preparation toward maintained audit-ready information. Machine-verifiable proof and reusable decisions support that process; they do not replace continuous operational assurance. No cost-saving percentage, response-time guarantee, or automatic stakeholder acceptance is assumed.
3.8 Institutional Tokenization and External Conditions
The proposed architecture fits institutional tokenization and asset-mobility use cases, including tokenized real-world assets and money, settlement, custody, collateral, asset servicing, and regulated financial applications. For a given workflow, relevant conditions may include organizational authority, approvals, asset eligibility, contractual obligations, governance, operational state, and evidence held in enterprise systems rather than on the ledger. CompliLedger's role is to translate applicable conditions into deterministic, lifecycle-aware, independently verifiable assurance that an authorized Canton application can consume. It does not replace asset records, custody responsibilities, or legal determinations, and it makes no claim about specific customers, market share, or regulatory compliance.
3.9 Bounded Governance for Emerging Agentic Finance
Automated and agentic financial workflows are a future-facing reuse case for the same assurance layer. Autonomous execution does not imply unrestricted authority: identity and authority context, bounded delegation, applicable requirements, action/transaction limits, and human-approval conditions can define a governance boundary before execution. Action-integrity checks, execution lineage, and machine-verifiable governance proof can make the resulting activity inspectable afterward. The funded extension remains bounded and secondary to institutional continuous assurance; it is not a separate product or a claimed Canton Foundation priority. Specific ecosystem experimentation and project relationships are reserved for later verification before any named examples are included.
3.10 Complementing Existing Canton Infrastructure
The proposal is intended to complement existing work across protocol infrastructure, token/asset standards, developer tooling, application infrastructure, and financial workflow composability. Protocol and token infrastructure define how supported assets and workflows operate; CompliLedger adds application-layer assurance about applicable conditions that those workflows may consume. Its package specifications, verifier, and integration interfaces are intended to work with supported ecosystem surfaces rather than establish competing token standards or replace participant infrastructure. Specific compatibility and funded-project relationships will require verification; none is presumed by this architectural positioning.
3.11 CIP Alignment — Pending Verification
Drafting note — CIP alignment: Relevant Canton Improvement Proposals governing token interfaces, application integration, wallet/dApp interaction, authorization, or other applicable integration surfaces will be mapped during the dedicated technical verification pass before submission. The mapping will distinguish required dependencies from optional interoperability opportunities and record verified identifiers, status, and applicability to the selected design. No CIP number, implementation dependency, or conformance claim is asserted at this stage.
3.12 Architectural Outcome
The intended result is a reusable assurance layer through which authorized Canton applications can consume continuously maintained deterministic decisions and independently verifiable proof alongside financial workflows. Sensitive evidence need not be broadly disclosed, each application need not build an equivalent assurance architecture, and stakeholders need not rely solely on static reports or proprietary portals for supported verification. Canton provides the workflow environment; CompliLedger makes the assurance supporting those workflows continuously evaluable, portable, and independently verifiable within explicit privacy, applicability, and authorization boundaries.
4. Backward Compatibility
The proposed CompliLedger Canton integration is additive and opt-in. It introduces reusable application-layer components, interfaces, schemas, one primary SDK, verification tooling, and optional assurance-consumption patterns; it is not intended to require changes to existing Canton protocol behavior. The proposal does not require replacing synchronizers, participant nodes, token standards, identity providers, custodians, or systems of record. This position does not imply that adoption has no deployment or integration dependencies.
Applications may choose to consume current assurance, deterministic decisions, Portable Decision Packages, Canonical Proof Packages, verification results, and lifecycle updates, or adopt governed or execution-gated workflows. Adopters may need supported SDK/API integration, authorization configuration, decision/proof consumption, lifecycle and freshness handling, verification, and upgrade handling. Execution gating may deliberately change an adopting application's behavior under its declared policy; it is not imposed on applications that do not adopt it. Canton-specific ProofSync, AuditSync, RegSync, and DevSync integration will likewise be designed as additions to the existing portals, not replacements for unrelated portal foundations.
The funded layer will use explicit versioning for schemas, decision and proof packages, APIs, the SDK, DAML packages/components where applicable, and lifecycle/event structures. Documented compatibility rules will allow consumers to identify the format and semantics they support rather than silently interpret an unfamiliar version. Previously issued decisions and proof packages must retain their historical meaning. New assessments and lifecycle changes will use explicit successor or superseded relationships, preserving auditability and verification while distinguishing historical results from current assurance.
Productionization will include compatibility and upgrade testing, supported-version documentation, migration guidance where necessary, regression testing of both reference workflows, and validation of lifecycle behavior across supported upgrades. The compatibility policy will describe supported combinations and any required consumer migration rather than promise compatibility with every past or future version. Exact requirements depend on the selected Canton/DAML/API versions, package design, deployment topology, integration surfaces, and supported upgrade policy; these will be established during funded architecture work and validated before production acceptance. No particular Canton upgrade mechanism or unconditional compatibility guarantee is assumed.
No mandatory backward compatibility impact is expected for Canton applications that do not adopt the CompliLedger integration: they should not need to change their workflows solely because the infrastructure exists. Applications that opt in will follow the versioned integration interfaces and upgrade requirements defined and tested by the funded implementation.
Milestones and Deliverables
What the Canton Ecosystem Receives
| Foundation | Developer Infrastructure | Institutional Workflows | Production |
|---|
| Canton/DAML integration | One primary SDK + APIs | Institutional Continuous Assurance reference | Independent security review |
| Decision/proof specifications | Schemas | Tokenized RWA / Settlement reference | Remediation & retesting |
| Continuous assurance lifecycle | Independent verifier | Governed workflow patterns | Production readiness |
| Privacy/authorization patterns | Conformance tests | Bounded agentic governance | Accepted production deployment |
| Version/provenance model | Developer documentation | Authorized stakeholder consumption | 6 complete months bounded support/adoption |
The grant funds the reusable Canton layer that makes CompliLedger assurance consumable within Canton; it does not fund the invention of CompliLedger or the entire private commercial platform. Subject to final licensing and distribution terms, supported interfaces, authorization boundaries, and the verified deployment architecture, the funded output is reusable ecosystem infrastructure rather than a private one-off integration.
Potential Canton Use Cases
| Potential Canton Use Case | Qualified assurance question |
|---|
| Tokenized RWA | Is the asset or participant currently eligible for the proposed action? |
| Settlement | Are the required current conditions satisfied before settlement? |
| Stablecoins / Tokenized Money | Are the applicable issuance, reserve, redemption, governance, and operational conditions satisfied? |
| Custody | Are the required authorization, operational, and custody conditions current? |
| Banking Controls | Are the required controls satisfied on current evidence? |
| Governance Approvals | Has the required authorized approval occurred and does it remain valid? |
| AI-Agent Transactions | Are the required authority, conditions, and human approvals satisfied? |
These are conditional use cases only, dependent on applicable requirements, supported controls and evidence, authorized integration, and stated processing limits. The only funded full references are Institutional Continuous Assurance and Tokenized RWA / Settlement; the bounded agentic governance scenario remains a reuse demonstration, not a third full reference.
Program Roadmap
| Milestone | Focus | Estimated Delivery | USD Reference Allocation |
|---|
| M1 | Canton-Native Foundation | Month 2 | $40,000 |
| M2 | Continuous Assurance Integration | Month 4 | $63,500 |
| M3 | Portable Decisions & Verification | Month 5 | $28,000 |
| M4 | Developer Platform & Portals | Month 6 | $58,000 |
| M5 | Reference Workflows & Governance | Month 7 | $70,500 |
| M6 | Security & Production Deployment | Month 9 | $84,000 |
| M7 | Maintenance & Adoption | Six complete months after accepted production | $41,000 |
| Total | | | $385,000 |
These dates are estimates, not guaranteed acceptance dates. Production remains subject to verified prerequisites, any delay preserves the full six-month maintenance period rather than shortening it, and the USD figures are reference allocations only—they do not change the proposal's denomination, payment mechanics, or fixed-Canton-Coin methodology.
Development periods overlap; acceptance dependencies remain sequential: M1 → M2 → M3 → M4 → M5 → M6 → M7. Work may proceed in parallel and is not required to wait for the preceding milestone payment. Acceptance depends on completed deliverables and reproducible evidence, not elapsed time. Each submission will identify the evaluated revision, artifacts, environment, and mandatory test results. Unresolved technical prerequisites and policies must be recorded and approved before the affected acceptance gate; thresholds and adoption targets must not be selected retrospectively.
Milestone 1: Canton-Native Foundation
- Estimated Delivery: Months 1–2.
- Focus: Establish the reusable Canton-native architecture, executable foundation, readiness baseline, and technical dependencies.
- Deliverables / Value Metrics:
- Readiness inventory distinguishing existing CompliLedger capabilities, commercial prerequisites, and Canton-funded work; approved scope boundaries mapped to traceable deliverables, with blocking prerequisites identified and assigned in a technical dependency register.
- Canton/DAML architecture and initial reusable integration components covering assurance state, deterministic decision representation where appropriate, Portable Decision Package and Canonical Proof Package representations, request/result interfaces, and lifecycle/version models.
- Privacy/visibility and authorization models, protected/off-ledger evidence boundary, architecture decision records, and initial threat model.
- CI/build/test foundation, documented clean-environment setup, initial automated tests, and conformance fixtures covering valid inputs, deliberately invalid inputs, and positive/negative authorization cases.
- Deployment/onboarding investigation recording evidence for verified assumptions and explicitly identifying unresolved dependencies. Final production topology selection is not required at this milestone.
- Ecosystem value: A reusable, executable integration foundation and explicit dependency baseline reduce duplicated Canton assurance architecture work.
- Gate metric: All mandatory foundation/conformance and authorization tests pass; valid fixtures are accepted and deliberately invalid fixtures rejected; a clean supported environment reproduces build/test results; scope traceability and prerequisite ownership are recorded; deployment assumptions are verified or marked unresolved.
Milestone 2: Continuous Assurance and Deterministic Integration
- Estimated Delivery: Months 2–4.
- Focus: Integrate existing CompliLedger reasoning with the Canton layer and demonstrate changing assurance as conditions change.
- Deliverables / Value Metrics:
- Requirements/target/context integration exposing applicability, applicable controls, evidence requirements/state and sufficiency, deterministic assessments and decisions, and Canton request/result processing.
- Lifecycle synchronization covering evidence freshness/expiry, material-change triggers, reassessment, successor/version lineage, stale/superseded handling, and remediation/retest; event-driven and scheduled reassessment where appropriate.
- Idempotency, replay/recovery, reconciliation, and a runnable continuous-assurance integration harness.
- Reproducible lifecycle demonstration: State A — current evidence supports the applicable control, producing a deterministic decision and current assurance; material change/expiry — evidence refresh or insufficiency detection triggers reassessment and State B, reflecting changed, stale, insufficient, or not-satisfied assurance; remediation — new evidence and reassessment produce State C, restored or otherwise updated assurance. Preserve historical/successor lineage and distinguish current from superseded/expired assurance for consumers.
- Negative cases showing that stale, insufficient, conflicting, or manual-review-required evidence does not become unsupported satisfaction; determinism cases showing identical deterministic inputs and rule versions reproduce deterministic result content, distinguished from run-specific metadata.
- Duplicate/replayed-event tests showing no contradictory current state, interrupted-processing tests demonstrating recovery to consistent state, and measurements of reassessment latency and synchronization lag under a documented workload. Final performance thresholds remain subject to approval before the applicable performance acceptance test.
- Ecosystem value: Shared assurance changes with operational conditions rather than remaining a static proof or periodic report.
- Gate metric: All mandatory lifecycle, sufficiency, determinism, idempotency, and recovery cases pass, with reproducible State A → State B → State C evidence and documented latency/lag measurements.
Milestone 3: Portable Decisions, Proof Infrastructure, and Independent Verification
- Estimated Delivery: Months 3–5.
- Focus: Deliver portable decisions, machine-verifiable proof, and independent verification without dependence on a proprietary portal.
- Deliverables / Value Metrics:
- Portable Decision Package and Canonical Proof Package implementations, canonical encoding, deterministic commitment/hash specification, Canton-native assurance/proof association, and lifecycle/provenance/version references.
- Independent verifier library, standalone CLI or equivalent, verification API, and verification documentation describing trust assumptions and limitation/error semantics.
- Level 1 — Package Integrity: Validate supported structure, canonical encoding, and commitment/hash; detect tampering and reject malformed packages. Integrity success must not be represented as proof of underlying evidence truth.
- Level 2 — Authorized Provenance and Canton State: Demonstrate the supported authorized Canton-state access path and supported origin, association/state, lifecycle, version, timestamp, and provenance checks.
- Level 3 — Assessment Reproduction Where Supported: Rerun selected disclosed deterministic reference assessments using authorized evidence/reference fixtures, reproduce deterministic results, and compare them with recorded decisions/proof.
- Valid, tampered, malformed, stale, and unavailable-data fixtures. Unsupported properties or unavailable rules, evidence, state, or authorization produce explicit limitations rather than unconditional success.
- Clean-environment verifier execution without ProofSync or another proprietary portal.
- Ecosystem value: Authorized ecosystem participants can independently verify supported package properties and disclosed assessments.
- Gate metric: All mandatory verification vectors pass; every result identifies the verification level, applicable versions, properties verified or failed, and unavailable/unsupported properties. All three supported levels and portal-independent execution have reproducible evidence.
Milestone 4: Developer Platform and Stakeholder Portals
- Estimated Delivery: Months 4–6.
- Focus: Make the reusable Canton assurance infrastructure consumable by external developers and authorized stakeholders.
- Deliverables / Value Metrics:
- One primary SDK, APIs, schemas, appropriate DAML bindings/components, authentication integration, decision/package consumption, independent verification integration, lifecycle/error handling, and an event/streaming interface where appropriate. SDK language and supported technical baseline will be established through verified technical decisions.
- Quickstart, runnable sample integration, supported-environment instructions, release/version guidance, and developer documentation.
- ProofSync: Canton-specific current assurance, decision, proof, verification, lifecycle, and history consumption.
- AuditSync: Governed assessment, evidence-lineage, decision, proof, verification, and audit-oriented access.
- RegSync: Authorized assurance, decision, proof, verification, and permitted lineage access.
- DevSync: SDK/API/schema/documentation/reference access.
- Portal work is limited to Canton-specific integration with the shared assurance infrastructure, not rebuilding portal foundations or attributing reasoning/proof generation to portals. Positive and negative authorization tests cover appropriate stakeholder paths.
- A non-author evaluator completes documented setup, authentication, supported decision/package consumption, independent verification, and lifecycle-update processing from a clean supported environment without bespoke code changes, undocumented steps, or bespoke live employee assistance. Standard documented credential provisioning is permitted. Required interventions are recorded, corrected in tooling/documentation where applicable, and affected validation rerun.
- Ecosystem value: Developers can integrate the shared infrastructure reproducibly, while stakeholders consume role-appropriate assurance.
- Gate metric: All mandatory SDK/interface/lifecycle/error/authorization tests pass; all four portal integrations have reproducible functional evidence; the non-author clean-environment journey succeeds through documented steps.
Milestone 5: Reference Workflows and Reusable Governance
- Estimated Delivery: Months 5–7.
- Focus: Demonstrate reuse of the same shared infrastructure across materially different institutional workflows.
- Deliverables / Value Metrics:
- Reusable governed-consumption patterns for applicable issuance, transfer, settlement, eligibility, approvals, custody/operational conditions, and human authorization. These are reusable patterns, not commitments to production-integrate every workflow class.
- Reference Implementation 1 — Institutional Continuous Assurance: Demonstrate State A → material change → State B → remediation → State C through evidence refresh, sufficiency handling, deterministic reassessment, updated decisions/packages, successor lineage, and authorized stakeholder visibility.
- Reference Implementation 2 — Tokenized RWA / Settlement: Use synthetic assets, parties, requirements, and evidence unless an approved external integration becomes available. Demonstrate a privacy-preserving multi-party workflow, freshness, authorization, governed consumption, and multi-party verification using the same SDK, lifecycle model, Portable Decision Package, Canonical Proof Package, and verifier. This demonstration does not establish legal/regulatory compliance.
- Bounded Agentic Financial Governance Scenario: Demonstrate APPROVED, DENIED, REQUIRE_APPROVAL, appropriately authorized human approval, bounded agent-to-agent delegati
