Semi fungible tokens support (ERC1155 equivalent)

[MarvinJanssen]

(Is this better at home in https://github.com/clarity-lang/reference/issues?)

It is amazing that Clarity has built-in support for fungible and non-fungible tokens. However, the intermediary semi-fungible token (or "multi token") is missing.

A semi-fungible token has both an ID and a supply. The equivalent Ethereum standard is ERC1155 / EIP1155: https://eips.ethereum.org/EIPS/eip-1155.

A straightforward way to mentally picture the use of semi-fungible tokens is to consider digital trading cards or in-game items: not all trading cards are the same, but there might be more than one of a particular kind. (Each with their own supply and rarity.)

Granted, you could just define fungible tokens and deploy a new contract for each new type but this is more prohibitive for apps / games that require many different items to be represented on-chain. With a semi-fungible, all it would take is a contract call. Another upside is programmatic / VRF generation of new tokens types and supplies. But it is not limited to applications of this kind, art NFTs can benefit by being able to mint a series or editions of a particular piece. Having a semi-fungible token type also allows for easier creation of bulk mint & transfer actions that aid scalability.

One can likely jerry-rig existing built-ins and use data maps to achieve the same result but then we lose out on native events and post conditions.

The function signatures for semi fungibles could look like this:

(define-semi-fungible-token asset-name asset-identifier-type)
(sft-mint? asset-name asset-identifier amount recipient)
(sft-transfer? asset-name asset-identifier amount sender recipient)
;; And so on...

Posting to hopefully open a discussion on the usefulness of such a token.

[jcnelson]

If you're asking to change the language spec, it's probably better to open against the clarity-lang repo.

One can likely jerry-rig existing built-ins and use data maps to achieve the same result but then we lose out on native events and post conditions.

But it is the case that you can build a semifungible token in Clarity without doing a hard fork, right? It just might require a little bit more work.

[MarvinJanssen]

Totally, we would just move away from semantic representation of such tokens in terms of native events. It feels like it goes against the design principles to be introducing custom balance sheets so early in the game.

For example, if the semi-fungible is expressed as a single (define-fungible-token) then the total user balance has little bearing on how much the user has of what. And the user interacting with a swap contract or DEX can only safeguard against some amount of tokens being transferred, not which kind. A malicious contract could transfer 10 rare tokens instead of the 10 the user intended to trade. (And the user is sad because post conditions were added, wrongly assuming things would be OK.)

Perhaps not an ask to change the language spec (just yet), more to open a discussion. Feel free to close if so and I will use that as a signal to repost over there.

The ability to have post conditions for custom (print) events could deal with this too. (And much more!)

[MarvinJanssen]

For reference: https://github.com/MarvinJanssen/stx-semi-fungible-token

[MarvinJanssen]

Relevant: stacksgov/sips#42

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed. Please reopen if needed.

[blockstack-devops]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.