The issues summarized here aim to clarify the protocol specification and we submit them to inform about the exact way the implementation fulfills its specification. We leave the judgement on the correctness of the implementation with respect to the specification to the SingularityNet team.
The specification lists a requirement:
Requirement: Tokens can be burnt freely by token holder
A token holder can burn the tokens he owns, but there is a constraint for the burning transaction to succeed.
Namely, even if the token is being burned, there is a check that the transaction mints or burns just this single token.
This excludes a plausible usecase where a token is exchanged for another token that gets minted. The usecase is still achievable but with a more complex 2-step process.
Informally, the holder can burn his tokens, but the extent of how "free" he is to do so is philosophically ambiguous :).
The token can be minted with any of the validator redeemers
The UpgradeableOwners validator defines 4 redeemers, among them the TokenMint redeemer. For the mint to succeed the Token minting policy checks the spending of the protocol NFT. The validator doesn't perform any checks on the minted value.
This means that the token can be minted by spending validator with any of the 4 redeemers, provided the owners agree. No vulnerability was found by Mlabs exploiting this property. The specification says that the protocol datum mustn't change in the minting transaction. It is not changed in the TokenMint transaction, but can be in the minting transactions using other redeemers.
The protocol once initialized can be used to mint tokens with various minting policies.
This may be the desired feature, nevertheless we'd like to point that out.
The Token script is parametrized with a token name. For the given parametrized Token policy there's a single allowed token name for the minted tokens.
Note though, that no concrete parametrization of the token policy is expected by other validators of the protocol.
Concretely, both the UpgradeableOwners and Token are bound to work with the single state thread NFT.
After a correct initialization, it is ensured that the NFT token is held at an UpgradeableOwners script address, therefore it is justified to delegate the verification from Token script to UpgradeableOwners validator by checking for NFT presence.
But the validator does not depend on the Token script - on its hash or any concrete parametrization.
This means that, provided that the owners agree, the protocol can mint tokens from various asset classes using the Token policy parametrized with different token names and yielding different policy hashes.
The practical consequence is that the tokens minted with the protocol cannot be recognized on chain simply by their minting policy.
Description
The issues summarized here aim to clarify the protocol specification and we submit them to inform about the exact way the implementation fulfills its specification. We leave the judgement on the correctness of the implementation with respect to the specification to the SingularityNet team.
The specification lists a requirement:
Requirement: Tokens can be burnt freely by token holder
A token holder can burn the tokens he owns, but there is a constraint for the burning transaction to succeed. Namely, even if the token is being burned, there is a check that the transaction mints or burns just this single token. This excludes a plausible usecase where a token is exchanged for another token that gets minted. The usecase is still achievable but with a more complex 2-step process.
Informally, the holder can burn his tokens, but the extent of how "free" he is to do so is philosophically ambiguous :).
The token can be minted with any of the validator redeemers
The
UpgradeableOwnersvalidator defines 4 redeemers, among them theTokenMintredeemer. For the mint to succeed the Token minting policy checks the spending of the protocol NFT. The validator doesn't perform any checks on the minted value.This means that the token can be minted by spending validator with any of the 4 redeemers, provided the owners agree. No vulnerability was found by Mlabs exploiting this property. The specification says that the protocol datum mustn't change in the minting transaction. It is not changed in the
TokenMinttransaction, but can be in the minting transactions using other redeemers.The protocol once initialized can be used to mint tokens with various minting policies.
This may be the desired feature, nevertheless we'd like to point that out.
The Token script is parametrized with a token name. For the given parametrized Token policy there's a single allowed token name for the minted tokens. Note though, that no concrete parametrization of the token policy is expected by other validators of the protocol. Concretely, both the
UpgradeableOwnersandTokenare bound to work with the single state thread NFT. After a correct initialization, it is ensured that the NFT token is held at anUpgradeableOwnersscript address, therefore it is justified to delegate the verification fromTokenscript toUpgradeableOwnersvalidator by checking for NFT presence. But the validator does not depend on theTokenscript - on its hash or any concrete parametrization. This means that, provided that the owners agree, the protocol can mint tokens from various asset classes using theTokenpolicy parametrized with different token names and yielding different policy hashes.The practical consequence is that the tokens minted with the protocol cannot be recognized on chain simply by their minting policy.