Skip to content
CCPEDIAby Unity Nodes
Mailing Lists/Freename AG – Party Name Resolution & Imported Names Dev Fund ProposalsSource on lists.sync.global ↗

Freename AG – Party Name Resolution & Imported Names Dev Fund Proposals

grants-discuss0 messages
  1. #1Gherardo29-09-2026source ↗

    Hi everyone,

    I'm Gherardo Varani from Freename AG. Following guidance from Amanda Martin, COO of the Canton Foundation, I'm bringing our two related Development Fund proposals to the broader community for discussion, particularly around their sequencing, dependencies, and milestone structure.

    Canton Party Name Resolution – Reference Implementation
    Dev Fund PR #60: https://github.com/canton-foundation/canton-dev-fund/pull/60
    Related CIP #171: https://github.com/canton-foundation/cips/pull/171
    Covers the reference implementation of the Party Name Resolution standard: resolution service, party-id resolver, CNS wrapper, rendering components, and SDKs.

    Canton Imported Names – DNS Importer
    Dev Fund PR #811: https://github.com/canton-foundation/canton-dev-fund/pull/811
    Related CIP #249: https://github.com/canton-foundation/cips/pull/249
    Covers the reference implementation of Imported Names, starting with DNS/DNSSEC-based name import and its integration with Canton credentials and resolution.

    Over the past several months, Freename has been contributing to the Identity & Metadata Working Group, including authoring the Party Name Resolution and Imported Names CIPs and working through the review process on #171. The CIP and design work is contributed at no cost; the two proposals, totaling approximately $240k equivalent in CC, fund the subsequent reference implementation. On our side, all changes requested to date on #171 and #249 have been applied; the remaining steps are review and coordination.

    Based on our technical analysis, which we will validate in the coordination with PixelPlex and Digital Asset that Simon suggested, the implementation dependencies are:

    • The resolver's on-ledger state builds on DA's CN Credentials Standard (#204); the TestNet-dependent milestones are sequenced after a credential registry is deployable on TestNet.
    • #171 and PixelPlex's Party Profile work (#169) can progress in parallel, with one specification-level coordination point (the preferred-name claim).
    • #249 follows #171, and its on-ledger/TestNet portion likewise builds on #204.
    • There is no dependency on PixelPlex's software implementation itself.

    We are coordinating with PixelPlex to make these dependencies explicit and will bring a consolidated delivery plan back to the SIG.

    I've cc'd @Paolo Domenighetti, our CTO and author of the two CIPs, for any technical questions or additional context.

    At the same time, a meaningful portion of the reference implementation does not depend on #204. For the Party Name Resolution grant, we would restructure the current A2 milestone so that every milestone carries explicit, verifiable preconditions – and no milestone commences or becomes payable before its preconditions are met:

    A2a – Standard-only implementation – 324,675 CC (~$50k)
    Core FQPN parser/validator, Resolution Service against the #171 OpenAPI interface with a mock ledger adapter, party-id resolver, CNS v1 compatibility wrapper, rendering components, SDK structure.
    Precondition: CIP #171 reaches Proposed status.

    A2b – Ledger integration on TestNet – 194,806 CC (~$30k)
    Resolution against real on-ledger credentials, TestNet round-trip verification, 50+ parties, performance benchmarking.
    Precondition: a #204 credential registry deployable on TestNet.

    A3 – unchanged at 324,675 CC (~$50k). The overall grant amount is unchanged at 844,156 CC (~$130k).

    A similar separation can be applied to the Imported Names proposal, distinguishing the DNSSEC/importer engine work from the credential pipeline and TestNet work.

    Our question for the group: could the proposals be reviewed and potentially approved conditionally under this structure – with each milestone gated on explicit preconditions (CIP approval, #204 on TestNet), so that no work under that milestone commences and no funding is drawn before its underlying standards and dependencies are in place?

    We'd appreciate feedback from SIG members and Development Fund participants before we update the proposals accordingly.

    Thanks everyone,
    Gherardo Varani

    --
    Gherardo V.
    Head of Business Development
    Book a meeting