Interesting. It seems still a bad and inefficient format, as they continue to use JSON to store the parameters, which wastes precious data for the keys of each dictionary, instead of only encode the values with a library like Protobuf and keep the keys in the protocol definition itself. But yeah, the fact that it requires one transaction per transfer is a little bit better than BRC-20 (which is the worst protocol ever designed).
Still, OP_RETURN protocols without JSON seem more efficient to me. Even
CBRC-20, another post-"BRC-20" alternative, seems to do it better (not using JSON but the
URN format), even if they still require two transactions for transferring.
So in theory the "holy grail" should be a SCBRC-20 which uses CBRC-20's storage format and SRC-20's multisig approach
(Or: simply use one of the old token protocols.
)
2. Rather than exploit witness data, it seems they exploit public key on P2MS (Pay to Multi Signature) address. It also means they don't need to create 2 transaction for single SRC-20 operation.
This looks like this is an even more obfuscating way to store the data, as this way they look like "regular" P2MS transactions. It would become difficult to create "patches" to block this kind of tokens ("the LukeJr way"). It's basically what I feared what would happen if these patches get more popular, and why I think this approach is useless.
I have only read the protocol description superficially (I don't know if it's worth it to dedicate more time to investigate it further) but I fear that this kind of protocol, which includes the data in the parts of the transaction which are normally meant for public keys (like also Doginals does), could make it even more difficult to create ways to ignore these data in the Intial Blockchain Download (maybe @vjudeu can confirm this). However, I believe there's a limit how much data can be crammed with this method in a single transaction, so it's unlikely this will lead to images and other media objects to be stored on-chain.