For instance, suppose a transaction has three inputs: the first contains a spend of 10 Zen, the second a mint of 500 tokens from contract A, of subtype X, and the third a spend of 100 tokens from contract B, of subtype Y. Then the transaction’s outputs with the Zen type must have amounts summing to 10, those with the A:X type must sum to 500, and those with the B:Y type must sum to 100. No other assets can be present in the outputs of the transaction.
ContractLockdefined below applies to version-0 contracts. Although high version mint inputs implicitly have high version contract locks, the release version does not define anything about a high version contract lock – neither its serialization nor its semantics.
High version contract locks are validated like any other unidentified lock type. The only difference of any significance is that they are the kind of lock which mint inputs implicitly possess.
None, then require that the lock’s contract hash is the same as the “recipient” parameter of the message. Then read the current witness and require that:
None, then check only for a contract witness, version 0, with contract hash matching the lock.
Note: if a contract returns a message, and the next input does not have a contract lock, then at the latest, validation will fail here. This prevents a chain of contracts from being broken.