Idea for freezing the rgb asset in ifa schema

[cymqqqq]

Hi team, I have an idea for solving the RGB asset freeze problem when issuing the IFA asset(Issue the USDT).
First, I will describe my idea based on my finished work, then you can check if it is possible.
New variables:
OS_BLACK_OWNER: the utxo whose rgb asset is frozen.
OS_BLACK_RIGHTS: When we issue the ifa genesis contact, we can add the new black rights assignments. (It's like a black list manager).
TS_BLACK: New add black transition used to add black list and spend black list manager utxo.

Logic:

1. Add new variables to the IFA schema
2. Issue a new IFA genesis contract with black right assignment.
3. Build the add black transition,
   3.1 Select the black manager utxo, the specific amount we want to freeze, and the black owner utxo as the input. First, we check the freeze amount whether or not it is larger than the black owner balance.
   3.2 If not, then we add the black owner's utxo with the specific amount to the black owner fungible assignment
   3.3 Add the black list manager utxo to the input(I mean spent it)
   3.4 Add a new black list manager utxo to the black manager rights assignment.(wait for next add black transition to spend)
   3.5 Complete the add black transition
4. When we want to build a transfer transition, first we should check whether or not the sender's utxo is in the black list. If it is, then we can check if all his RGB balances are frozen(or just freeze some of them).

The above description is my new idea; you can check if it is possible. We can discuss here. :)

[St333p]

The IFA schema aleady supports freezing assets outside the scope of RGB business logic. The "REJECT_LIST_URL" global optionally contains a URL controlled by the issuer that exposes a list of frozen allocations (Opouts). The validation procedure returns the graph of Opouts included in the history, so the wallet has all the information it needs to refuse the transfer even though the RGB-specific validation was successful.

There is indeed space for a contract implementing a native freezing mechanism, so I'll still get into more details about your proposal.

• Since RGB supports blinded transfers, it is suboptimal to use UTXO information to identify frozen allocations, as it could be unknown to both the issuer and the sender; Opout seems more appropriate to me as it's always known and it allows to avoid freezing other possibly legitimate allocations on the same utxo
• There is a data availability problem: when receiving an asset, I might not have the latest updates on the blacklisted allocations; to ensure I have the latest data I need to reject any consignment that doesn't contain the data associated to all transaction involving black rights I can observe onchain. Also, since it's the issuer that controls the black rights, there will need to be a way to publish the client-side data somewhere for wallets to get from
• Issuers might need a way to unfreeze allocations if the owner can prove to be legitimate, your proposal doesn't cover that need AFAICT