Skip to content
CCPEDIAby Unity Nodes
Mailing Lists/CIP (PR 245) - File Governance for Multi-Party Contracts - Nandit MehraSource on lists.sync.global ↗

CIP (PR 245) - File Governance for Multi-Party Contracts - Nandit Mehra

cip-discuss0 messages
  1. #1Nandit Mehra25-08-2026source ↗
    Hi all,

    Opening a discussion thread for a draft CIP on file governance for multi-party contracts. No CIP number has been assigned yet; the PR is here:
    https://github.com/canton-foundation/cips/pull/245

    Why this came up
    Contracts on Canton routinely reference material that does not live on-ledger: signed agreements, supporting documentation, attestations, identity and compliance artifacts. The ledger records that the parties agreed, but it does not record what they agreed to rely on or provide a shared way to govern access to those materials over time.
    Today, each application solves this independently. As a result, access rules for the same document can differ between counterparties, there is no consistent way to prove which party could access what at a given point in time, and a party leaving a contract does not reliably lose access to the material associated with it. For multi-party contracts involving regulated participants, this creates a meaningful governance gap.

    What the proposal covers

    The draft sets out a governance pattern for associating off-ledger files with on-ledger contracts, so that access is derived from contract state rather than maintained separately by each participant. It is intended as a pattern and interface, rather than a mandate for any particular storage or encryption implementation.

    What would help
    Feedback from anyone working on identity, metadata, or document handling in Canton applications would be especially valuable. Specifically:
    1. Whether the problem framing matches what you are seeing in practice, or whether it is narrower or broader than described.
    2. Whether deriving access from contract state is the right anchor, or whether it should key off something else.
    3. Anything in the specification that is underspecified or conflicts with existing patterns.

    Happy to revise substantially based on the feedback.
    Nandit
    Lighthouse