In D15041#337586, @Fabien wrote:

The only standard tx format is OP_RETURN <PUSH OPCODE(s)> <DATA>. Nothing else will be accepted in a mempool or relayed. It makes no sense to let the URI contain the whole script, it's error prone and needs validation to be duplicated in the code making the transaction.
Just use a max 220 bytes, which is the data with no opcode at all and add the op_return and push opcodes in the software that creates the tx => no validation needed, it's simple and it works.

I don't think it's so simple, since many OP_RETURN txs use multiple pushes.

Say we want a URI for an alias tx.

From the spec:

An output with an OP_RETURN containing 4 data pushes:
A push of the 4-byte protocol identifier. Must be pushed with 04.
A push of a version number. Must be pushed as OP_0.
A push of the Alias. Must be pushed with 0x01-0x15.
A push of a CashAddr payload. This information defines the "Alias Address". Must be pushed with

Here's an example: https://explorer.e.cash/tx/ec92610fc41df2387e7febbb358b138a802ac26023f30b2442aa01ca733fff7d

Here, the output script is 6a042e786563000131150076458db0ed96fe9863fc1ccec9fa2cfab884b0f6

So the URI param using OP_RETURN <PUSH OPCODE(s)> <DATA> format, where we add OP_RETURN and <PUSH OPCODE(s)>, would be ?opreturn=2e786563000131150076458db0ed96fe9863fc1ccec9fa2cfab884b0f6 ?

Dev has no easy way of knowing he needs to push this 29-byte string with 04. Maybe I'm not understanding the solution you'd like to see here.

We could support something like ... opreturn=2e786563&opreturn=0&opreturn=01&.... etc ...but this is also messy. How do we know &opreturn=0 must be a push of OP_0? What if the URI creator wanted 0x0100?

I think we need to start with a "literally this" approach. The param is just the exact hex output expected.

We don't really need to validate this at all, since the node will fail to broadcast any malformed OP_RETURN. I just like to validate stuff like this in Cashtab to catch it before bouncing it off the node.