Signing a TokenScript
TokenScript files are signed by the token issuer, usually.
The TokenScript files are signed for two distinct reasons.
First, to associate the TokenScript to the identity of the issuer.
Second, to link to the smart contracts it interacts with.
- Associate the signature with an identity
- Associate the signature with an identity, such as a domain name - e.g. "aave.com" - by attaching a certificate to the signature. Domain cerifiicate is the most convenient type to obtain, but any identity that can be ceritified through a trusted X.509 certificate authority should do.
- Link TokenScript with smart contracts
- Used for transaction security. If a smart contract trusts TokenScript, the transaction generated from that TokenScript is displayed with a trust badge. This is similar to how a website might be displayed with a trust badge if it properly uses https.
The former is done during signing of the TokenScript; the second is done separately, outside of TokenScript signing.
TokenScript can't be deployed for production use if it is unsigned. But you can debug an unsigned TokenScript (they will be displayed as untrusted by TokenScript engines).
Does the signer need to be the smart contract author?
It's not required, even though it's often the case.
TokenScript can be maintained by a member of your team who isn't the smart contract developer or administrator. In this case, the smart contract needs to express trust to the key or the identifier of the key.
But it can also be done by another party, which gained trust from the token issuer. In this case, it's better if the TokenScript, or the relative portion, be signed twice. Once by the author of the TokenScript - aw.app, AlphaWallet, made some TokenScript on behalf of the Token Issuer - and once by the Token Issuer themselves.