Pausable by onurinanc · Pull Request #2793 · 0xMiden/protocol

onurinanc · 2026-04-20T10:07:11Z

Closes issue including the design discussion provided here: #2241

This PR adds a Pausable component without Access Control mechanism included as we split this work into small PRs.

In the next PRs, we'll integrate the following features:

Pausing is controlled by the owner.
Pausing is controlled by some role in an RBAC setup.

Related Issues:

Implement Pausable Component OpenZeppelin/miden-confidential-contracts#101

bobbinth

Looks good! Thank you! I left just a few questions/comments inline.

bobbinth · 2026-04-26T02:36:23Z

+#! This procedure does not verify the caller. Wrap with access control in the account component
+#! composition if only privileged accounts should pause.


This will be changed in a follow-up PR, right? (i.e., we'll have owner-based or RBAC-based checks)

I think this comment won't be changed but instead, owner-based and RBAC-based checks will include their own assertions using this procedure or with a policy manager if we also want to include dyncall here similar to blocklistable (transfer_controls), but I think we somehow need to treat both transfer_controls through blocking specific accounts, pausing the global accounts, and transfer amount restrictions as they all need to be included in the same callback.

But, I believe, for Pausable, we have decided to go with the Approach 2, or should we switch to Approach 3? #2241 (comment)

I think I don't yet understand how we want to expose these procedures. Are pause and unpause supposed to be called by trusted code, i.e. exposed through other public account procedures? If so, we shouldn't export them from crates/miden-standards/asm/account_components/utils/pausable.masm because that would allow anyone to call these without authentication.

I assume we want to define something like:

pub proc pause_with_role exec.active_note::get_sender push.PAUSER_ROLE_SYMBOL exec.::miden::standards::access::role_based_access_control::has_role assert.err="sender does not have the pauser role" exec.::miden::standards::utils::pausable::pause end

The nice thing is that the pause impl itself is define in standards and can be extended with various auth mechanisms. The downside is that this procedure would have a MAST root specific to the RBAC implementation, and another implementation using ownable would have a different MAST root. So to pause a network account, we'd need to have distinct PAUSE_RBAC and PAUSE_OWNABLE network note types.

If we want stable MAST roots to enable a single PAUSE note to work for all impls, we probably need dyncalls as mentioned in approach C in #2241 (comment). The main question is where we want to have the complexity, in the pausable implementation (dynamic execution) or on the user side (clients need to handle multiple pause notes). It's probably better to bite the bullet and make it simpler for users, and it would work consistently with the other MINT and BURN note types we have.

I guess we'd need another PausePolicyManager, but since we're considering a unified TokenPolicyManager (#2821 (comment)), it likely makes sense to include the pause functionality in that manager, too.

crates/miden-standards/asm/account_components/utils/pausable.masm because that would allow anyone to call these without authentication.

That's a good point, so I think pausable.masm should be a module rather than providing an account component for it (for now before pausable with Ownable2Step and RBAC), and removing it as an account component and adding the component as a test script makes sense.

Other than that, I think your point is to implement approach C as we also talk in this comment as a part of TokenPolicyManager #2821 (comment).

But, the main issue with merging MASM files specified in approach 2 in my comment here: #2821 (comment) and your comment here: #2821 (comment) that we might also need a TransferControlPolicyManager (Blocklistable) as a part of this PR, too: #2820 (comment). Or, there might be other modules needs to be included here, too, in the future.

So, I'm not actually sure if the dyncall is the correct approach for "transfer control" (blocklistable) or "pausable", I think we need to provide modules and user needs to implement its policies at some point. (I'm not sure what's the correct way right now but I'll be trying to come up with a better solution)

Ah - makes sense! I should read some comments more carefully. So, the idea is that in a follow-up PR account_components/utils/pausable.masm would go away and instead we'll have something like OwnerPausable and RbacPausable components - right?

One thing I just realized is that having different components for pausable access control would imply that we'd need different notes to invoke the right set of procedures on each. Not a big deal (especially if the number of such components is small) - but something to be aware of.

I think we have bunch of PRs open but in case of the workflow is not clear as expected I've prepared how workflow would be:

Current Workflow for Stablecoin and Access Control:

Extraction (Main PR): refactor: Extract Mint and Burn PolicyManager into their own component #2821

RBAC (Main PR): feat(standards): add Role Based Access Control Account Component #2712

Pausable: Pausable #2793

Blocklistable (Account Freezing): feat(standards): add Blocklistable component for per-account freezing #2820

Core PRs:

Extraction and RBAC are the foundational PRs that the rest of the work will build on:

Extraction: Introduces TokenPolicyManager (mint/burn combination).

RBAC: A new access control mechanism built on top of Ownable2Step.

Once these two are merged, they will serve as the foundation for everything that follows.

Plan After Merging the Foundation PRs
Pausable

Merging the Pausable PR largely as-is, without using dyncall. We'll extract the pausable logic out of the account components, and for testing purposes, implement this account component inside scripts.

Pausable follow-ups - implement the following as account components:

PausableOwnable2Step

PausableRbac

Blocklistable
We are not merging this PR yet. Once the Extraction PR is merged, we'll rework its architecture as follows:

Add transfer to TokenPolicyManager.

Add the on_before_asset_added_to_account and on_before_asset_added_to_note callbacks into TransferPolicyManager. These callbacks will execute execute_transfer_policy.

Introduce two owner-controlled transfer policies:

allow_all

transfer_if_not_blocked

The active policy will be invoked via dyncall inside execute_transfer_policy:

allow_all → no-op

transfer_if_not_blocked → executes assert_not_in_blocklist

After Pausable is added:

Extend the owner-controlled transfer policies described above:

transfer_if_not_paused → executes assert_not_paused

transfer_if_not_paused_and_not_blocked → executes both assert_not_in_blocklist and assert_not_paused

After RBAC is added:

mint and burn → RBAC-controlled

transfer → RBAC-controlled

more Policies → RBAC-controlled

CC: @bobbinth @PhilippGackstatter

All makes sense! Thank you for writing this up, @onurinanc!

bobbinth · 2026-04-26T03:52:17Z

+pub proc on_before_asset_added_to_account
+    exec.assert_not_paused
+    # => [ASSET_KEY, ASSET_VALUE, pad(8)]
+
+    dropw
+    # => [ASSET_VALUE, pad(12)]
+end
+
+#! Callback when a callbacks-enabled asset is added to an output note.
+#!
+#! Panics if this faucet account is paused.
+#!
+#! Inputs:  [ASSET_KEY, ASSET_VALUE, note_idx, pad(7)]
+#! Outputs: [ASSET_VALUE, pad(12)]
+#!
+#! Invocation: call
+pub proc on_before_asset_added_to_note


Why do we need these callbacks here? I was imagining that they'd be defined in more specific contexts (e.g., in regulated stablecoin).

Correct, I've added them initially for testing purposes, but now, I've added a MockPausableCallback component which includes these two callback procedures, and removed them here.

@onurinanc FYI The callbacks are still present in the latest version.

@PhilippGackstatter thank you for the comment, what I meant from the MockPausableCallback is that, instead of having on_before_asset_added_to_account and on_before_asset_added_to_note callbacks as a part of the pausable.masm component, I've created a mock component for testing purposes instead using pausable.masm by adding those 2 callbacks.

bobbinth

Looks good! Thank you! I left a couple of comments inline - but overall, as you've outlined, I'd come back to this PR after we get the core PRs merged (i.e., the RBAC and mint/burn token policies).

I would maybe even come back to this after we've implemented transfer policies and merged fungible faucets into a single component. I think the overall structure would be much more clear then.

bobbinth · 2026-05-02T08:04:42Z

+pub use ::miden::standards::utils::pausable::is_paused
+pub use ::miden::standards::utils::pausable::pause
+pub use ::miden::standards::utils::pausable::unpause


I'm not sure pause and unpause should be included here. As @PhilippGackstatter mentioned in one of the comments, these are not meant to be used externally (i.e., they are to be invoked only by other components deployed within the same account) - and so, shouldn't be a part of the "external" interface.

bobbinth · 2026-05-02T08:06:21Z

+#! Invocation: call
+pub proc pause


Related to the above comment, I think pause (and unpause) should be invokable via the exec instruction rather than the call instruction because they are meant only for internal use.

onurinanc · 2026-05-19T11:06:44Z

I think the current implementation of this PR is closer to the approach specified here: #2862 (comment)

bobbinth

Thank you! Not a review yet, but I left one question inline about potentially using a different approach.

Also, "pausing" a faucet in my mind could imply two things:

Pausing transfers of all assets issued by the faucet (only possible for assets that enable callbacks).
Pausing minting of new assets.

I believe this PR addresses the first point but not the second. Should we cover both points under the same "pause" functionality? Or should we have distinct procedures for pause_transfers, pause_minting, and pause_transfers_and_minting?

Lastly, it may be good to follow the pattern described in #2862 (comment) - though, if we are using transfer/mint policies to control pausing/unpausing - there wouldn't be a distinct "pauser" role.

bobbinth · 2026-05-20T05:31:16Z

+    /// Active policy = [`BasicPausable::root`]. Resolves into a [`BasicPausable`] component that
+    /// starts unpaused; to seed an initial paused state, install [`BasicPausable`] explicitly
+    /// via [`BasicPausable::paused`] and select the policy via [`TransferPolicy::Custom`] with
+    /// [`BasicPausable::root`].
+    Pausable,
+    /// Active policy = [`PausableBlocklist::root`]. Resolves into a [`PausableBlocklist`]
+    /// component that starts unpaused and with no initially blocked accounts; to seed either
+    /// state, install [`PausableBlocklist`] explicitly via
+    /// [`PausableBlocklist::with_initial_pause_state`] /
+    /// [`PausableBlocklist::with_initial_blocked_accounts`] and select the policy via
+    /// [`TransferPolicy::Custom`] with [`PausableBlocklist::root`].
+    PausableBlocklist,


Do we actually need these variants? IIUC, the functionality we want is to have the ability to pause all asset transfers for a given faucet. If so, this could probably be achieved with something like DenyAll policy that will error out on any asset transfer.

If the owner of the faucet would want to pause all transfers, they would be able to set the active transfer policies to DenyAll, and then, if they want to unpause, they set the active transfer policy to something else.

So, it seems to me that adding something like DenyAll transfer policy should be sufficient - but maybe I'm missing something?

If the owner of the faucet would want to pause all transfers, they would be able to set the active transfer policies to DenyAll, and then, if they want to unpause, they set the active transfer policy to something else.

Do you mean if they want to switch to another policy component in this part: "if they want to unpause"?

The main reason why we have this variants is an account should be able to choose which policy checks they want to include in their code.

For example,

if a user wants to use all checks they can add the DenyAll policy check component, which uses pausable, blocklist, allowlist.

if a user doesn't want to include allowlist in their account, they can just add PausableBlocklist transfer policy check component into their account, which doesn't include allowlist checks but include pausable and blocklist checks.

if a user wants to include both DenyAll and PausableBlocklist they can switch to one of them later. by set_{send/receive}_policy

onurinanc · 2026-05-20T11:58:20Z

Thank you @bobbinth for the comments.

Also, "pausing" a faucet in my mind could imply two things:

Pausing transfers of all assets issued by the faucet (only possible for assets that enable callbacks).

Pausing minting of new assets.

I believe this PR addresses the first point but not the second.

I think we should also include burning assets to this list as third item. I was thinking about handling 2 and 3 by adding new mint/burn policies but it's also fine to me to add this features in this PR.

Or should we have distinct procedures for pause_transfers, pause_minting, and pause_transfers_and_minting?

I believe pausing is an emergency situation so it should be just one pause operation to prevent users from the misuse. However, I think your consideration is that what happens if a user wants to extend it to a specific procedure such as withdraw/deposit ?

For the concept of stablecoin, cross-chain bridging, NFTs, I consider Pausable as a global pause / emergency pause functionality, which I believe this would be enough.

For some defi protocols such as staking and lending, pause might be needed for specific procedures such as in addition to mint and transfer, borrow might be needed to be paused (as global pause still satisfies this) but withdraw might be unpaused, for example.

bobbinth · 2026-05-21T08:11:33Z

I think we should also include burning assets to this list as third item.

Agreed.

For the concept of stablecoin, cross-chain bridging, NFTs, I consider Pausable as a global pause / emergency pause functionality, which I believe this would be enough.

Agreed here as well. So, the Pausable component would hold a storage slot with is_paused flag, and I think other components can make use of it or not - depending on their specific needs. So, for the faucet, we'd want to pause, mint, burn, and transfer functions, and maybe also pause updates for the component metadata?

I've also been thinking about how to implement this in the "least intrusive" way. For mint and burn, this should be pretty easy.

Specifically, we should be able to avoid introducing any new policies and handle the check at the TokenPolicyManager level. Specifically, we could modify execute_mint_policy and execute_burn_policy to do the following:

First check if the miden::standards::utils::pausable::is_paused slots exists in the account.
If not, nothing to do - and execution continues as now.
If yes, read the flag value from the slot, and act accordingly.

For transfers, we can't use the same pattern because use use the callback slots to directly store the policy procedure roots. But I do wonder if instead of introducing new policy variants (e.g., "pausable blocklist"), we could add an extra layer of indirection and make it work more similar to the mint/burn policies. The approach could be:

When relevant, we store the roots of execute_send_policy and execute_receive_policy procedures in the corresponding protocol-defined slots.
These procedures, would perform the pausable check described above, and then would read the roots of actual policy procedures from different storage slots, and execute them.

This would require two extra storage slots, and an extra call indirection - but maybe that's worth it.

bobbinth

Looks good! Thank you! I reviewed mostly non-test code and left some comments inline. In the interest of getting this merged sooner, I think we should only address the simple comments here, and leave the bigger ones to a follow-up PR.

The follow-ups would include:

Using active_account::has_storage_slot procedure to figure out if the is_paused storage slot is installed in an account. This procedure first needs to be added to the transaction kernel.
Adding a level of indirection to the transfer policy handlers so that we could control them from the TokenPolicyManager (similar to how we control mint/burn policies).

bobbinth · 2026-05-21T22:29:15Z

+#! If the `IS_PAUSED_SLOT` is not installed on the account, `active_account:: get_item` 
+#! returns the zero word, which is treated as "unpaused" — so the assertion is a no-op
+#! for accounts that did not install the Pausable component. This is the canonical way for
+#! cross-cutting consumers (TokenPolicyManager dispatch, asset callbacks, metadata setters) to
+#! gate their logic on pause state without making Pausable a hard dependency.


Is the behavior described here correct? The docs for active_account::get_item say that it should panic if the requested storage slot does not exist. cc @PhilippGackstatter

If active_account::get_item does not panic on non-existent storage slot, that's a bug and we should fix it (let's open an issue for this).

If it does panic, the we should update the logic here, but AFACT, we actually don't have something like active_account::has_storage_slot. I think we should add it and then based this procedure on that. But I would do it in a separate PR.

The documented behavior should be correct, get_item panics on unknown slots. test_account_get_item_fails_on_unknown_slot tests that.

The idea is that, because assert_not_paused is used so pervasively, we don't want to force every faucet to explicitly set that slot, if they don't use pause functionality? I guess that's fine, though being explicit about it also has its own value. I'd lean towards being explicit, but not a strong opinion.

The has_storage_slot functionality may be interesting independently, though I'd add it when we need it.

I think this is more about implied dependencies. Without the extra check, TokenPolicyManager will require Pausable as a dependency. So, anyone deploying a faucet would need to also add the Pausable component to their account, even if they don't need this functionality.

bobbinth · 2026-05-21T22:36:59Z

        let mut slots: Vec<StorageSlot> = Vec::new();
        slots.push(self.token_config_slot_value());
        slots.extend(self.metadata.into_storage_slots());
+        slots.push(crate::account::pausable::PausableStorage::default().into_slot());


Why do we need to do this via the FungibleFaucet component rather than via the Pausable component?

bobbinth · 2026-05-21T22:40:57Z

 #!
 #! Invocation: call
 pub proc check_policy
+    exec.pausable::assert_not_paused


This is fine for now, but I still think we should consider the approach I've described in #2793 (comment). The main reason is that with the current approach, developers will need to make sure add this assertion to all future policies, and that may be something easy to miss. Handling it at a PolicyManager level removes this potential footgun.

But let's not do this in this PR and instead create an issue.

bobbinth · 2026-05-21T22:46:18Z

+pub struct PausableStorage {
+    initial_state: bool,
+}


I would rename initial_state to just state as we should be able to instantiate PausableStorage from existing accounts too.

bobbinth · 2026-05-21T22:48:05Z

+    /// Creates a [`PausableStorage`] starting unpaused.
+    pub const fn new() -> Self {
+        Self { initial_state: false }
+    }
+
+    /// Creates a [`PausableStorage`] with the given initial pause state.
+    pub const fn with_initial_state(initial_state: bool) -> Self {
+        Self { initial_state }
+    }


I would get rid of the current new() constructor (the Default implementation does the same thing), and would rename with_initial_state() to new().

bobbinth · 2026-05-21T22:51:38Z

+    pub fn build_word(&self) -> Word {
+        if self.initial_state {
+            Word::from([1u32, 0, 0, 0])
+        } else {
+            Word::default()
+        }
+    }


nit: I would rename this to to_word().

bobbinth · 2026-05-21T22:52:46Z

+pub struct Pausable {
+    initial_state: bool,
+}


Same comment as above: I'd rename initial_state into state.

PhilippGackstatter

Looks good to me! Left a few comments, nothing blocking.

I agree with the follow-up of moving the assert_not_paused into the token policy manager. Pause functionality seems to be quite fundamental, so making the manager pause-aware makes sense to me.

PhilippGackstatter · 2026-05-22T06:30:00Z

I think utils is a category we should avoid because it is so generic. Even if it doesn't fit perfectly, I'd rather move this module into access. Pausing is a form of global access control, so it fits at least a bit.

PhilippGackstatter · 2026-05-22T06:57:51Z

+#! If the `IS_PAUSED_SLOT` is not installed on the account, `active_account:: get_item` 
+#! returns the zero word, which is treated as "unpaused" — so the assertion is a no-op
+#! for accounts that did not install the Pausable component. This is the canonical way for
+#! cross-cutting consumers (TokenPolicyManager dispatch, asset callbacks, metadata setters) to
+#! gate their logic on pause state without making Pausable a hard dependency.


The documented behavior should be correct, get_item panics on unknown slots. test_account_get_item_fails_on_unknown_slot tests that.

The idea is that, because assert_not_paused is used so pervasively, we don't want to force every faucet to explicitly set that slot, if they don't use pause functionality? I guess that's fine, though being explicit about it also has its own value. I'd lean towards being explicit, but not a strong opinion.

The has_storage_slot functionality may be interesting independently, though I'd add it when we need it.

PhilippGackstatter · 2026-05-22T07:01:41Z

+/// - [`Self::is_paused_slot()`]: single word; the zero word means unpaused, `[1, 0, 0, 0]` means
+///   paused. Any non-zero word is interpreted as paused by the MASM helpers.
+#[derive(Debug, Clone, Copy, Default)]
+pub struct PausableStorage {


Iiuc, we only use this in Pausable, so why is this a separate type? I have the same question about BasicBlocklist and BlocklistStorage.

If it must be a separate type, I'd redefine Pausable(PausableStorage), unless that creates issues.

PhilippGackstatter · 2026-05-22T07:05:06Z

+// ================================================================================================
+
+#[tokio::test]
+async fn pausable_manager_pause_succeeds_when_owner_signs() -> anyhow::Result<()> {


Suggested change

async fn pausable_manager_pause_succeeds_when_owner_signs() -> anyhow::Result<()> {

async fn pausable_manager_pause_succeeds_when_sender_is_owner() -> anyhow::Result<()> {

I don't think the owner signs here?

PhilippGackstatter · 2026-05-22T07:09:14Z

+    let mut rng =
+        RandomCoin::new(Word::from([1u32, 2, 3, 4].map(|v| Felt::new_unchecked(v as u64))));


Suggested change

let mut rng =

RandomCoin::new(Word::from([1u32, 2, 3, 4].map(|v| Felt::new_unchecked(v as u64))));

let mut rng = RandomCoin::new(Word::from([1u32, 2, 3, 4]));

PhilippGackstatter · 2026-05-22T07:10:55Z

+# ERRORS
+# ================================================================================================
+
+const ERR_PAUSABLE_ENFORCED_PAUSE = "the contract is paused"


Nit: I'd rename this to ERR_PAUSABLE_IS_PAUSED.

PhilippGackstatter · 2026-05-22T07:11:55Z

+    let seed: [u64; 4] = rand::random();
+    let mut rng = RandomCoin::new(Word::from(seed.map(Felt::new_unchecked)));


Suggested change

let seed: [u64; 4] = rand::random();

let mut rng = RandomCoin::new(Word::from(seed.map(Felt::new_unchecked)));

let seed: [u32; 4] = rand::random();

let mut rng = RandomCoin::new(Word::from(seed));

onurinanc added 5 commits April 3, 2026 18:18

add pausable component

f7ce498

add Pausable for composition component wrappers

66c9d47

Merge branch 'next' into pausable

975d515

changelog

6be1f65

clippy

2915639

onurinanc requested review from PhilippGackstatter and bobbinth April 20, 2026 10:24

onurinanc added 5 commits April 20, 2026 16:20

merge next

6344ca1

Merge branch 'next' into pausable

2a92f5d

merge next

88e6ad3

Merge remote-tracking branch 'origin/pausable' into pausable

44d5fde

fix tests after merge

5b51b0b

onurinanc mentioned this pull request Apr 23, 2026

Add ability to freeze specific accounts: Blocklistable #2819

Closed

onurinanc added 2 commits April 23, 2026 15:22

merge next

131aee2

remove load procedure

3c1d069

This was referenced Apr 26, 2026

Add Pausable module #2291

Closed

AggLayer: add emergency pause mechanism #2785

Draft

bobbinth reviewed Apr 26, 2026

View reviewed changes

Comment thread crates/miden-standards/src/account/pausable.rs Outdated

onurinanc added 2 commits April 27, 2026 16:55

Merge branch 'next' into pausable

c6757ba

remove callbacks from pausable add test component instead

93b358d

mmagician added standards Related to standard note scripts or account components pr-from-maintainers PRs that come from internal contributors or integration partners. They should be given priority labels Apr 29, 2026

onurinanc mentioned this pull request Apr 30, 2026

Extend the owner-controlled transfer policies OpenZeppelin/miden-confidential-contracts#106

Open

onurinanc added 2 commits April 30, 2026 16:03

Merge remote-tracking branch 'origin/pausable' into pausable

4253528

Merge remote-tracking branch 'origin/next' into pausable

e2080f6

onurinanc requested a review from bobbinth April 30, 2026 14:15

bobbinth mentioned this pull request May 2, 2026

Investigate separation between internal and external account component procedures #2862

Open

bobbinth reviewed May 2, 2026

View reviewed changes

merge next

f8f368f

onurinanc added 4 commits May 17, 2026 19:56

fix

ae942c8

add pausable transfer policies

e6a08a4

merge next

35efdcb

fix documentation

0781027

onurinanc requested a review from bobbinth May 18, 2026 12:51

onurinanc requested a review from mmagician May 19, 2026 11:39

onurinanc mentioned this pull request May 19, 2026

Pausable OpenZeppelin/miden-confidential-contracts#63

Open

bobbinth reviewed May 20, 2026

View reviewed changes

merge next

6595018

onurinanc added 7 commits May 21, 2026 15:02

Merge branch 'next' into pausable

047d093

add PausableManager

faacaaa

Merge remote-tracking branch 'origin/next' into pausable

19840de

Merge remote-tracking branch 'origin/pausable' into pausable

09d77f3

remove comments

a7f1e93

fix comments

47fbcca

fix comments

fc4cfd6

onurinanc requested a review from bobbinth May 21, 2026 15:44

bobbinth reviewed May 21, 2026

View reviewed changes

onurinanc added 2 commits May 22, 2026 08:54

apply review suggestions

eec5bda

Merge branch 'next' into pausable

4ccc30c

onurinanc requested a review from bobbinth May 22, 2026 07:07

PhilippGackstatter approved these changes May 22, 2026

View reviewed changes

onurinanc added 4 commits May 22, 2026 09:37

apply fixes

1b3dc1c

Merge remote-tracking branch 'origin/next' into pausable

d4c08d2

Merge remote-tracking branch 'origin/next' into pausable

01a456d

Merge remote-tracking branch 'origin/pausable' into pausable

1e09ed6

onurinanc requested a review from PhilippGackstatter May 22, 2026 08:23

		#! This procedure does not verify the caller. Wrap with access control in the account component
		#! composition if only privileged accounts should pause.

	async fn pausable_manager_pause_succeeds_when_owner_signs() -> anyhow::Result<()> {
	async fn pausable_manager_pause_succeeds_when_sender_is_owner() -> anyhow::Result<()> {

		let mut rng =
		RandomCoin::new(Word::from([1u32, 2, 3, 4].map(\|v\| Felt::new_unchecked(v as u64))));

	let mut rng =
	RandomCoin::new(Word::from([1u32, 2, 3, 4].map(\|v\| Felt::new_unchecked(v as u64))));
	let mut rng = RandomCoin::new(Word::from([1u32, 2, 3, 4]));

		let seed: [u64; 4] = rand::random();
		let mut rng = RandomCoin::new(Word::from(seed.map(Felt::new_unchecked)));

Conversation

onurinanc commented Apr 20, 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!

Choose a reason for hiding this comment

Uh oh!

bobbinth Apr 29, 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!

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!

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!

onurinanc commented May 19, 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!

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

Uh oh!

Uh oh!

bobbinth commented May 21, 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!

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!

PhilippGackstatter left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

bobbinth Apr 29, 2026 •

edited

Loading

onurinanc commented May 20, 2026 •

edited

Loading