Conversation
|
|
||
| pub mod shard_metadata; | ||
|
|
||
| pub const ZK_MINT_CW20_LABEL: &str = "zk_mint_cw20"; |
There was a problem hiding this comment.
are we actually minting a cw20 and not a token factory token?
There was a problem hiding this comment.
for the existing demo, yes. could migrate it to tf but cw20 was just faster given that the cw20 contract minter is the processor, so no additional libs were required.
| /// Valence verification gateway version | ||
| pub valence_version: String, |
There was a problem hiding this comment.
We don't have a verification gateway after the onchain zk flow refactor. We have a verification router that points towards verifiers/verification switches using routes. But I see that you have that in the Artifacts below, so I'm not sure what this field is for.
| pub authorization_labels: [String; MAX_ITEMS], | ||
|
|
||
| /// Route used by the verification gateway, e.g. | ||
| /// - ethereum/1.0.0/sp1/2.0.0 |
There was a problem hiding this comment.
nit: maybe provide the example of the format we are using? e.g. "0001/sp1/5.0.8/groth16"
There was a problem hiding this comment.
oh yeah perfect. also little question here, these versions are the only ones we have for the on-chain zk flow, right? wondering if this contains everything we need and we can just remove valence_version above
There was a problem hiding this comment.
yup, maybe the registry used? Each authorization has a VK and a registry, as each Circuit can create messages with different registries so we can have multiple functionality in the same circuit
3 participants
Description
First stab at the notion of shard metadata.