PSP-55, a fungible Token for assets with 'negative value', like debts

[Nradko]

PSP22 has a limited use case to only "positive value" assets.
Here, the draft of a similar standard to PSP22 is proposed that can be used to represent "negative value" assets like debts.

In general, if an asset has a negative value then to transfer it to the other_user, the other_user should have given the sender allowance before.

[xgreenx]

I didn't check the methods' signatures. This comment is related to the idea overall.

Note: Introducing the new standard for FT means that everybody should stop using the old one. Otherwise, it breaks the idea of standardization.

I like the idea of supporting debt and credit things in smart contracts. But I'm not sure we need to integrate it as a default behavior of FT.

A negative balance means that the user should be able to take a loan, but at the same time, his positive balance should increase to spend tokens. balance_of should show the actual amount you can spend. With a negative balance, it is not possible, so you need a negative balance_of for debt and a positive balance_of to see how much you can spend at the same time.

For me, it seems better to create a separate interface for loans and debt, and the same PSP22 contract can implement this interface. Seems you need most of the methods from PSP22 but with another behavior and context. The debt can be positive in this case because you will have a separate trait to work only with this entity.

[xgreenx]

One of the main ideas of PSP22 is also to be compatible with pallet-assets. The introduction of negative values will break it.

[Nradko]

Hey, I must have not explained myself clearly. In the proposal, the balanceOf is always positive (u128) but this positive balance represents the amount of asset that has negative value.
As I said the PSP55 is almost the PSP22 standard but there is a VERY important difference that, as far as I understand, cannot be implemented into PSP22. Namely, notice that as asset has a negative value (value in terms of $ not negative integer) one should not be able to freely transfer it to other users. To transfer this asset to the 'target', the caller should have an allowance from the 'target' to do so.

The only two differences in implementation are that:

1. transfer function decreases the allowance of the caller that was given by the target (to address)
2. transferFrom decreases the allowance of the caller that was given by the target (to address). In contrast in the PSP22 case, it is the owner (source) that must give allowance to make transferFrom, not the target.

These two points, I think are not compatible with PSP22 as the allowance means a different thing.
Once again, allowance in PSP22 means how much the caller can transfer FROM the source account.
Here, in PSP55, allowance means how much the caller can transfer TO the target account.