asset-identifier, the payment invoice is generated by following the procedure describted by BIP-21[1], with the following changes:rgb.asset-identifier MUST be present, and it should be encoded as a Base58[5] string without checksum.amount field can be added. If present, the amount MUST be encoded as a floating-point number with the precision factor already applied, if the assets protocol supports it.req- prefix depending on whether or not the field should be considered "required".req-endpoint that indicates where the sender is supposed to upload the client validated history of the tokens. It should be equal to a V2 or V3 Tor onion endpoint, optionally followed by an explicit port if the listening server is running on a non-standard port.txid in the network binary format (reverse of the hex string usually displayed) in a temporary buffer.vout encoded as a 32 bit long unsigned big endian integer.0.0.ln + <unique prefix>.a MUST be present, and MUST be set to the binary representation of the asset-identifierf fields) MAY be present and they MAY contain UTXO-based addresses, if the assets protocol supports them. Any other field that would normally be required by the specific asset protocol in its "On-Chain Addresses" MUST also be added with a unique field type defined by the protocol.e (endpoint) if at least one f field is present, serialized in a string as described in the "On-Chain Address" part of this standard. Multiple e fields MAY be specified in an implied preferred order.Decoders SHOULD enforce known-length restrictions on witness programs. For example, BIP141 specifies If the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail.