Flexible Minting Policies for Token Standards by onurinanc · Pull Request #2559 · 0xMiden/protocol

onurinanc · 2026-03-05T15:47:09Z

This PR corresponds to the discussion for Miden Token Standards, overall, it implements flexible and modular minting policies: OpenZeppelin/miden-confidential-contracts#39

Design specification related to this document: OpenZeppelin/miden-confidential-contracts#39 (comment)

Please see additional design discussion here: OpenZeppelin/miden-confidential-contracts#39 (reply in thread)

#! Distributes freshly minted fungible assets to the provided recipient.
#!
#! Invocation: call
pub proc distribute
   exec.mint_policies::enforce_mint_policy # previously -> exec.ownable::verify_owner
   # => [amount, tag, aux, note_type, execution_hint, RECIPIENT, pad(7)]

   exec.faucets::distribute
   # => [note_idx, pad(15)]
end

[ ] Left to-do: I would like to rename this procedure as pub proc mint as we have discussed with @bobbinth but I would like to double-check is there any other thoughts on this?

bobbinth

Looks good! Thank you! Not a full review yet - but I left some comments inline. The main comment so far is about splitting the component into a "policy manager" component and separate policy components (probably just a single policy component for now).

bobbinth · 2026-03-08T00:56:06Z

crates/miden-standards/asm/standards/mint_policies/mod.masm

+#!
+#! Invocation: exec
+proc assert_valid_policy_root
+    dupw exec.word::eqz


We could use word::testz procedure here to avoid the dupw.

bobbinth · 2026-03-08T00:56:23Z

crates/miden-standards/asm/standards/mint_policies/mod.masm

+    exec.active_account::get_map_item
+    # => [ALLOWED_FLAG, MINT_POLICY_ROOT]
+
+    dupw exec.word::eqz not


Same comment as above.

bobbinth · 2026-03-08T00:58:37Z

crates/miden-standards/asm/standards/mint_policies/mod.masm

+const MINT_POLICY_PROC_ROOT_SLOT=word("miden::standards::mint_policies::proc_root")
+const MINT_POLICY_PARAMS_SLOT=word("miden::standards::mint_policies::params")
+const MINT_POLICY_ALLOWED_ROOTS_SLOT=word("miden::standards::mint_policies::allowed_roots")
+const MINT_POLICY_PROC_ROOT_PTR=0


Would be good to add some comments explaining the purpose and expected formats of the storage slots. For example, it is not immediately clear what "allowed roots" means.

crates/miden-standards/asm/standards/mint_policies/owner_controlled.masm

crates/miden-standards/asm/standards/mint_policies/mod.masm

onurinanc · 2026-03-09T17:08:44Z

All done! Please review: @bobbinth

PhilippGackstatter

Looks good to me!

I left a few comments related to naming and structure, e.g. whether it should be MintPolicies or MintPolicyManager.

PhilippGackstatter · 2026-03-10T12:12:54Z

crates/miden-standards/asm/account_components/faucets/basic_fungible_faucet.masm

 # See the `BasicFungibleFaucet` Rust type's documentation for more details.

-pub use ::miden::standards::faucets::basic_fungible::distribute
+pub use ::miden::standards::faucets::basic_fungible::mint


That's a very welcome change 🙂

Since this does both minting (like miden::protocol::faucet::mint), but also creating a note, maybe we should consider mint_to_note as the name to reflect the note creation side effect in the name.

@PhilippGackstatter I think the intent of mint_to_note is good but instead what about having mint_and_create_note which semantically sounds better?

That's a bit more explicit and also a good choice. Another one might be mint_and_send (saw it in OpenZeppelin/miden-confidential-contracts#79 (comment)) which is a bit more concise but less explicit (does not mention note).

I like mint_and_send - though, not a very strong preference.

And, in a future PR, we could also add a regular mint procedure which mints an asset and adds it to the account's vault.

PhilippGackstatter · 2026-03-10T12:14:38Z

crates/miden-standards/asm/standards/faucets/basic_fungible.masm

-pub proc distribute
+pub proc mint
    exec.faucets::distribute


The faucets::distribute should probably also be renamed to mint, right?

PhilippGackstatter · 2026-03-10T12:20:51Z

crates/miden-standards/asm/standards/mint_policies/mod.masm

+#! - note sender is not owner.
+#!
+#! Invocation: dynexec
+pub proc mint_policy_owner_only


Nit: It might be sufficient to name this owner_only, since the module is called mint_policies already, so the module-qualified name would be mint_policies::owner_only which reads naturally.

PhilippGackstatter · 2026-03-10T12:22:35Z

crates/miden-standards/asm/standards/mint_policies/policy_manager.masm

+# Active policy root slot.
+# Layout: [proc_root_w0, proc_root_w1, proc_root_w2, proc_root_w3]
+const MINT_POLICY_PROC_ROOT_SLOT=word("miden::standards::mint_policies::proc_root")


Suggested change

# Active policy root slot.

# Layout: [proc_root_w0, proc_root_w1, proc_root_w2, proc_root_w3]

const MINT_POLICY_PROC_ROOT_SLOT=word("miden::standards::mint_policies::proc_root")

# Active policy root slot.

# Layout: [PROC_ROOT]

const MINT_POLICY_PROC_ROOT_SLOT=word("miden::standards::mint_policies::proc_root")

Nit: Avoid specifying the individual word elements.

PhilippGackstatter · 2026-03-10T12:56:10Z

crates/miden-standards/asm/standards/mint_policies/policy_manager.masm

+    exec.word::testz not
+    assert.err=ERR_MINT_POLICY_ROOT_NOT_ALLOWED
+    # => [ALLOWED_FLAG, MINT_POLICY_ROOT]
+
+    dropw
+    # => [MINT_POLICY_ROOT]


Nit: We can avoid the dropw by simplifying to word::eqz not assert (or assertz directly).

PhilippGackstatter · 2026-03-10T16:06:46Z

crates/miden-standards/src/account/faucets/mint_policies.rs

+#[derive(Debug, Clone, Copy)]
+pub struct MintPolicies {
+    initial_policy_root: Word,
+}


Should this be called MintPolicyManager and the mint_policies_library be renamed to mint_policy_manager_library along with crates/miden-standards/asm/account_components/faucets/mint_policies.masm?

I'd also suggest renaming MintPolicyConfig -> MintPolicy so we can "instantiate a mint policy manager with a mint policy".

PhilippGackstatter · 2026-03-10T16:13:42Z

crates/miden-standards/src/account/faucets/mint_policies.rs

+        let allowed_roots =
+            if mint_policies.initial_policy_root == MintPolicies::owner_only_policy_root() {
+                StorageMap::with_entries([(
+                    StorageMapKey::from_raw(MintPolicies::owner_only_policy_root()),
+                    Word::from([1u32, 0, 0, 0]),
+                )])
+            } else {
+                StorageMap::with_entries([
+                    (
+                        StorageMapKey::from_raw(MintPolicies::owner_only_policy_root()),
+                        Word::from([1u32, 0, 0, 0]),
+                    ),
+                    (
+                        StorageMapKey::from_raw(mint_policies.initial_policy_root),
+                        Word::from([1u32, 0, 0, 0]),
+                    ),
+                ])
+            }


Nit: Consider introducing a constant or variable that represents the "allowed flag" (word [1,0,0,0]).

PhilippGackstatter · 2026-03-10T16:19:46Z

crates/miden-testing/tests/scripts/faucet.rs

+    let mut rng = RpoRandomCoin::new([Felt::from(rng_seed); 4].into());
+    let note = NoteBuilder::new(sender_account_id, &mut rng)
+        .note_type(NoteType::Private)
+        .tag(NoteTag::default().into())
+        .serial_number(Word::from([rng_seed, rng_seed + 1, rng_seed + 2, rng_seed + 3]))
+        .code(note_script_code)
+        .build()?;


Suggested change

let mut rng = RpoRandomCoin::new([Felt::from(rng_seed); 4].into());

let note = NoteBuilder::new(sender_account_id, &mut rng)

.note_type(NoteType::Private)

.tag(NoteTag::default().into())

.serial_number(Word::from([rng_seed, rng_seed + 1, rng_seed + 2, rng_seed + 3]))

.code(note_script_code)

.build()?;

let mut rng = RpoRandomCoin::new([Felt::from(rng_seed); 4].into());

let note = NoteBuilder::new(sender_account_id, &mut rng)

.note_type(NoteType::Private)

.code(note_script_code)

.build()?;

Nit: The serial number is generated by the RNG internally and the note tag should already be set to its default by the builder.

The NoteBuilder can also compile a string itself so no need to use CodeBuilder above.

PhilippGackstatter · 2026-03-10T16:21:43Z

crates/miden-testing/tests/scripts/faucet.rs

+
+    let tx_context = mock_chain
+        .build_tx_context(faucet_id, &[], &[note])?
+        .add_note_script(note_script)


Suggested change

.add_note_script(note_script)

Nit: Haven't checked but this is likely unnecessary.

PhilippGackstatter · 2026-03-10T16:28:11Z

crates/miden-testing/tests/scripts/faucet.rs

+/// Tests owner minting on a network faucet built from two separate components:
+/// `NetworkFungibleFaucet` and `MintPolicies`.
+#[tokio::test]
+async fn test_network_faucet_owner_can_mint_with_separate_mint_policies_component()


Is this test effectively testing additional things than the other tests that use a network fungible faucet with MintPolicyConfig::OwnerOnly? I think it doesn't and if so, I'd remove it.

bobbinth

Looks good! Thank you! Not a full review still, but I left some comments inline.

crates/miden-standards/asm/standards/mint_policies/policy_manager.masm

bobbinth · 2026-03-12T00:25:56Z

crates/miden-standards/asm/standards/mint_policies/policy_manager.masm

+#! Enforces active mint policy by dynamic execution.
+#!
+#! Inputs:  [amount, tag, note_type, RECIPIENT, pad(9)]
+#! Outputs: [amount, tag, note_type, RECIPIENT, pad(9)]


I think the motivation here is that we create a note right after calling this procedure, and so, duplicating all note inputs would be a bit wasteful. I don't really have a strong preference here.

But it does make me think that this procedure is specifically related to sending notes. So, maybe the name here should reflect this? Something like enforce_mint_and_send_policy?

bobbinth · 2026-03-12T00:26:26Z

crates/miden-standards/asm/standards/mint_policies/policy_manager.masm

+#! - active policy predicate fails.
+#!
+#! Invocation: exec
+pub proc enforce_mint_policy


I actually don't mind enforce_ prefix, but also don't have anything against the execute_ prefix.

crates/miden-standards/asm/standards/mint_policies/policy_manager.masm

bobbinth · 2026-03-12T00:32:02Z

crates/miden-standards/src/account/faucets/network_fungible.rs

        .storage_mode(AccountStorageMode::Network)
        .with_auth_component(auth_component)
        .with_component(NetworkFungibleFaucet::new(symbol, decimals, max_supply, owner_account_id)?)
+        .with_component(MintPolicies::new(mint_policy_config))


Once we have the Ownable2Step component, we'd need to add it here too, right?

crates/miden-standards/src/account/faucets/basic_fungible.rs

crates/miden-standards/asm/standards/mint_policies/owner_controlled.masm

…nt-policies

onurinanc · 2026-03-12T20:45:47Z

Thank you for the review, all done! @bobbinth @PhilippGackstatter Please review.

bobbinth

Looks great! Thank you! I think we are pretty close. I left some more comments inline. The main one is about potentially making MintPolicyManager into a stand-alone component. We could also decide to do it in a follow-up PR to merge this PR sooner.

bobbinth · 2026-03-14T20:33:23Z

crates/miden-standards/asm/standards/faucets/mod.masm

 #! Invocation: exec
 @locals(4)
-pub proc distribute
+pub proc mint_and_send


nit: I'd probably update the comment on line 38 above a bit as well.

bobbinth · 2026-03-14T22:42:20Z

crates/miden-standards/asm/standards/mint_policies/policy_manager.masm

Not for this PR, but we should probably think about allowing updates to policy allowlist (i.e., adding or removing policies). Should be pretty easy to do - we'd probably need something like add_allowed_policy and remove_allowed_policy procedures.

I believe this would be a parallel work to upgradable/updatable contracts. The main reason is that, even if we provide adding/removing allowed policies, if the account code is not upgradable, this won't make any sense since the corresponding code won't be the part of the account. This is the main reason why I didn't include updating the allowed policies in this PR. That means, when upgrading the account code, the user can also update the allowed policies. So, I think that there is no need for updating the allowed policies.

bobbinth · 2026-03-14T22:45:17Z

crates/miden-standards/asm/standards/faucets/basic_fungible.masm

+    # Keep this procedure digest distinct from network_fungible::mint_and_send.
+    push.0 drop


Why do we need to do this?

@bobbinth The main problem is that when both NetworkFungibleFaucet and BasicFungibleFaucet have the same procedure digest (without having push.0 drop, both mint_and_send and burn will have the same procedure digests), and AccountComponentInterface::try_from is not able to differentiate those components, and we're having MissingNetworkFungibleFaucetInterface as the account component interface matches with BasicFungibleFaucet. We didn't have this problem before they produced different procedure digests. @PhilippGackstatter do you have any suggestion on this?

The first and the most basic solution is keeping the procedure digests different as adding push.0 drop
The second one is refactoring AccountComponentInterface

So, I would like to keep it simple for now, and you could potentially refactor the AccountComponentInterface

I think that's an okay workaround for now, as we plan to remove the AccountComponentInterface as it is and then this problem would naturally go away. It would be good to leave a TODO: Remove once AccountComponentInterface is refactored here, though.

bobbinth · 2026-03-14T22:47:12Z

crates/miden-standards/asm/standards/faucets/basic_fungible.masm

I would mention somewhere in the comments at the top of the file that this component requires the policy manager component to also be in the account.

bobbinth · 2026-03-14T22:47:41Z

crates/miden-standards/asm/standards/faucets/network_fungible.masm

Same comment as above re mentioning the policy manager dependency.

bobbinth · 2026-03-14T23:30:56Z

crates/miden-standards/asm/account_components/mint_policies/auth_tx_controlled.masm

+pub use ::miden::standards::mint_policies::auth_tx_controlled::allow_all
+pub use ::miden::standards::mint_policies::policy_manager::set_mint_policy
+pub use ::miden::standards::mint_policies::policy_manager::get_mint_policy


Same comment as above.

bobbinth · 2026-03-14T23:31:49Z

crates/miden-standards/src/account/faucets/network_fungible.rs

 pub fn create_network_fungible_faucet(
    init_seed: [u8; 32],
    symbol: TokenSymbol,
    decimals: u8,
    max_supply: Felt,
    access_control: AccessControl,
 ) -> Result<Account, FungibleFaucetError> {


Not for this PR, but we should probably make this take TokenMetadata instead of passing in symbol, decimals, and max_supply separately.

I think TokenMetadata PR should address this one but if not I'll be addressing in the follow-up PR.

bobbinth · 2026-03-14T23:33:31Z

crates/miden-standards/src/account/faucets/network_fungible.rs

@@ -300,6 +301,7 @@
        .with_auth_component(auth_component)
        .with_component(NetworkFungibleFaucet::new(symbol, decimals, max_supply)?)
        .with_component(access_control)


Before getting here, we should validate that access_control is Ownable2Step. I know this is the only variant right now, but as we add variants in the future, this could change. And since we here depend on Ownable2Step - we should make sure we check it.

bobbinth · 2026-03-14T23:37:59Z

crates/miden-standards/src/account/mint_policies/owner_controlled.rs

+                .with_description(
+                    "Mint policy owner controlled component for network fungible faucets",
+                )
+                .with_storage_schema(storage_schema);


In other places, we started to encapsulate this into a separate method. For example, here it could be:

impl OwnerControlled { pub fn component_metadata() -> AccountComponentMetadata { let storage_schema = StorageSchema::new(vec![ OwnerControlled::active_policy_proc_root_slot_schema(), OwnerControlled::allowed_policy_proc_roots_slot_schema(), OwnerControlled::policy_authority_slot_schema(), ]) .expect("storage schema should be valid"); AccountComponentMetadata::new(OwnerControlled::NAME, [AccountType::FungibleFaucet]) .with_description( "Mint policy owner controlled component for network fungible faucets", ) .with_storage_schema(storage_schema); } }

And then here, this becomes just:

let metadata = OwnerControlled::component_metadata();

bobbinth · 2026-03-14T23:40:32Z

crates/miden-standards/src/account/mint_policies/auth_tx_controlled.rs

+pub struct AuthTxControlled {
+    initial_policy_root: Word,
+}


I'm wondering if the naming here is accurate - specifically the AuthTx part. Technically, we have authentication procedures - so, this could be AuthProcControlled - but I wonder if just AuthControlled is sufficient.

I don't think AuthTxControlled constitutes a good naming but all the naming of the auth component account starts with pub proc auth_tx. However, AuthControlled would be a candidate since the owner-controlled one is basically NoAuth. But, there is also current change, which we specify the auth component procedures as @authscript, so maybe AuthScriptControlled, so I've found naming this one quite confusing.
CC: @PhilippGackstatter

PhilippGackstatter

Looks good to me!

I'll approve since most of my comments apply to follow-ups.

PhilippGackstatter · 2026-03-16T14:26:39Z

crates/miden-standards/asm/account_components/mint_policies/owner_controlled.masm

+pub use ::miden::standards::mint_policies::owner_controlled::owner_only
+pub use ::miden::standards::mint_policies::policy_manager::set_mint_policy
+pub use ::miden::standards::mint_policies::policy_manager::get_mint_policy


Generally agreed that it seems better to have a base MintPolicyManager component that can be extended in plug & play fashion with additional mint policy components.

Not a strong opinion whether we should do it in this PR or later.

PhilippGackstatter · 2026-03-16T14:32:00Z

crates/miden-standards/asm/standards/faucets/network_fungible.masm

+pub proc mint_and_send
+    exec.policy_manager::execute_mint_policy
+    # => [new_amount, new_tag, new_note_type, NEW_RECIPIENT, pad(9)]

-    exec.faucets::distribute
+    exec.faucets::mint_and_send
    # => [note_idx, pad(15)]
 end


The code of NetworkFungibleFaucet and BasicFungibleFaucet is now identical, so I think we should collapse these into just one type, i.e. BasicFungibleFaucet.

The difference between a network and a "local" faucet is now just a different configuration of the overall account, but the distinction no longer exists at the account component level, and so we don't need different code and account components.

If agreed, we should create an issue as a follow-up. This could also make the token metadata #2439 simpler.

Overall, I agree we should address this issue, but I'm not sure if we should to this in a follow-up PR or wait a bit more if there would be a specific needs for the NetworkFungibleFaucet in the future so that we don't need to re-implement it again.

PhilippGackstatter · 2026-03-16T14:35:58Z

crates/miden-standards/asm/standards/mint_policies/policy_manager.masm

+
+# Allowlist map slot for policy roots.
+# Map entries: [PROC_ROOT] -> [1, 0, 0, 0]
+# This slot ensure `dynexec` runs only allowed mint-policy roots, not arbitrary procedures.


Suggested change

# This slot ensure `dynexec` runs only allowed mint-policy roots, not arbitrary procedures.

# This slot ensures the policy manager runs only allowed mint-policy roots, not arbitrary procedures.

Nit: I'd rephrase this

PhilippGackstatter · 2026-03-16T14:37:49Z

crates/miden-standards/asm/standards/mint_policies/policy_manager.masm

+const ALLOWED_POLICY_PROC_ROOTS_SLOT=word("miden::standards::mint_policy_manager::allowed_policy_proc_roots")
+
+# Policy authority slot.
+# Layout: [POLICY_AUTHORITY, 0, 0, 0]


Suggested change

# Layout: [POLICY_AUTHORITY, 0, 0, 0]

# Layout: [policy_authority, 0, 0, 0]

Nit: felts are lowercase

PhilippGackstatter · 2026-03-16T14:41:07Z

crates/miden-standards/asm/standards/mint_policies/policy_manager.masm

+    exec.word::testz
+    assertz.err=ERR_MINT_POLICY_ROOT_NOT_ALLOWED
+    # => [ALLOWED_FLAG, MINT_POLICY_ROOT]
+
+    dropw
+    # => [MINT_POLICY_ROOT]


Nit: This could be word::eqz assertz to avoid the dropw.

PhilippGackstatter · 2026-03-16T15:09:01Z

crates/miden-standards/asm/standards/mint_policies/policy_manager.masm

+#!
+#! Invocation: exec
+@locals(4)
+pub proc execute_mint_policy


This procedure validates the mint policy, but get_mint_policy does not. Depending on the perspective, both are valid approaches:

We can say that since set_mint_policy validates the procedure when setting, so the stored mint policy is valid.

The only exception to the above is that the account deployer could set an invalid root, and so we could also say that we should always validate the mint policy on retrieval.

So far, I think we have usually used the first approach, though this was mostly for component-internal data. I'm not sure how much damage a malicious deployer could do by setting an invalid mint policy root, probably not much other than making their own account unusable, so I'd go with approach 1.

This makes me wish we could let every account component have some on-chain validation of its storage at account creation time so we could always go with the first approach and provide stronger guarantees.

I think this is a good point! I agree that we would have stronger guarantees with on-chain validation, but it also adds more complexity for account creation, and this also needs an execution order design and rules between the other account components. I'm not exactly sure which one is the right direction.

PhilippGackstatter · 2026-03-16T15:12:30Z

crates/miden-standards/src/account/faucets/basic_fungible.rs

        // [num_trigger_procs, allow_unauthorized_output_notes, allow_unauthorized_input_notes, 0].
        //
-        // With 1 trigger procedure (distribute), allow_unauthorized_output_notes=false, and
+        // With 1 trigger procedure (mint), allow_unauthorized_output_notes=false, and


Suggested change

// With 1 trigger procedure (mint), allow_unauthorized_output_notes=false, and

// With 1 trigger procedure (mint_and_send), allow_unauthorized_output_notes=false, and

PhilippGackstatter · 2026-03-16T15:12:51Z

crates/miden-standards/src/account/faucets/basic_fungible.rs


-        // The procedure root map should contain the distribute procedure root.
-        let distribute_root = BasicFungibleFaucet::distribute_digest();
+        // The procedure root map should contain the mint procedure root.


Suggested change

// The procedure root map should contain the mint procedure root.

// The procedure root map should contain the mint_and_send procedure root.

PhilippGackstatter · 2026-03-16T15:20:30Z

crates/miden-standards/src/account/mint_policies/auth_controlled.rs

+        let policy_authority_slot = StorageSlot::with_value(
+            AuthControlled::policy_authority_slot().clone(),
+            Word::from([0u32, 0, 0, 0]),
+        );


I think we should introduce an enum for the policy authority, because it's otherwise hard to understand which zero represents the actual config and what that zero represents. Something like:

#[repr(u8)] pub enum MintPolicyAuthority { AuthControlled = 0, OwnerControlled = 1, } impl From<MintPolicyAuthority> for StorageSlot { ... } impl AuthControlled { pub fn mint_policy_authority(&self) -> MintPolicyAuthority { MintPolicyAuthority::AuthControlled } }

And then here we'd have:

let policy_authority_slot = StorageSlot::from(auth_controlled.mint_policy_authority);

PhilippGackstatter · 2026-03-16T15:22:31Z

crates/miden-standards/src/account/mint_policies/owner_controlled.rs

+static ACTIVE_MINT_POLICY_PROC_ROOT_SLOT_NAME: LazyLock<StorageSlotName> = LazyLock::new(|| {
+    StorageSlotName::new("miden::standards::mint_policy_manager::active_policy_proc_root")
+        .expect("storage slot name should be valid")
+});
+static ALLOWED_MINT_POLICY_PROC_ROOTS_SLOT_NAME: LazyLock<StorageSlotName> = LazyLock::new(|| {
+    StorageSlotName::new("miden::standards::mint_policy_manager::allowed_policy_proc_roots")
+        .expect("storage slot name should be valid")
+});
+static POLICY_AUTHORITY_SLOT_NAME: LazyLock<StorageSlotName> = LazyLock::new(|| {
+    StorageSlotName::new("miden::standards::mint_policy_manager::policy_authority")
+        .expect("storage slot name should be valid")
+});


These definitions are duplicated in crates/miden-standards/src/account/mint_policies/auth_controlled.rs, would be great to deduplicate, but also fine to do as part of the MintPolicyManager refactor.

The "miden::standards::mint_policy_manager::policy_authority" slot could be defined on the previously proposed MintPolicyAuthority enum.

…nt-policies

onurinanc · 2026-03-16T17:09:01Z

All done! The corresponding issues for the follow-up PRs are opened! @bobbinth @PhilippGackstatter

onurinanc added 2 commits March 5, 2026 10:31

add mint_policies

300aece

add mint_policy_owner_only_per_cap

b22d4f3

bobbinth requested review from PhilippGackstatter, bobbinth and mmagician and removed request for PhilippGackstatter and mmagician March 6, 2026 06:03

bobbinth reviewed Mar 8, 2026

View reviewed changes

onurinanc added 3 commits March 9, 2026 13:46

add ownable2step

2a0aeb6

merge upstream/next

5de4a82

merge

6f1d526

onurinanc mentioned this pull request Mar 9, 2026

Make Ownable2Step an account component #2570

Closed

3 tasks

onurinanc added 5 commits March 9, 2026 16:51

separate mint policies and policy manager

2add1a5

Merge remote-tracking branch 'upstream/next' into onur-mint-policies

51f5900

fix

a96e0bd

fix

f6282ba

rename distribute to mint

6ba27ca

onurinanc requested a review from bobbinth March 9, 2026 17:08

Merge branch 'next' into onur-mint-policies

6768626

PhilippGackstatter reviewed Mar 10, 2026

View reviewed changes

bobbinth reviewed Mar 12, 2026

View reviewed changes

onurinanc added 6 commits March 12, 2026 10:34

fix comments

e5e1809

prep merge

d2de23c

merge next

89f1716

merge

ecb8e35

Merge remote-tracking branch 'origin/onur-mint-policies' into onur-mi…

be94473

…nt-policies

rename as mint_and_send

5dc6b6d

onurinanc added 8 commits March 12, 2026 18:44

fmt

c053466

add owner controlled

00dcca7

add auth_tx_controlled

4ba4304

refactor

f9a5e17

typo

dc52903

fix name

688d7c4

typo

89cd101

typo

984c02d

onurinanc requested review from PhilippGackstatter and bobbinth March 12, 2026 20:48

onurinanc and others added 2 commits March 12, 2026 23:11

fix tests

c643c9c

Merge branch 'next' into onur-mint-policies

36b760e

bobbinth reviewed Mar 14, 2026

View reviewed changes

onurinanc mentioned this pull request Mar 16, 2026

Token Metadata extension to form standard #2439

Open

fix reviews

f8be317

onurinanc mentioned this pull request Mar 16, 2026

Make MintPolicyManager into a stand-alone component OpenZeppelin/miden-confidential-contracts#84

Open

onurinanc added 2 commits March 16, 2026 12:45

rename AuthTxControlled -> AuthControlled

602d17e

rerun ci

b66aeff

onurinanc requested a review from bobbinth March 16, 2026 11:53

PhilippGackstatter approved these changes Mar 16, 2026

View reviewed changes

onurinanc added 3 commits March 16, 2026 16:31

Merge branch 'next' into onur-mint-policies

0b6089a

fix comments

4b3aef5

Merge remote-tracking branch 'origin/onur-mint-policies' into onur-mi…

baa1750

…nt-policies

onurinanc mentioned this pull request Mar 16, 2026

Consider unifying BasicFungibleFaucet and NetworkFungibleFaucet OpenZeppelin/miden-confidential-contracts#85

Open

apply comments

9fdd4e2

onurinanc requested a review from PhilippGackstatter March 16, 2026 17:09

		# Keep this procedure digest distinct from network_fungible::mint_and_send.
		push.0 drop

	# This slot ensure `dynexec` runs only allowed mint-policy roots, not arbitrary procedures.
	# This slot ensures the policy manager runs only allowed mint-policy roots, not arbitrary procedures.

	# Layout: [POLICY_AUTHORITY, 0, 0, 0]
	# Layout: [policy_authority, 0, 0, 0]

	// With 1 trigger procedure (mint), allow_unauthorized_output_notes=false, and
	// With 1 trigger procedure (mint_and_send), allow_unauthorized_output_notes=false, and

	// The procedure root map should contain the mint procedure root.
	// The procedure root map should contain the mint_and_send procedure root.

Conversation

onurinanc commented Mar 5, 2026

Uh oh!

bobbinth left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

onurinanc commented Mar 9, 2026

Uh oh!

PhilippGackstatter left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bobbinth Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bobbinth left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

onurinanc commented Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bobbinth left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

onurinanc Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bobbinth Mar 12, 2026 •

edited

Loading

onurinanc commented Mar 12, 2026 •

edited

Loading

onurinanc Mar 16, 2026 •

edited

Loading

onurinanc Mar 16, 2026 •

edited

Loading