Currently, on LocalNet, I am trying to build a Canton AMM (constant-product swap)
that mints/burns its own **LP tokens**. The swap math and pool templates compile
fine — my build only fails because it depends on the **Utility Registry** packages,
which I can't locate.
## What I'm building
A `x*y=k` AMM with pool create / swap / deposit / withdraw. Deposits mint LP tokens
and withdrawals burn them, using a registrar + allocation factory (Uniswap-V2-style
fee minting).
## Environment
- SDK: **3.4.11**, built with **DPM** (`dpm build`), target LF 2.1
- Token-standard interface DARs already in place and resolving correctly:
`splice-api-token-holding-v1`, `-metadata-v1`, `-allocation-v1`,
`-transfer-instruction-v1`, `splice-api-featured-app-v1` (all v1-1.0.0 from
the public `hyperledger-labs/splice` repo `daml/dars`).
## The blocker
`dpm build` succeeds on everything **except** 8 imports, all from the registry
packages:
```
Could not find module 'Utility.Registry.App.V0.Configuration.Provider'
Could not find module 'Utility.Registry.App.V0.Model.Burn'
Could not find module 'Utility.Registry.App.V0.Model.Mint'
Could not find module 'Utility.Registry.App.V0.Service.AllocationFactory'
Could not find module 'Utility.Registry.App.V0.Service.Registrar'
Could not find module 'Utility.Registry.V0.Configuration.Instrument'
Could not find module 'Utility.Registry.V0.Holding.TokenApiUtils'
Could not find module 'Utility.Registry.V0.Rule.Transfer'
```
These map to three DARs (versions taken from a reference project):
- `utility-registry-app-v0` (0.4.0)
- `utility-registry-v0` (0.4.0)
- `utility-registry-holding-v0` (0.1.2)
## What I've already tried
1. They are **not** in the public `hyperledger-labs/splice` `daml/dars` folder
(only the `splice-api-token-*` interface DARs are there).
2. They are **not** in the `decentralized-canton-sync` `splice-node.tar.gz`
release bundle (that ships Amulet + token-standard, not `utility-registry`).
3. The DA JFrog repo `digitalasset.jfrog.io/artifactory/canton-network-utility/`
returns **HTTP 401** without credentials.
## My questions
1. What is the correct/supported way to obtain the `utility-registry-app-v0`,
`utility-registry-v0`, and `utility-registry-holding-v0` DARs for **LocalNet**
development? Are they bundled with LocalNet/DPM somewhere, or do they require
DevNet onboarding / JFrog credentials?
2. Are these the right artifacts/versions for an SDK **3.4.11 / LF 2.1** build, or
is there a newer set I should target?
3. If they aren't publicly available, is the recommended approach to **implement my
own minimal token issuer** against the public `splice-api-token-burn-mint-v1`
interface for the LP token, rather than depending on `utility-registry`?
Any pointers (download location, credentials process, or the "build your own
issuer" pattern) would be hugely appreciated. Thanks!
Where did you come across this URL? That JFrog repo has not been used for quite some time.
The details on the latest MainNet Utilities dars are here
The MCP is still providing outdated information. I got this link from Claude, and I have already connected the DAML MCP that was provided by @Jatin_Pandya_cf .
Another thing, could you please clarify whether the setup I’m using in LocalNet is the same as DevNet? I’m a little confused about this. I am abut that utility dar file .
Report this to the MCP itself please by opening an github issue or discord(I assume we were doing it already so does’nt make sense here) not on forum.
Note - as said, this MCP is still connected to claude, so like all other MCPs, there will be instances where claude will pull data by itself which might be depreciated.
In those cases, reporting it on github would be best for the all.
ok sure ! Make sense i will report on Github !
@sanujit You won’t be able to replicate the full registry workflow on localnet as you will need a network with a running DA Registry to test fully → so on DevNet, TestNet, MainNet for full integration testing
That’s why I’ve slightly changed my learning path. My plan is to first create a token called NaiveToken. It will be a simple replica of what we use on MainNet. By that, I mean it will mimic the role of Amulet and the Utility Registry, which are used when dealing with real money .
For now, I’ll implement NaiveToken along with my own Mint, Burn, and Transfer choices. I think this will be a great way to learn and experiment on LocalNet and DevNet.
Later, when I move to TestNet, I can replace NaiveToken with Amulet and use the CC and Registry APIs for minting and burning operations instead of maintaining my own implementation.
Does this analogy and learning path make sense?