Native Token name length restriction of 32 bytes

[ullamonster]

To address this limitation in the name length, the pubkeyhash is split into two parts, the last 32 bytes becoming the CATs name. The other 24 bytes are stored in the datum and upon validation, the smartcontract combines these two parts to validate against the signing wallet sig as well as compares both cats to each other and their destination wallet must match the owner.

Here is the first CAT on testnet for our Alice: addr_test1vzck0zlwql2nf7clg5vsxcpucmpg43wvm2srg38vu7hvqsgl9zcer and this associate pubkeyhash is: b1678bee07d534fb1f451903603cc6c28ac5ccdaa03444ece7aec041, the final 32 bytes of which are the name for her 1M CATs seen at the above address.

The smartcontract should be able to handle logic like so:

These values need to be found

• pubKeyExpect = this tx signer pubkeyhash
• catNameExpect = final 32 bytes of pubKeyExpect
• pubKeyPrefixExpect = Datum stored first 24 bytes of the pubkeyhash who locked the funds/filled the datum
• pubKeyReconstruct = pubKeyPrefixExpect + catNameExpect

With these values we do this logic, all of which must be true in order to validate:

• Does tx-in from script have 1 CAT with catNameExpect
• Does tx-in from signer have 1 CAT with catNameExpect
• Does pubKeyExpect =match= pubKeyReconstruct
• Do CATs match
• Are CATs being spent to pubKeyExpect

If these conditions are met, the transaction is valid. It would be pointless in most instances to try to change the datum with this configuration as you would be creating a hash that cannot work for validation, locking the funds forever. So while unlocking still relies on datum in this situation, it won't allow unlocking by someone who modified the datum via a webapp.