Skip to content

Naming Guidelines

davidwboswell edited this page Mar 17, 2026 · 3 revisions

Project and Lab Naming Guidelines

Part of the contribution process at LF Decentralized Trust (LFDT) includes selecting a name for your new Project or Lab. A strong, well-vetted name helps avoid legal and branding issues later, ensures the project’s long-term stability, and provides clarity for our community and ecosystem.

Choosing a name is not just creative—it is a critical governance step. If a project name conflicts with an existing company, product, or trademark, we may be forced to change it later, creating unnecessary disruption.

This document outlines the step-by-step process to follow when proposing a new name.

Our LFDT staff is here to help you, so if you have any questions or are ready to start the process please reach out to us community-architects@lfdecentralizedtrust.org

Step 1. Check for Existing Usage

Search engines (Google, Bing, etc.) – Search the proposed name directly.

Industry overlap check – Ask: is the name already used by another project, company, or product in blockchain, digital identity, or decentralized technologies?

Secondary searches – Use queries like:

  • “[Proposed Name] + blockchain”
  • “[Proposed Name] + decentralized”

If the name is already widely used in our industry, it should be eliminated from your list. If it is used, but not widely in another industry/domain we can review.

Step 2. Trademark Check

Conduct a preliminary search in trademark databases (USPTO, EUIPO, WIPO, etc.).

Note: the presence of a trademark is not always a blocker (some are abandoned or unused).

LFDT’s trademark counsel will provide a final review and recommendation.

Step 3. Domain Availability

Check whether .org or .io domains are available and other domains.

Note: domain availability is not always a blocker

Important: Do not purchase the domain yourself. Contact LFDT staff, who will secure it.

  • If you purchase, the domain may be subject to a 90-day transfer lock, delaying setup.

Step 4. GitHub Repository Check

Search GitHub for the proposed name.

If a repo already exists:

  • Is it active?
  • Is it related to blockchain or decentralized trust?
  • If it is unrelated, the name may still be acceptable.

Step 5. Negative Connotation Check

Research cultural, historical, and pop-culture meanings.

Avoid names with offensive, controversial, or sensitive associations across major languages and regions.

Think globally—LFDT is an international community.

Step 6. Shortlist Multiple Options

Create a shortlist of 3–4 names.

Provide the findings from Steps 1–5 for each name.

This helps LFDT staff and trademark counsel to evaluate and approve faster.

Step 7. Document Findings for Review

For each name option, document the following:

Search results: Is it already in use (general + blockchain specific)?

Trademark status: Any existing filings?

Domain status: Is .org or .io available?

GitHub availability: Repo taken? Active or inactive?

Connotations: Any negative cultural/historical associations?

Submit your findings to LFDT staff.

Step 8. Trademark Lawyer Review

LFDT’s trademark counsel will review the shortlist.

Note: Review may take several weeks, depending on availability. Please talk to the LFDT team about timing.

Counsel will provide a recommendation on which names are safe to use.

Step 9. Name Selection & Finalization

Once cleared, the project’s maintainers will select their preferred name from the approved options. LFDT can assist with a formal voting process for maintainers if required using our LFX vote/survey tools.

LFDT staff will assist with:

  • Trademark filings (if appropriate)
  • Domain registration
  • GitHub repo setup
  • Logo development and branding assets

Additional Considerations

Existing names: If you already have a name and a trademark, you may propose it.

  • You’ll need to transfer the trademark to the Linux Foundation for open governance.
  • Projects cannot share the same name as a commercial product or service derived from the code. Example: Hedera contributed code to LFDT, but the project was named Hiero (not Hedera).

Neutrality: Names should not reference one company, jurisdiction, or product.

Clarity: Prefer short, memorable, and pronounceable names.

Example Workflow

Maintainers brainstorms 5 candidate names.

Conduct Steps 1–5 for each.

Narrow to 3 viable names.

Submit shortlist + documentation to LFDT staff.

LFDT trademark counsel reviews.

Maintainers choose the final name from cleared options.

LFDT finalizes branding and infrastructure.

Summary

Naming is a community responsibility and requires due diligence. Following these steps ensures that LFDT projects and Labs launch with strong, sustainable names that reflect our shared values of open collaboration, neutrality, and trust.

Ready to get started? Please use the LF Decentralized Trust – Project/Lab Naming Checklist

Sub-Project Naming Guidelines

These guidelines help maintainers name modules or components within a project to support trademark protection, ecosystem consistency, and clear marketing alignment.

Use a Project Prefix

Most top-level projects hosted at LF Decentralized Trust have trademark protection. Sub-projects can inherit that protection by including the parent project name as a prefix.

Examples

  • Hiero Heka
  • Hyperledger Fabric Smart Client

Usage rules

  • Use the full name (prefix + sub-project name) on the first reference.
  • Subsequent references in the same context may drop the prefix.

Example:

  • First reference: Hiero Heka
  • Later references: Heka

The full project name should also be used:

  • in the repository name
  • in the first reference within the repository documentation

Avoid Trademark Conflicts

Trademark protection for sub-projects is limited. Sub-project names should avoid obvious conflicts or misleading associations.

Examples of names that would not be acceptable

  • Hiero Lightsaber
  • Besu Windows

If a trademark conflict arises, LFDT will work with maintainers to select an alternative name.

When the Prefix Is Required

The project prefix should be used when a component or module contains code that could be deployed or used as part of the project ecosystem. This helps ensure:

  • clear attribution to the parent project
  • consistency across the ecosystem
  • stronger trademark alignment

When the Prefix Is Not Required

The prefix is not required for repositories that do not contain deployable code.

Examples include:

  • governance materials
  • roadmaps
  • documentation repositories

Questions

If you are unsure whether a component should include the project prefix, contact: marketing@lfdecentralizedtrust.org

Clone this wiki locally