Previous value in Frozen event
To close this thread, to me it’s redundant to emit the previous value, as an indexer tracking frozen balances would most probably be also tracking allowances or balances, which don’t offer this feature.
That said, it’s a nitpick, I don’t think there’s much impact in going either way.
Unfreezing in forced transfers
I believe your examples are better off using native ERC20 approvals or token vaults, due to simplicity and security concerns.
Escrowed payments, if kept as balances, should disallow transfers or they’d behave as ERC20 approvals. Therefore, it’s a choice between forced transfers with frozen balances or custom compliance rules, and a token vault. Allowing application-access to multiple higher-level functions seems to me wrong in principle.
Forced liquidations or slashing should also use a mix of permissioning functions or token vaults.
I see your point in making it as flexible as possible. I believe the underlying disagreement lies in that, to me, the token standard should incentivize applications to be built on top of the non-permissioned features, and leave permissioned functions to governing bodies, possibly EOAs, multisigs or governance contracts.
Coming back to the issue, enforcing or not the unfreezing of tokens in forced transfers is also a nitpick. My point stands, but I’d be ok either way. More community feedback on the underlying topic (permissioned features open or closed) would be much appreciated.
Pausability, setters & inclusion criteria
Standardizing getters and user-facing functions is obviously the main point of the ERC, as most of the usage will come from end-users and their interactions with wallets.
I see the point in standardizing setters if there’s no evidence for diverging behaviours or use-cases: the benefit for having integrations and tooling adapt to a common behaviour and interface outweighs the noise from a heavier ERC.
I can sense some evidence of different wanted behaviours in minting and burning, although I don’t know if strong enough. I don’t see it in pausability.
To me, the strongest reason for not including the full pausing feature is overlapping with isTransferAllowed. Still, my point stands.
I would love to hear more community feedback on the topic.
Partial compatibility with ERC-3643
There’s obviously benefit in partially inheriting the ERC-3643 interface and expected behaviour where it’s possible: token freezing, forced transfers and transfer checks, for example; making it a subset of the previous and reutilizing available tooling.
We’ll probably encounter most friction in ERC-7943 being multi-token and breaking interfaces with the support for token IDs.
If there’s evidence of existing ERC-3643 tooling that would profit from joint interfaces for any of the features of the ERC-7943, a discussion is surely deserved!
Token scope
It’s definitively a wanted feature to be able to identify a set of modular rules that apply to the token, as there can be common implementations, depending on jurisdiction or use-case (public or private offering).
I’d argue that, in favour of a leaner standard, these identification checks should be performed with the already included ERC-165 and not an additional getter.