Skip to main content

Registry Modules Policy

Document type: Policy
Doc ID: POL-REGISTRY-MODULES
Status: Final v0.1
Release date: December 21, 2025
Author: Nicolas Turcotte, Founder
Source repo: dcorps-docs-public (docs/policy/POL-REGISTRY-MODULES.md)
Last updated: 2025-12-24

Scope: Rules for listing, maintaining, and delisting modules and applications in official dCorps registries.

1. Purpose and scope

The module and app registry serves to:

  • provide a curated, transparent catalog of modules and apps that integrate with the dCorps Hub;
  • communicate risk levels, audit statuses, and intended use cases;
  • avoid the appearance of implicit endorsement beyond clearly stated criteria.

This policy covers:

  • protocol modules approved via governance and listed in the on-chain module registry;
  • applications and tools listed in any official off-chain directories maintained by the foundation or community.

2. Listing criteria

To be listed, a module or app:

  • implements relevant dCorps standards (e.g. SPEC-MODULES.md, SPEC-DATA.md);
  • has clearly documented purpose, scope, and limitations;
  • discloses its operators, maintainers, and any economic relationships with dCorps;
  • undergoes appropriate security review for its risk profile.

Additional expectations for high-impact modules include:

  • public audit reports or equivalent independent review;
  • documented incident response and maintenance plans;
  • clear user-facing risk disclosures.

3. Review and approval process

3.1 Protocol modules

Protocol modules:

  • are approved via on-chain governance following SPEC-MODULES.md;
  • are listed in the on-chain module registry upon activation;
  • may be accompanied by off-chain entries with richer descriptions and documentation.

3.2 Applications and tools

Apps and tools integrated into official directories:

  • may be submitted via a lightweight application process;
  • are reviewed by a small review group or foundation team;
  • must not misrepresent themselves as official unless explicitly designated.

Decisions to list or not list an app or tool are based on transparent criteria and documented where practical.

4. Risk tiers and labels

Each listed module or app may have risk labels, for example:

  • Core – maintained by or under the close oversight of core teams or the foundation.
  • Ecosystem – maintained by third parties with established track records.
  • Experimental – new or unproven modules with limited track record.

Additional labels may include:

  • Audited / Unaudited;
  • High impact (e.g. modules that can affect funds or governance outcomes);
  • Jurisdictional (modules binding on-chain behavior to local law).

Risk labels are:

  • clearly explained to users;
  • updated when new information (e.g. audits, incidents) arrives.

5. Delisting and incident response

Modules or apps may be delisted or downgraded when:

  • severe vulnerabilities or abuses are discovered;
  • operators fail to address issues within reasonable timeframes;
  • behavior diverges materially from stated purpose or policy.

For protocol modules:

  • delisting or disabling goes through on-chain governance, except in narrowly scoped emergencies handled under governance and security policies.

For apps and tools:

  • registry maintainers may delist quickly in response to credible security issues or abuse, with public post-hoc explanations when appropriate.

Delisting does not retroactively validate or invalidate past use; users remain responsible for their own decisions. The objective is to provide timely, transparent signals about ongoing risk.