feat: generate and register CDM metadata from deployment manifests - #200
Draft
charlesHetterich wants to merge 1 commit into
Draft
feat: generate and register CDM metadata from deployment manifests#200charlesHetterich wants to merge 1 commit into
charlesHetterich wants to merge 1 commit into
Conversation
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.
Contributor
CI Summary
Deploy ContractsDeployed addresses vs DEPLOYMENTS.mdExpected is the committed manifest; actual is this CI deployment of the same pipeline.
Labelsdependencies, other, type: docs |
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
sphamjoli
requested changes
Aug 6, 2026
sphamjoli
left a comment
Member
There was a problem hiding this comment.
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
Member
|
@charlesHetterich please update the PR and ensure it follows the template |
charlesHetterich
marked this pull request as draft
August 14, 2026 16:50
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
Networks without a CDM preset pass explicit endpoints:
--name custom --assethub-url wss://… --bulletin-url wss://… --registry-address 0x….Design
out/**, and only deployment-independent content (CDM package names, descriptions, readmes) is checked in underscripts/deploy/cdm/. The generator fails loudly if the manifest is missing a required contract or an artifact is absent.Create3Factoryis intentionally not published; the two beacons use the OZUpgradeableBeaconABI.SubnodeRecordtuple order, released escrow deposits attributed to the wrong ledger, the registry-delegated write path missing from the content resolver docs, and a nonexistentclaimLabelStoreForoverload. 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), andcdm installfrom a clean project resolved a published package with its address and full ABI via the registry + Bulletin.Notes for reviewers
@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).DotnsNameEscrowcredits 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.lockgrew by the@parity/cdm-*+ product-sdk dependencies used by the register script.bun run deploy— documented as optional Step 9 inDEPLOYMENT_CHECKLIST.md.