feat: add the token-forge side alongside the Canton Coin one

[lmcorbalan]

Summary

Closes #154

The backend rewrite cannot start until the registry is proven against a barebones
participant, which had never been tried. This lands that infrastructure on its own and
leaves the Canton Coin path running.

Changes

• Both DARs ship as vendored binaries, with provenance recording the release each came from
• The token registry runs on 3013, started and stopped by the dev stack
• bootstrap seeds the instrument admin and one DBT instrument
• The registry's whole non-secret configuration is a KEY=value block bootstrap prints on stdout, so no config file exists to go stale
• up deploys the vendored DARs and blocks until the registry answers /readyz
• A test holds bootstrap's printed keys and the dev stack's key list together
• bootstrap and mint-token guard main() on import.meta.main: comparing argv[1] against a realpathed path made a symlinked checkout exit 0 having created nothing
• The registry restart kills only a registry holding that port, waits past the registry's own 8s drain, and starts with DOTENV_CONFIG_PATH=/dev/null so wallet-service's .env, the CANTON_AUTH_SECRET signing key included, stays out of its environment
• The dpm precheck, build-dar and the Canton Coin path are untouched

Deviations

• /registry/metadata/v1/info carries only adminId and supportedApis, so the DBT check is /instruments. The Does the canton-token-forge registry boot against a barebones participant? #151 spike found this and issue Add the token-forge side alongside the Canton Coin one #154's second criterion has been corrected to match
• The token-forge DAR is vendored from v0.2.0, not the spec's v0.1.0: the asset is byte-identical, so one tag governs both the DAR and the registry pin

Acceptance criteria

• dev-stack.sh up starts five services and the registry answers /readyz on 3013
• /registry/metadata/v1/instruments reports one DBT instrument
• The dApp on 3012 still vests Canton Coin, unchanged
• dev-stack.sh down leaves 3010-3013 free

Test plan

Automated tests

1. Run pnpm install
2. Run pnpm test
3. Expect every workspace green, including the script test that holds bootstrap's printed keys and the dev stack's key list together, and the one that runs mint-token through a symlinked path

Manual verification

1. Install the DAML SDK (3.4.11) so dpm is on PATH, then run ./scripts/dev-stack.sh up
2. Expect five services, the last being the token registry on 3013
3. Run curl -sS http://localhost:3013/readyz and expect {"status":"ready"}
4. Run curl -sS http://localhost:3013/registry/metadata/v1/instruments and expect one DBT instrument with decimals: 10
5. Open http://localhost:3012, connect a wallet, and expect Canton Coin vesting to behave as before
6. Run ./scripts/dev-stack.sh down, then expect lsof -nP -iTCP:3010-3013 -sTCP:LISTEN to report nothing

Steps 3, 4 and 6 were verified against a live LocalNet while the task PRs landed. Steps 1,
2 and 5 need a machine with dpm, which PR 3 removes, so the two criteria they cover are
left unchecked above.

Known minors

• The "Stack is up" heredoc still hardcodes 3013 while start_registry logs $port. registry_port() now exists and would close it in one line, deferred rather than widened into this PR.

Breaking changes

None.

Checklist

• Self-reviewed my own diff
• Tests added or updated
• Docs updated (if applicable)
• No unrelated changes bundled in

Screenshots

None.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
demo.canton-dappbooster	Ready	Preview	Sep 4, 2026 5:19pm UTC
docs.canton-dappbooster	Ready	Preview	Sep 4, 2026 5:19pm UTC

[Copilot]

🔵 Needs a closer look

It changes core dev infrastructure (dev-stack process lifecycle, a build-script-running git dependency, and the lockfile) whose full up integration path depends on dpm/Docker/LocalNet and cannot be end-to-end validated here.

Pull request overview

This PR stands up the canton-token-forge registry side-by-side with the existing Canton Coin path, so the read-only CIP-56 registry can be proven against a barebones participant before a larger backend rewrite begins. It vendors both required DARs as committed binaries, seeds a DBT instrument during bootstrap, and wires the registry into the dev-stack.sh local loop on port 3013 — all driven by a KEY=value block that bootstrap prints on stdout and dev-stack.sh reads back, so no config file exists to go stale.

Changes:

• Vendors canton-token-forge.dar and vesting.dar (with PROVENANCE.md and a *.dar binary gitattribute), and adds @bootnodedev/canton-token-forge@v0.2.0 as a git devDependency (lockfile, allowBuilds, knip ignore).
• Extends bootstrap-vesting.mjs to create an instrument admin, seed one DBT InstrumentConfig, and print a registry env block; adds a contract test that keeps the printed keys and dev-stack.sh's REGISTRY_ENV_KEYS in sync.
• Adds registry start/stop/port lifecycle to dev-stack.sh, and switches both bootstrap-vesting.mjs and mint-token.mjs from an argv[1] comparison to import.meta.main (fixing a symlinked-checkout no-op), with a new symlink test.

File summaries

File	Description
vendor/PROVENANCE.md	Documents both vendored DARs; checksums/sizes verified to match the committed binaries.
scripts/bootstrap-vesting.mjs	Seeds the instrument admin + DBT config, adds formatRegistryEnv, guards main() with import.meta.main.
scripts/bootstrap-vesting.test.mjs	New contract test asserting the printed block matches the keys dev-stack.sh reads back.
scripts/mint-token.mjs / .test.mjs	Switches guard to import.meta.main; adds a symlinked-path invocation test.
scripts/dev-stack.sh	Deploys vendored DARs, teeing bootstrap output, and manages the registry lifecycle on 3013.
README.md / CLAUDE.md / architecture.md	Document the registry service, updated loop steps, and the bootstrap/dev-stack contract.
pnpm-workspace.yaml / pnpm-lock.yaml / package.json / knip.json	Register the git dependency and its build/ignore entries.
.gitattributes	Marks *.dar as binary.

I reviewed the shell lifecycle, env-key contract, ledger/bootstrap logic, and docs, and verified import.meta.main behavior (including through a symlink) plus the vendored DAR checksums. I found no concrete defects to comment on: the env-key contract is consistent between bootstrap and dev-stack.sh, the module-guard change is correct for the pinned Node 24.20, and the vendored binaries match their documented provenance. The one known cosmetic nit (the "Stack is up" heredoc hardcoding 3013) is explicitly acknowledged and deferred in the PR description.

Review details

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

• Files reviewed: 12/16 changed files
• Comments generated: 0
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.