Overview

Config restrictions protect operations that change the system configuration of the vault, such as registering tokens, adding blockchain networks, or attaching cold-wallet master keys. They are one of three restriction categories alongside Transaction Restrictions and Policy Restrictions.

Unlike transaction restrictions, config restrictions have no asset, amount, source, or destination filters. Every config restriction applies to all configuration operations in that category. Each restriction specifies:

• Action - approval requirements (N of group) or Block
• When initiated by (Block rules) - optional initiator group exemption (All users or All users, except selected groups)

Restricting access with groups and Block policies

Historical Admin / MarketOps / Viewer privilege tables are replaced by groups plus restrictions:

1. Put users in groups under Settings → Groups (for example admins, market-ops, viewer).
2. Use config restrictions (this page) so configuration changes require approvals, or use Action Block with When initiated by → All users, except the groups that may initiate config changes.
3. Use transaction restrictions with Action Block and the same initiator pattern so other groups cannot start transfers or other signing operations. See Transaction Restrictions Scenario 5.
4. Use policy restrictions so only designated groups can change governance rules (policy restrictions do not offer Block or an initiator filter).

Example: members of viewer must not register tokens or chains. Create a config restriction with Action Block and When initiated by → All users, except admins (and any other groups that should remain able to initiate). Members of viewer match the Block rule and are denied; exempt groups skip that restriction (they must still confirm so Policy Nodes can verify group membership). Pair a similar transaction Block rule if those users must also be denied on-chain initiation.

Evaluation Semantics

Config restrictions follow the same additive model as transaction restrictions:

1. Every config restriction is checked.
2. A restriction is skipped when the initiator belongs to a group listed under When initiated by → All users, except. Otherwise it matches every config operation (there are no other filters).
3. For each matching restriction, Block denies the operation; approval actions add their approver requirements.
4. All approval requirements from matching non-Block restrictions accumulate. The operation proceeds when every accumulated requirement is satisfied.
5. If no config restriction matches (or none exist), config operations are allowed without approvals.

Governed Operations

The following operations require config restriction evaluation when at least one matching config restriction is configured:

📘

Note:

Account creation, user registration, user reset, user delete, and master-key backup are not governed by config restrictions. Those operations are uncategorized and are not gated.

Examples

Approvals for all config changes

A single approval restriction protects all asset and chain management operations:

Result:

• Registering a token requires 2 owner approvals.
• Registering a custom chain requires 2 owner approvals.
• Attaching a cold-wallet master key requires 2 owner approvals.
• Creating a new vault account requires no config-restriction approval (uncategorized).

Block config initiation except admins

Deny configuration changes from everyone except admins:

Result:

• Members of admins skip this Block rule (confirmation still required to verify membership).
• All other initiators are denied for every governed config operation above.

Combine with transaction Block rules when certain groups must not initiate on-chain operations at all.