Skip to content

feat: generate and register CDM metadata from deployment manifests - #200

Draft
charlesHetterich wants to merge 1 commit into
masterfrom
cdm-registry-publish
Draft

feat: generate and register CDM metadata from deployment manifests#200
charlesHetterich wants to merge 1 commit into
masterfrom
cdm-registry-publish

Conversation

@charlesHetterich

@charlesHetterich charlesHetterich commented Aug 5, 2026

Copy link
Copy Markdown

Most of the LOC added in this PR are md files with descriptions for each the DotNS contract, to be uploaded to the CDM registry. The descriptions were generated by Fable reviewing each contracts function in the larger DotNS system, so please feel free to re-write these.

The goal of this PR is to provide a script for DotNS CI to use to register DotNS contracts on the CDM registry so that DotNS consumers can reference the contracts by name instead of with hardcoded addresses. The idea is that the script should get DotNS permanently on CDM on all networks (paseo, previewnet, etc.)


Implements the flow for making DotNS addresses resolvable through the CDM contract registry: after a deploy, one command generates CDM assets from the actual deployment output, and a second publishes them — so consumers run cdm install @dotns/<package> instead of chasing address changes across redeploys.

Flow

forge build

# 1. Generate CDM assets from the deployment you just produced:
bun run cdm:generate -- \
  --deployment deployments/<folder>/<chain-id>.json \
  --network <label>

# 2. Preview (connects, checks ownership + idempotence, submits nothing):
bun run cdm:register -- --metadata .generated/dotns-cdm/metadata.json --name paseo --dry-run

# 3. Publish (CDM_SURI env var also accepted):
bun run cdm:register -- --metadata .generated/dotns-cdm/metadata.json --name paseo --suri "<mnemonic>"

Networks without a CDM preset pass explicit endpoints: --name custom --assethub-url wss://… --bulletin-url wss://… --registry-address 0x….

Design

  • Nothing generated is hand-maintained. Addresses come from the deployment manifest, ABIs from out/**, and only deployment-independent content (CDM package names, descriptions, readmes) is checked in under scripts/deploy/cdm/. The generator fails loudly if the manifest is missing a required contract or an artifact is absent. Create3Factory is intentionally not published; the two beacons use the OZ UpgradeableBeacon ABI.
  • Safe to re-run. Metadata is uploaded to Bulletin before the registry points at it, and contracts whose registered address + metadata CID already match are skipped — a partially-failed run is just re-run. Registration is versioned on-chain; skipping avoids burning versions on no-ops.
  • Readmes audited against current sources. The copies that previously lived in contract-developer-tools had drifted: wrong SubnodeRecord tuple order, released escrow deposits attributed to the wrong ledger, the registry-delegated write path missing from the content resolver docs, and a nonexistent claimLabelStoreFor overload. All corrected against the code in this repo.

Verified end to end

Against a local preview network: generated assets for all 16 contracts from the committed deployments/paseo-assethub/420420417.json, published them, re-ran (all 16 skipped as unchanged), and cdm install from a clean project resolved a published package with its address and full ABI via the registry + Bulletin.

Notes for reviewers

  • On the public Paseo registry the @dotns/* names are already claimed by the account that first published them from contract-developer-tools; subsequent publishes there must sign with that account (name ownership is enforced on-chain).
  • The readme audit surfaced one open question for the team: the top-level README says released escrow deposits land in the per-entry refund ledger, but DotnsNameEscrow credits them to the no-cooldown withdrawal balance (claimWithdrawal); the new readme follows the code. If the README is the intended behavior, that's worth a look.
  • bun.lock grew by the @parity/cdm-* + product-sdk dependencies used by the register script.
  • Suggested run-list placement: right after bun run deploy — documented as optional Step 9 in DEPLOYMENT_CHECKLIST.md.

Adds a post-deploy path that publishes DotNS contract addresses and
metadata to the CDM contract registry, so consumers resolve current
addresses with cdm install instead of chasing them across redeploys.

- scripts/deploy/cdm/generate.ts: builds a CDM asset directory from a
  deployment manifest (deployments/<folder>/<chain-id>.json), Foundry
  artifacts (out/**), and checked-in static descriptors + readmes.
  Addresses and ABIs always come from the actual deployment and build;
  nothing generated is hand-maintained. Fails clearly on missing
  contracts or artifacts.
- scripts/deploy/cdm/register.ts: uploads each contract's metadata to
  the Bulletin chain, then publishes (name, address, metadata CID) to
  the CDM registry on Asset Hub. Metadata is stored before the registry
  points at it; re-runs skip contracts whose registered address and
  metadata already match, so partial failures are safely retryable.
  Works with CDM presets (--name paseo) or fully custom endpoints
  (--name custom + explicit URLs) for networks like previewnet.
- Readmes and descriptions audited against the current contract sources
  (fixed stale claims around registry record tuple order, escrow
  ledgers, content-resolver authorization, and PoP controller surface).
- DEPLOYMENT_CHECKLIST.md: documents the flow as optional Step 9.

Verified end to end against a local preview network: 16 contracts
generated from the committed paseo manifest, published, re-run skipped
all 16 as unchanged, and cdm install resolved a published package with
its full ABI.
@github-actions github-actions Bot added dependencies Pull requests that update a dependency file other type: docs labels Aug 5, 2026
@github-actions

github-actions Bot commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

CI Summary

Check Result
Deploy Contracts Reproduces DEPLOYMENTS.md; resume verified
PR Title PR Title Valid
Labels Unknown
Secret Scan Passed - No secrets detected

Deploy Contracts

Deployed addresses vs DEPLOYMENTS.md

Expected is the committed manifest; actual is this CI deployment of the same pipeline.

Contract Expected Actual Match
Create3Factory 0x8533c79E058c5a6489CAFeCA86dc600E029D75f5 0x8533c79E058c5a6489CAFeCA86dc600E029D75f5 match
DotnsContentResolver 0x7F74D7CD50f5a834270E2ad395a01b01891AB37d 0x7F74D7CD50f5a834270E2ad395a01b01891AB37d match
DotnsNameEscrow 0x4881Afb78e7C908cAe818168B926229D93376520 0x4881Afb78e7C908cAe818168B926229D93376520 match
DotnsPopController 0xCC932348606cc1f3318cADeC5A5Cd2CA447f8a4b 0xCC932348606cc1f3318cADeC5A5Cd2CA447f8a4b match
DotnsPopResolver 0xDaC984884EcA8Fc44011f1D6C49B27828390A72B 0xDaC984884EcA8Fc44011f1D6C49B27828390A72B match
DotnsProtocolRegistry 0xD19e3D0C97CF501125a04A97405e3e6592fa846E 0xD19e3D0C97CF501125a04A97405e3e6592fa846E match
DotnsRegistrar 0x4f06E818Ba3d987704fd91cf3d868E4b019106Ab 0x4f06E818Ba3d987704fd91cf3d868E4b019106Ab match
DotnsRegistrarController 0xBdaA01bD1bA67d709F2b1fF286Da0d854977EA30 0xBdaA01bD1bA67d709F2b1fF286Da0d854977EA30 match
DotnsRegistry 0xf34054fd76BbF85f216cf9908226D5f0A72E50CA 0xf34054fd76BbF85f216cf9908226D5f0A72E50CA match
DotnsResolver 0xbd1165E549DF96F083c0A16f61590927bC187009 0xbd1165E549DF96F083c0A16f61590927bC187009 match
DotnsReverseResolver 0xee3883d7eB60Ee9BCD7F3bcD8f2f05302A9Cc035 0xee3883d7eB60Ee9BCD7F3bcD8f2f05302A9Cc035 match
LabelStoreBeacon 0xb57Ebc2e7085616d4906D1fE49af1cE13f7dffeF 0xb57Ebc2e7085616d4906D1fE49af1cE13f7dffeF match
Multicall3 0xB4468000abD87D3c56cbFBd153161223D7b109e5 0xB4468000abD87D3c56cbFBd153161223D7b109e5 match
PopRules 0x747B456bE03aec0b42bd85C51513730FBD45DA31 0x747B456bE03aec0b42bd85C51513730FBD45DA31 match
RootGatewayDispatcher 0xa889CCA3Fb4B07b98a11cc54C10f13dDA20bc3db 0xa889CCA3Fb4B07b98a11cc54C10f13dDA20bc3db match
StoreFactory 0x709A027F446a9e2a4BB9cb9a9c754435b19e32B7 0x709A027F446a9e2a4BB9cb9a9c754435b19e32B7 match
UserStoreBeacon 0xb7C995601679840d36F37E86DB2d7dF30797eC5C 0xb7C995601679840d36F37E86DB2d7dF30797eC5C match
_seed 0x0000000000000000000000000000000000000000 0x0000000000000000000000000000000000000000 match

View full logs

Labels

dependencies, other, type: docs

@socket-security

Copy link
Copy Markdown

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff Package Supply Chain
Security
Vulnerability Quality Maintenance License
Added@​parity/​cdm-env@​2.3.0731006896100
Added@​parity/​product-sdk-tx@​0.2.17771007199100
Added@​parity/​product-sdk-cloud-storage@​0.5.5771007196100
Added@​parity/​cdm-builder@​5.0.0761007397100
Added@​parity/​product-sdk-contracts@​0.9.27610010099100

View full report

@sphamjoli sphamjoli left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR, my suggestion is instead of hand rolling custom .md files find a way to feed them the natspec from the contracts. The reason for this is that natspec is the source of truth, and should these .md files drift from whats written on the natspec. It creates more work for us to update them. But if we seed them using natspec data, we dont have to manually create/re them

@sphamjoli

Copy link
Copy Markdown
Member

@charlesHetterich please update the PR and ensure it follows the template

@charlesHetterich
charlesHetterich marked this pull request as draft August 14, 2026 16:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file other type: docs

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants