ERC-7943: Universal RWA Interface (uRWA)

ERCs
23

Thanks @tinom9 for your thoughts and suggestions on this.

Force event instead of FrozenChange.

I agree with this :smiley:

  • ERC7943InsufficientUnfrozenBalance event instead of ERC7943NotAvailableAmount, with more specificity over ERC20InsufficientBalance.

I agree with the specificity and probably we should add it as a SHOULD (in case the token doesn’t have specific errors as the ERC20 template by OZ has) not replace the specific errors for insufficient balances (outside the frozen one). However I’m still having some issues with the naming. “not available” (“unavailable”) suggests a temporary condition like a frozen amount not allowing you to transfer a determined amount while “insufficient” suggest more of a general lack of funds. Indeed if you try to transfer more tokens than the unfrozen one, you technically have a “sufficient” balance, but not an “available” one to be used. What do you think about this argument ? What about changing to “unavailable” instead ?

  • Pausability implemented through isTransferAllowed checks. Although I imagine it being a much used feature, so it wouldn’t bother me adding a setPaused method to the standard.

I agree in using isTransferAllowed, we might end up doing the error of forcing a setPaused and have integrators being forced to integrate this to be compliant with this EIP even if they don’t need it.

Regarding instead the fact of unfreezing when doing forceTransfer / burn

For forceTransfer:

I think the standard should still say that the function SHOULD skip freezing validations ( I believe you proposed a “MUST” but I’m curious to know why. If the function actually skips that, then I agree with your suggestion of unfreezing first (and emit an event) before doing the transfer, so that the transfer event doesn’t emit an amount of unavailable tokens. However, the integrators might decide to NOT skip freezing validations in a forceTransfer. I am thinking of use cases where there’s an automated penalty system that forcefully transfer tokens out without skipping the freezing status (that might have a higher priority over the penalty system).

For burn:

I actually think is dangerous to allow a burn to unfreeze. The burn function is meant to be either public (anyone can burn) or restricted. In the former case, burning would actually circumvent the freezing status imposed by an authorized party. This would easily translate into frozen assets being on purpose burnt down to avoid any reusage of those by the freezing authority.

Can you clarify why the need of a MUST in burn and forceTransfer to unfreeze ?