0xMiden/protocol
View on GitHubMove standards types from `miden-protocol` to `miden-standards`
Open
#2,214 opened on Dec 29, 2025
good first issueruststandards
Repository metrics
- Stars
- (123 stars)
- PR merge metrics
- (PR metrics pending)
Description
As a follow-up to #2197, I think we should move some types from miden-protocol to miden-standards. The main motivation is to have types that are likely going to be extended in the future in the standards crate rather than in the protocol crate. Additionally, the protocol crate is fairly large after #1563 and this makes it a bit leaner.
This applies to:
miden_protocol::asset::TokenSymbol- used as part of fungible faucet metadata, which are defined as miden standards.
miden_protocol::address- The
Addressis not something that is inherently a part of the protocol, but more like a tool for working with it. TheAddressInterfaceandRoutingParametersare meant to be extended through standardization and so it makes sense to have it in the standards crate. - Something to figure out here is how to make
AddressId::decodedelegate toAccountId::from_bech32_byte_iterwithout making types from thebech32crate part of our public API. This can probably be done fairly simply by changing the iterator parameter to animpl Iterator<Item = u8>.
- The
Edit: This was now integrated intomiden_protocol::account::component::AccountComponentMetadataAccountComponent.miden_protocol::account::auth::{AuthScheme, AuthSecretKey, PublicKey, Signature}.- These are less clear to me. They are used protocol-wide, and so one could argue that defining them in the protocol crate is fine. They are likely to be extended in the future with more standardized auth schemes, so it could make sense to move these to standards, or at least there should be no downside to doing so.
- This requires moving
AccountFileto standards as well, but that seems fine. If we do that, it probably also makes sense to moveNoteFile. - One issue is that
TransactionArgs::add_signaturerelies onSignature, and so moving these types would require a different solution here, like a trait or movingadd_signature(as an extension trait) itself to standards. I think the latter makes the most sense. - Even if we move this to standards, it should be fine to keep
miden_protocol::cryptore-exports.
- This requires moving
- These are less clear to me. They are used protocol-wide, and so one could argue that defining them in the protocol crate is fine. They are likely to be extended in the future with more standardized auth schemes, so it could make sense to move these to standards, or at least there should be no downside to doing so.
I think TokenSymbol and Address make sense to be moved. For the other two I'm less convinced, but would lean towards moving them.
If we decide to move these, each of these high-level bullet points should be done as a separate PR.