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-identifier
f
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.