> Sign-to-contract looks like:
 
Nice! I think it should be standardized as some informational BIP. This is a similar case as with Silent Payments: it is possible to let users make their own commitments as they please, but if it will be officially standardized, then it will be possible to build more protocols on top of that, in a way which will be understood properly by other nodes.
 
Before, I thought about interpreting signature R-value just as a Taproot-based public key, and forming a commitment as a valid input, that would allow moving coins on such address, but maybe we could standardize it in a simpler way than that. In general, if a commitment would allow pushing any data, it could be always extended when needed, because future commitments could be always nested in the old ones, 32 bytes is enough to do that.
 
Also, I thought about including OP_RETURN at the beginning of each commitment, to make sure it will be never pushed on-chain, but only stored and processed off-chain. Another thing is that r-value is always expressed as some 256-bit number, even in DER encoding, which means we can always assume 02 public key prefix in all commitments, and simply convert it directly into a proper Taproot address.