Most people assume a token freeze simply stops everything. In practice, the boundary is more specific. If one participant is restricted from transferring a particular asset, does that stop other institutions from using the same token? Does it prevent the restricted institution from moving a different token? And what happens to ordinary transfers between accounts on its own ledger?
I tested this directly instead of relying only on documentation.
I stood up a local Rayls Private Network, deployed two independently authorized Enygma tokens, froze one token for one specific participant, and measured what stopped and what continued with real transactions, contract state checks, and recovered governance receipts.
Setup I used
Three Sovereign chains plus the Private Network Hub:
- Sovereign A (Chain ID 12345)
- Sovereign B (Chain ID 12346) — the participant I restricted
- Sovereign C (Chain ID 12347)
- Private Network Hub (Chain ID 1337)
The Hub is the central Hyperledger Besu chain that holds the participant registry, token registry, and cross-chain messaging contracts. Every message between Sovereign chains passes through it. Each Sovereign chain remains a private EVM ledger controlled by its own institution. Internal transfers never leave that chain.
I created two distinct Enygma tokens:
- W2F — the freeze target
- W2C — the control token that remained unfrozen
Both followed the normal lifecycle: deployment on A, local registration and authorization, submission to the Hub, Hub approval, and minting. I minted 1,000 units of each and first confirmed both could move across chains.
Starting balances after baseline transfers:
- W2F: A 810 | B 90 | C 100
- W2C: A 910 | B 90
I also recorded the distinct resource IDs through direct contract reads.
What the official design says
According to the Rayls documentation, the Private Network operator (or a COMPLIANCE_OFFICER role) can freeze a specific token for chosen participants. The freeze is stored in the Hub’s TokenRegistry and propagated to every chain.
Once applied it is intended to block:
- Enygma transfers involving the frozen participant (both directions)
- Related DvP operations that use that token for the restricted participant
It is not intended to stop ordinary local ERC-20 transfers on the same Sovereign chain, because those never leave the chain and do not go through the Hub.
There is a separate control. A Sovereign chain’s own administrator can freeze a token locally with `freezeOnPrivacyNode`. That blocks operations on that chain itself. The Hub-level freeze and the local freeze are different mechanisms.
I wanted to see whether the deployed behavior matched this description.
Freezing W2F for Sovereign B
All freeze flags were false before the operation. I then executed the authorized freeze for W2F targeting only participant 12346.
I recovered the original mined transaction through historical Hub inspection. Its calldata decoded to `freezeToken` with the exact W2F resource ID and chain ID 12346. After the transaction, only W2F for Sovereign B was marked frozen. W2F remained unfrozen for A and C. W2C stayed authorized everywhere.
Sovereign B’s own registry showed W2F Hub status as 4 (frozen) while W2C remained 2 (authorized).
What the freeze stopped
I tested both cross-chain directions involving B:
- Sending W2F from A to B reverted during gas estimation (destination-participant restriction, selector `0xad22899b`).
- Sending W2F from B to A also reverted (source-side Hub status check, selector `0xdc2ffb0f`).
Neither attempt was broadcast. Balances did not change. The tested cross-chain routes for W2F involving Sovereign B were blocked.
What continued working
While W2F remained frozen for B, three other activities succeeded:
1. A W2F transfer from A to C (same token, different route). Balances updated exactly as expected.
2. An ordinary ERC-20 `transfer` of W2F between two local accounts on Sovereign B itself. The Hub freeze did not stop internal movement on B’s ledger.
3. Both directions of the separate token W2C between A and B.
The same two institutions that could no longer move W2F across chains could still exchange W2C. The restriction was token-specific and participant-specific in the scenarios I tested.
This matches the documented design: a Hub participant-specific freeze stops cross-chain movement of that token for the restricted participant, but leaves local transfers and other tokens unaffected.
Governance boundary and recovery
An ordinary account could neither freeze nor unfreeze. Both calls reverted with `RaylsAccessManaged__Unauthorized`. Only the authorized operator could lift the restriction.
After the authorized unfreeze I re-tested the two previously rejected routes. Both succeeded. Balances reconciled before, during, and after the restriction. The tracked totals for both tokens remained 1,000 units.
What this actually clarified
The local transfer on Sovereign B was the result that made me think most carefully. W2F was frozen for B at the Hub level. Cross-chain activity involving B stopped. Yet an ordinary transfer between two accounts on B still worked, and a completely different token continued moving in both directions.
Rayls treats these as distinct controls:
- A Hub-level freeze of a token for a specific participant
- A blanket freeze of a participant
- A local Sovereign-level freeze of a token
For an institution designing compliance procedures or incident response, that distinction matters. A successful governance command is not the same as understanding exactly what stopped and what remained available.
Limits
This was a local development-stack experiment, not a production audit. I tested specific tokens, routes, amounts, and governance actions. I did not test every possible path, timing condition, or recovery scenario. The results are limited to the behavior I observed in this deployment.
What can be verified from the public documentation is the intended design of the Hub-level participant-specific freeze and the existence of the separate local freeze control. Runtime behavior in any live deployment still depends on configuration, roles, and how the network is operated.
Takeaway
A targeted restriction should be judged not only by what it stops, but also by what it allows to continue.
In this experiment, freezing W2F for Sovereign B blocked the tested cross-chain routes involving B. Local transfers of W2F on B still worked, transfers of the same token between other institutions continued, and a completely different token kept moving normally. After the authorized unfreeze, the blocked routes recovered.
That boundary is the practical detail that remains useful long after the governance command itself has been executed.
Sources
- Freezing Tokens: https://docs.rayls.com/docs/freezing-tokens
- How Enygma works: https://docs.rayls.com/docs/how-enygma-works
- Private Network roles: https://docs.rayls.com/docs/private-network-roles
- Rayls Private Networks: https://docs.rayls.com/docs/rayls-private-networks
- Privacy in a Private Network: https://docs.rayls.com/docs/evm-privacy