CHIP 2023-07 Minting Baton Covenant (MBC) Standard for Fungible Tokens

CHIPs Standards Track
,
#1

This specification is a standard to create minting baton functionality for CashTokens. Bitcoin Cash does not have the concept of a minting baton for fungible CashTokens natively because then the token amount could overflow 64-bit integer size. Other token protocols, such as SLP and ERC20, allow for issuing supply on an ongoing basis with a minting token. The CashTokens specification does propose how to mark supply as reserved, held by the trusted entity and not in circulation but this has not been implemented anywhere thusfar because it is not straightforward.

This standard uses a covenant holding the reserved supply to create a minting baton NFT for fungible CashTokens. An extension to the BCMR metadata schema is specified for tokens following the MBC token-standard, this way applications such as wallets and blockexplorers can be correctly display the NFT as a MBC minting baton and can easily show the issued supply.

This standard uses a covenant to achieve the same functionality as a classic minting baton that controls issuance. The minting covenant is tracked using an authchain starting at the covenant’s creation making it easy to track the minting history. The authority to mint tokens is held by the minting baton NFT making it easy to track changes to the minting setup.

By keeping the design simple, this specification aims to be a practical solution which can be used immediately.

3 Likes
CHIP 2023-08 AuthGuard Standard
#2

I expect this standard to be very helpful in the future for simple fungible token projects such as trusted stablecoins.

This standard is going to part of Paytaca’s token creation studio so it will get userfriendly tooling. The paytaca team has successfully done a chipnet demo of the contract!

In a request for comment @bitjson wrote:

For centralized issuers, it also makes a lot of sense to put all the tokens in just one covenant (at the authhead) so that the reserved supply can be proven with just the authchain. The spec definitions are intended to be a bit more general so that they support multi-threaded systems (so can’t just require using the authhead) and don’t try to lock everyone into some sort of commitment prefix scheme. But definitely intended to be compatible with the bitauth resolution strategy!

which I see as a positive endorsement of the approach taken by the MBC standard :pray:

@bitcoincashautist has suggested allowing the minting baton NFT to be a mutable token so it can keep state instead of having a fixed commitment, this would require only a small change to the contract but the exact usecase for this still need to be worked out.

I also found that the BCMR spec suggested a method for light client

Providing for Continued Issuance of Fungible Tokens

If additional fungible tokens of a category may be needed in the future, token issuers should initially mint an excess supply (e.g. the maximum supply of 9223372036854775807 ) and hold the unissued tokens in the identity output with a mutable token (using any commitment value) to indicate they are part of the Unissued/Reserved Supply. This enables continued issuance from the identity output while maintaining the ability for light clients to verify the maximum possible Circulating Supply.

I added this to the evaluated alternatives in the CHIP!

1 Like