CIP-XXXX: Building a Name Resolution Service for Permissioned Blockchain Infrastructure - A Hybrid Tiered Approach

Abstract

This paper recommends how a name resolution service, one that maps human-readable metadata to machine-readable identifiers, such as Canton Party IDs should be designed for a permissioned network whose primary adopters are regulated financial institutions.

Its central claim is that Canton should not adopt a single resolution approach. Instead, it should adopt a hybrid, tiered architecture, where metadata is classified into tiers by how mission-critical it is, and each tier is served by a resolution service whose trust level matches it.

Mission-critical mappings (e.g. bank name to settlement address) are served by a highly trusted Tier 1 service, operated by a highly trusted, highly available, and accountable operator. Super validators are one natural candidate for that role, but the proposal does not mandate them; what matters is the trust requirement, not the specific operator. Less critical mappings are served by less trusted or individually hosted services owned by the data owners themselves.

A benefit of this structure is that institutions can bring their own existing name resolution mapping sets into Canton ecosystem, preserving consistency with their existing established processes and practices.

The Problem Statement

Canton identifies parties by Party IDs, which are long and opaque strings that bind an arbitrary label (a "hint") to a cryptographic namespace fingerprint. The label is just that, an arbitrary string: it carries no inherent meaning, is not guaranteed to be unique, and is not a trustworthy basis for recognizing a counterparty. These identifiers are precise and secure, but not human-usable, and their labels cannot be relied on. No operations analyst will eyeball a fingerprint before authorizing a settlement, and no end user will type one into a payment screen. Every practical workflow therefore needs a layer that translates between what people recognize and what the ledger enforces.

Existing Solutions

There are multiple types of well known and widely implemented name resolution service architectures, each carrying its own benefits and tradeoffs serving different scenarios.

DNS-like

Key words: hierarchical, partitioned A root authority delegates control downward, and the namespace is partitioned so no two registries own the same name (*.jpmorgan.canton and *.goldman.canton can't collide). Battle-tested at internet scale and delegation maps naturally onto institutions, but it tolerates caching, propagation delay, and divergent answers, which is fine for websites and undesirable for cases like settlement routing.

ENS-like

Key words: single canonical registry, decentralized governance One unpartitioned namespace backed by a single canonical on-chain list. Conflicts are prevented at registration: a name is registered once, and a second registration fails. Delivers exactly one unambiguous answer per name, but permissionless registration invites squatting, and nothing ties a name to a real-world identity (anyone can register jpmorgan.eth).

Federated multi-resolver

Key words: multi-source, relying-party trust, divergence as signal Many independent resolvers answer the same query, agreement raises confidence, divergence is surfaced to the application. Each relying party picks which resolvers to trust. Excellent for verification and importing claims from existing systems, but poor for routing money: the same name can resolve differently across apps, and bad-faith resolvers can grief or force conflicts.

Canton's Uniqueness

Most name services were designed for the open internet (DNS) or permissionless chains (ENS). Canton's environment differs in three ways that change the requirements:

• It is a public network with application-level permissioning. Canton itself is a public network: anyone can request a validator node and participate in consensus for transactions they are party to. Permissioning is not a property of the participant nodes; it is defined per application, where each app provider chooses how open or restricted its application is (see the Canton Network FAQ). The financial applications a name service must serve typically onboard known, accountable participants, so the naming layer for those applications can lean on real-world legal identity and existing trust relationships rather than manufacturing trust from scratch.
• It primarily serves regulated financial institutions. The dominant failure mode to engineer against is impersonation that misdirects value, not link rot. Resolving "Bank A" to the wrong party in a settlement flow is a potentially irreversible financial event, not a degraded experience.
• Institutions arrive with pre-existing naming systems. Banks already maintain authoritative directories, SWIFT/BIC mappings, and curated address books. Adoption is least disruptive when they can keep using them on Canton rather than migrating onto a registry they do not control.

Trust Must Match the Stakes

Depending on the type of metadata being resolved, a correspondingly trusted service should answer the query. Trust in the source must scale with the consequence of a wrong answer.

• Mission-critical metadata: Name resolutions like "Bank of Example" to settlement Party ID, or "USDC" to issuer, must come from a very trusted source, such as a top-tier resolution service operated by a highly trusted, highly available, and accountable operator. A spoofed answer here misdirects value, possibly irreversibly.
• Less critical metadata: display names, avatars, a dApp's own product names, all can be served by less trusted or individually hosted services owned by the data owners themselves. A wrong answer is a cosmetic blemish, not a financial event.

Trust here means network-wide canonical authority, not absolute trust. These two are easy to conflate. An institution's own curated address book is, from that institution's point of view, the most trusted source it has, more trusted than any network registry, because it owns and controls it. That is local authoritative trust, and the architecture must honor it (an owner's own data always wins for the owner's own workflows). What the tiering above describes is a different axis: which mappings need a single, network-wide canonical answer that every participant agrees on. Tier 1 is reserved for that small set of mappings where the whole network must converge on exactly one answer (so an impostor cannot offer a competing one), not for "data we trust more than the institution's own".

This gradient is the seed of the paper's recommendation: not one name service, but a tiered set of them, each matched to the criticality of the metadata it serves.

Serving Needs of Existing Institutional Users

Another benefit of the tiered structure: individual data and service owners can bring their existing name-resolution mapping sets into Canton.

Consider a pre-established financial institution newly onboarded onto the network. It already maintains authoritative directories, such as counterparty reference data, SWIFT/BIC mappings, curated address books, all embedded in existing systems. Rather than re-registering everything in a network-wide registry it does not control, the institution imports its mappings wholesale into a resolver it owns, keeping its workflows consistent with what it already runs.

These sources fall into two broad categories, and both should be supported:

• Internal-facing sources are an institution's own private reference data: internal counterparty IDs, desk- or entity-level address books, account aliases, and internal labels for partners. These are authoritative for the institution's own workflows and frequently confidential. They should resolve correctly for the owner without being exposed to, or imposed on, the rest of the network.
• External-facing sources are mappings derived from recognized shared references the institution already relies on, such as SWIFT/BIC directories, GLEIF/LEI records, or another name service it participates in. Importing these lets the institution keep resolving counterparties exactly as it does today, while selectively promoting the handful that need network-wide recognition into the top tier.

Imported mappings are scoped to their owner by default, authoritative for that institution's workflows, not imposed on the network, so two institutions importing conflicting mappings never collide. Only the few mappings needing network-wide recognition (e.g. the institution's own settlement identity) are registered in the top-tier service. The net effect is reduced friction to onboard onto the Canton ecosystem: institutions adopt the network without first surrendering control of their naming, or fighting over a shared namespace.

Goals and non-goals

Goals

• Recommend a hybrid, tiered architecture: classify metadata by how mission-critical its resolution is, and match each tier to a service with the corresponding trust level and operator, from a highly trusted, neutral, governed registry for critical mappings (super validators being one natural candidate operator) down to owner-hosted resolvers for the rest.
• Enable institutions to bring their existing name-resolution mappings into Canton, keeping consistency with established processes without forcing migration onto a registry they do not control.
• Serve as the rubric against which concrete name-service proposals are assessed.

Non-Goals

• This paper does not specify wire formats, Daml templates, API schemas, fee models, or a governance charter, those belong in dedicated Standards Track CIPs.
• This paper does not endorse a single existing proposal to the exclusion of others.
• This paper does not attempt to solve general-purpose decentralized identity; it is scoped to resolving names/metadata to Canton identifiers.

The Proposed Solution: A hybrid, Tiered Name-Resolution Service

The Core Idea: No Single Approach

Canton should not solve its metadata problem with a single name-resolution approach. The metadata spans too wide a spectrum, ranging from "which Party do I settle against?" to "what logo should this wallet show?". No one mechanism can serve both ends well. A mechanism strong enough for settlement is too expensive and restrictive for logos. One cheap enough for logos is dangerously weak for settlement.

Instead, classify metadata into tiers by how mission-critical its resolution is, and serve each tier with a service whose trust level, operator, and guarantees match.

Mission-Critical Resolution Comes From Highly Trusted Sources

For Tier 1, a wrong answer is a misdirected, possibly irreversible financial event. These mappings must come from a very trusted source. The essential requirement is not a specific operator but a set of properties: the operator must be highly trusted, highly available, accountable, and neutral, and registration must prevent conflicts at the point of registration rather than reconcile them later. Registration is deliberate and verified against the recognized source of truth (e.g. SWIFT directory, GLEIF); a name is registered once, and a competing registration fails.

The set of mappings that genuinely require this treatment is small, effectively the "axioms" of the ecosystem, for example:

1. Institution name → settlement address. If "J.P. Morgan" resolves to the wrong Party, a payment goes to an impostor; there must be exactly one agreed answer before funds move.
2. Stablecoin / asset name → issuer Party. "USDC" must point to the real issuer, or counterfeit assets can be passed off as genuine.
3. The canonical namespace root. Whoever controls "who owns acme.canton" controls a network-wide source of truth, so that registration authority must itself be maximally trusted.
4. Core operator identities. The authoritative list of which Party is actually a super validator or Global Synchronizer operator; spoofing it undermines trust in the network's own infrastructure.

Who operates this is deliberately left open. Super validators are the closest thing the network has today to a highly trusted, neutral, already-vetted operator, so they are a natural candidate. But the proposal specifies the trust requirement, not the operator: a highly trusted, neutral name resolver (or a small governed set of them) could equally fill the role. As detailed in Key Metadata Management, the right framing is that this top tier is primarily a matter of governance and a small set of key metadata, distinct from operating the bulk mapping data itself, which can be delegated.

Less Critical Resolution Is Owned by the Data Owners

Outside Tier 1, the cost of a wrong answer drops sharply while the value of flexibility and owner control rises. These tiers are served by less trusted, or individually hosted, services owned by the data owners, for a dApp resolving its own product names, an institution serving its own display metadata. Relying parties choose which resolvers to trust and in what precedence. This spends top-tier trust only where errors are catastrophic, keeping everything else cheap and under the owner's control.

The model is therefore best read as a spectrum rather than exactly two buckets, and it can be subdivided as needed, for example:

• Tier 1 — governed, network-wide canonical mappings. The small set of "axiom" metadata above, governed by the most trusted operators.
• Tier 2 — accredited registrars and trusted neutral resolvers. Operators accredited under Tier 1 governance to serve specific namespaces (see Key Metadata Management).
• Tier 3 — owner-hosted / self-hosted resolvers. An institution's own imported directories and a dApp's own metadata, authoritative locally and scoped to their owner.

Bring Your Own Mappings

The tiered structure also lets data and service owners bring their existing name-resolution mapping sets into Canton. A pre-established financial institution, newly onboarded, can import its directories, including counterparty reference data, SWIFT/BIC mappings, address books. All wholesale into a resolver it owns, keeping consistency with existing processes and forms. Imported mappings are scoped to their owner by default, so two institutions' conflicting imports never collide; only mappings needing network-wide recognition (e.g. the institution's settlement identity) are registered in Tier 1.

Key Features

The tiered architecture above is the backbone. Two features make it practical to adopt and safe to operate: a low-friction way to bring existing mappings in, and a clear definition of the small set of key metadata and governance that the most trusted tier must own. The first lowers the barrier to onboarding; the second keeps the trusted core small and well-bounded.

Bring-Your-Own-Mapping Import

A name service that asks every institution to re-register its naming from scratch will not be adopted. Institutions already operate authoritative naming today, and the path onto Canton should let them carry that naming with them rather than rebuild it. This feature exists so that an institution can improve and populate its own resolver from sources it already trusts, without first having to resolve conflicts with anyone else's view of the namespace.

What it solves. Because imported mappings are scoped to their owner by default, an institution can import its entire address book without worrying about colliding with another institution's names or with the network-wide tier. Onboarding becomes "point the resolver at your existing data" rather than "negotiate a shared namespace before you can transact". This directly reduces friction to join the ecosystem.

Supported sources. Import should accommodate the formats institutions actually keep their data in:

• Bulk file import (e.g. CSV). An institution uploads a file of label → Party (plus optional metadata such as display name, jurisdiction, or LEI) and the resolver ingests it as owner-scoped mappings. CSV is the lowest common denominator most reference-data systems can already export; other structured formats (JSON, spreadsheets) can be supported through the same pipeline.
• Direct import from an existing name service. Where an institution already runs, or subscribes to, a name service (an internal directory service, or an external/industry reference such as SWIFT/BIC or GLEIF/LEI), the resolver can import from it directly, and optionally stay in sync so updates at the source propagate. This avoids a brittle one-off export and keeps Canton resolution consistent with the institution's system of record.

Interface sketch (illustrative, non-normative). A concrete Standards Track CIP would specify the wire format, but the shape is roughly:

• An import operation that accepts a batch of mappings (inline, by file reference, or by connector to a source name service), all written into the importer's owner-scoped namespace.
• Per-entry validation and conflict handling within the owner's own namespace (e.g. reject duplicate labels, flag malformed Party IDs), with the import reporting which rows succeeded or were skipped.
• A scope/visibility flag per entry, so an institution can mark most imported mappings as private/internal (see design priority 5) while explicitly promoting the few that need network-wide recognition into the appropriate tier.

Because the import targets an owner-controlled resolver, none of this requires trust from, or coordination with, the rest of the network, which is exactly what makes onboarding cheap.

Key Metadata Management

Saying "Tier 1 must be highly trusted" is not enough; the proposal must say what, concretely, that trusted tier is responsible for, and just as importantly, what it is not. This subsection draws that boundary, resolving the open question of whether and how super validators participate.

Governance, not operation. The role of the most trusted tier (super validators today, or another highly trusted neutral body) is best understood as governance over a small set of key metadata, distinct from operating the bulk mapping data or running the resolvers, which can and should be delegated. Concretely, the trusted tier owns:

• Accrediting name registrars. Deciding which operators are trusted to act as registrars on the network, and under what obligations (availability, accountability, conflict-prevention). This is an approval/governance decision, not a data-entry task.
• Delegating namespaces to registrars. Determining which namespaces each accredited registrar may use (e.g. registrar A is authorized for *.bank.canton, registrar B for a different range), so that authority over a namespace is explicit and non-overlapping.
• Holding the namespace root. Maintaining the canonical root of the namespace, the single source of truth for "who is authorized to answer for which namespace", which is itself one of the "axiom" mappings.
• The small set of axiom metadata. The handful of network-critical mappings listed earlier (core operator identities, the namespace root itself), which must converge to exactly one answer.

What it explicitly does not own. The trusted tier does not need to store every institution's mappings, run every resolver, or curate display metadata. Those responsibilities sit with accredited registrars and with data owners themselves. Keeping the trusted tier's surface area this small is deliberate: it bounds the work asked of whoever operates it (addressing the concern that super validators have a narrow, well-defined mandate today), and it keeps the highly trusted core auditable.

Why this matters. Separating governance from operation is what lets the architecture demand a very high trust bar for the namespace root and registrar accreditation while still letting the bulk of resolution be cheap, delegated, and owner-controlled. It also keeps the door open: the governance role is defined by its responsibilities, so it can be filled by super validators, by an accredited set of neutral registrars, or by some combination, without changing the rest of the design.

Assumptions & Design Priorities

The recommendations in this paper are derived from an explicit priority ordering. These are assumptions, not conclusions; if the working group weights them differently, the recommended architecture shifts accordingly.

1. Spoof-resistance is the top priority. For value-bearing flows, preventing impersonation matters more than feature breadth or namespace richness. A naming layer that resolves a counterparty incorrectly is not a degraded experience. It is a potentially irreversible financial event.
2. Resolution availability should track the ledger or application it serves. Workflows that depend on resolution inherit its uptime. Where resolution is deliberately moved off-ledger (e.g. to limit ACS/Scan load), that trade-off must be named and bounded, and fail-closed is generally safer than fail-open for routing.
3. Risk-averse, proven-mechanism bias. On a high-stakes network, prefer mechanisms with a real-world track record (registries, delegation) over novel constructs being validated for the first time in production.
4. Trust is asserted by the relying party, not imposed by the network. No participant should be forced to fully trust any single registry or resolver. Participants choose whom to trust, in what precedence, and may operate their own resolvers.
5. Resolution must support confidentiality, not assume public data. Not every mapping should be publicly visible. Some translations (internal counterparty IDs, private address books, bilateral relationships) are sensitive and should be resolvable only by authorized parties. The name service must therefore be able to keep mappings permissioned and confidential, not default everything to a globally readable directory.