For context, I’m from Moonsong Labs, and we’re building a Canton vault management product for institutions to run in their own environment, so the parameter layer you describe is the one we have to operate. We’re closely following the vault standard and the operational layer around it.
I agree with the substance and direction. In essence, there is a clear opportunity to learn from these events and other ecosystem vault standard experiences to define Canton one.
I saw your comment in the OZ thread as well. Since the practical alignment is happening there, I’ll keep my higher-level points here:
-
I’d expect the socket from the standard, not the policy: the shape of a parameter update, with room for flexible per-asset and per-oracle policy modules to plug in. I echo your “this is why the interesting questions are interface questions”.
-
One concern regarding the operational layer is observability. Most vault risk tooling assumes anyone can watch, because it was designed for public chains. On Canton, a party only sees contracts it’s a stakeholder in, so the party that runs risk management and monitoring has to be defined up front and made an observer on the parameter contracts. Standardizing this setup will reduce integration friction across the ecosystem.
-
Vault standard design on Canton should rethink proven standards from other ecosystems to cater to institutional control, compliance, and privacy needs. As you mentioned, it should extend collateral to institutional assets that lack open-market pricing or rely on off-ledger workflows. Along these lines, two needs deserve first-class treatment: private access gating (a clear mechanism to control who can interact with the vault while keeping participants private from each other) and oracle and price update flexibility (institutions may need custom oracles for tokenized assets, as for example an issuer-attested NAV rather than a market feed).
@woof-software thanks for sparking this discussion!