Utexo: Not Every Payment Request Needs to Reveal the Same Information When someone wants to receive money, they usually share a payment address or invoice. But with RGB assets on Bitcoin, there are different ways to create a payment request. Utexo's SDK documents two receiving methods: blinded invoices and witness invoices. Understanding the difference helps explain how privacy and payment coordination work in RGB. 1. What is an RGB invoice? An RGB invoice is a payment request containing information needed to send a particular RGB asset. For example, imagine you want to receive 50 USDT issued on Bitcoin via RGB. Your wallet generates an invoice that tells the sender which asset and amount you want to receive. The sender uses that information to prepare the transfer. 2. What is a blinded invoice? A blinded invoice uses a concealed receiving reference rather than directly exposing the recipient's actual Bitcoin output. In simple terms, it gives the sender the information needed to make the payment without revealing the recipient's underlying UTXO in the same way a witness invoice does. A UTXO is an unspent Bitcoin transaction output. It represents a specific piece of Bitcoin that can be used in a future transaction. Blinding is useful when a recipient wants additional privacy around the receiving output. 3. What is a witness invoice? A witness invoice uses a specific Bitcoin output as the receiving reference. Instead of relying on a blinded receiving reference, the invoice identifies the output that will receive the RGB asset. This can be useful in workflows where the receiving output is already known and the application needs to coordinate the transfer around it. 4. How does Utexo support both? Utexo's SDK documents two receiving methods: - "blindReceive()" — creates a blinded receiving invoice. - "witnessReceive()" — creates a witness-based receiving invoice. Its Web SDK also provides "onchainReceive()" with witness receiving as the default, while developers can set "witness: false" to request a blinded invoice. This gives developers flexibility when designing their payment applications. 5. Real-life example: An online store Imagine an online store accepts USDT issued on Bitcoin via RGB. A customer wants to pay $100 for an item. The store generates an RGB invoice and shares it with the customer. If the store chooses a blinded invoice, it can avoid directly exposing the receiving UTXO in the invoice. The customer uses the invoice to prepare the payment. After the transfer, the store validates and receives the asset. This can be useful for businesses that want to reduce the amount of wallet information exposed during payment requests. 6. Another example: A business paying suppliers Imagine a company has a treasury wallet and needs to receive payments from several business partners. For some payment workflows, it may prefer using a specific receiving output that its accounting system already tracks. A witness invoice can help coordinate the transfer around that known output. For other situations, the company may prefer a blinded receiving reference. The important thing is that the application can choose the method that fits its workflow. 7. Why does this matter? Privacy and payment coordination are both important when building financial applications. A receiving method that works well for one business may not be ideal for another. Blinded invoices provide a more privacy-oriented receiving reference, while witness invoices use a specific output as the receiving reference. Utexo's support for both gives developers more control over how their applications receive RGB assets. The bigger picture Developers also need to decide what information a payment request exposes and how the receiving wallet identifies the destination. Utexo's blinded and witness invoice functionality provides two different approaches to handling that process on Bitcoin through RGB. @utexocom