WPRC 2026#020

Universal Money Address (UMA)

WPRC-020· SG· 2025. 03· INFRASTRUCTURE

Universal Money Address (UMA)

An open-source payment address standard for fast, low-cost global payments using the Bitcoin Lightning Network.

Contributors

RongxinWPRC·L·Jeremy KleinLightSpark

The WhitePaper Reading Club Singapore [27]	11 March 2025
Universal Money Address (UMA)
Other Summaries: https://bit.ly/WPRC_Analysis	Rongxin, L, Jeremy Klein (LightSpark)

Summary

An open-source payment address for easy transactions standard for fast, low-cost global payments using the Bitcoin Lightning Network.w

Why This Is Important

Its combination of the Bitcoin Lightning Network and personalized payment addresses. UMA simplifies the payment process by allowing users to conduct cross-border payments using email-like addresses while supporting the instant conversion of multiple currencies and digital assets.

Overview

The UMA standard introduced by Lightspark aims to facilitate secure and “compliant” remittances of both fiat and cryptocurrencies via the Lightning Network, making payments as easy as sending an email. Based on the Lightning Address (LUD-16), UMA uses an email-like format (e.g., $alice@vasp1.com) and leverages the LNURL-PAY specification for the payment process. During a transaction, the sender’s institution verifies the recipient’s address, after which UMA communicates the preferred currency, exchange rate, and compliance requirements. Subsequently, Lightspark Predict identifies the optimal route, (Don’t need to use LightSpark) converts the sender’s currency to Bitcoin for a lightning-fast transfer, and finally, the recipient’s institution converts the Bitcoin back to the recipient’s preferred currency.

Background

Lightning Network: (i) Enables instant, low-cost Bitcoin transactions via off-chain payment channels to address blockchain scalability issues. (ii) bidirectional payment channels to move Bitcoin transactions off-chain, dramatically enhancing scalability and speed (instant transactions vs. ~10-minute block confirmations). Hashed Timelock Contracts (HTLCs): Enables secure, trustless multi-hop routing across multiple payment channels without custodial risk, ensuring atomic (iii) Origins: Proposed in 2015 by Joseph Poon and Thaddeus Dryja (“The Bitcoin Lightning Network” whitepaper). Main implementation (2018): by Lightning Labs (Elizabeth Stark, Olaoluwa Osuntokun) and supported by Blockstream contributors (Christian Decker, Rusty Russell).

Team

Lightspark: Enterprise-grade infrastructure for Bitcoin’s Lightning Network, enabling global instant payments. Raised $175M in 2022. David Marcus: CEO of Lightspark and previously led Facebook’s Libra (later Diem) cryptocurrency project, worked in Switzerland. Lightning Network: Bitcoin’s Layer-2 scaling, co-invented by Tadge Dryja, designed for instant, low-cost off-chain transactions. Completed verified on Bitcoin using using Discreet Log Contracts Tadge Dryja: Co-inventor of the Lightning Network and currently a researcher at Lightspark. Jeremy Klein: Author and Core Maintainer for the UMA protocol. Senior Staff Engineer at LightSpark, Previously VP of engineering at Maykit, and spent 8 years at Google.

Opinions

The low fees and instant settlement features of UMA make it stand out in the competition with traditional bank transfers and existing cryptocurrency payment methods. For users and businesses that frequently need to make cross-border remittances, UMA offers an efficient and low-cost alternative. Security and compliance are two of the core strengths of UMA. By supporting compliance requirements such as anti-money laundering (AML), sanctions screening, and travel rules, UMA ensures the security and legality of transactions. This is crucial for financial institutions and businesses as they need to provide efficient payment services while meeting regulatory requirements.

UMA Protocol Components

UMA Address	UMA (Universal Money Address) serves as user identifiers for transactions handled by Virtual Asset Service Providers (VASPs). These addresses streamline interoperability between different VASPs, ensuring seamless payments and regulatory compliance (e.g., Travel Rule compliance).How UMA Addresses Work with VASPs: (i) A UMA address (e.g., $alice@somevasp.com) represents an account managed by a VASP. (ii) domain name (somevasp.com) directs requests to the appropriate VASP. (iii) Address Resolution via VASP(iv) When a sending VASP processes a payment request to a UMA address, it performs a lookup on the recipient’s VASP using a .well-known UMA configuration endpoint (e.g., https://somevasp.com/.well-known/uma-configuration).
Virtual Asset Service Providers (VASP)	Virtual Asset Service Providers (VASPs) are entities that facilitate transactions involving virtual assets, such as exchanges, custodians, and payment processors. They are critical for regulatory compliance and seamless asset transfers.(i) User Onboarding & Compliance – Perform KYC/AML checks to verify users and meet regulatory requirements (e.g., FATF Travel Rule).(ii) Address Resolution: When a transaction is initiated, the sending VASP resolves the recipient’s UMA address to retrieve transaction details from the receiving VASP.(iii) Transaction Processing – The sending VASP requests payment parameters, including supported currencies and exchange rates, before generating a Lightning invoice or fiat transaction.(iv) Settlement & Record Keeping – Transactions are finalized on the Lightning Network or internally within the VASP. Regulatory data is stored and shared if required.
UMA Payment Process:	(i) UMA Address: A UMA address comprises a username and a domain, prefixed by a $ symbol (e.g., $alice@vasp.com). This format aligns with the Lightning Address (LUD-16) standard, ensuring compatibility and ease of use. (ii) The sending VASP retrieves the UMA configuration of the recipient’s VASP by accessing a JSON object located at https://vasp.com/.well-known/uma-configuration.(iii) Using the information from the UMA configuration, the sending VASP constructs an LNURL Pay (LNURLP) request to initiate the payment process. This request is sent to the recipient VASP’s designated endpoint, typically specified in the UMA configuration document. (iv) The recipient VASP responds with an LNURLP response containing necessary payment parameters, such as the recipient’s preferred currency, exchange rates, and compliance requirements. This step ensures that both VASPs are aligned on the transaction details and adhere to regulatory obligations like the Travel Rule. (v) Based on the LNURLP response, the sending VASP generates a payment request (PayReq) that includes specifics like the payment amount, currency, and any additional compliance information. This request is then sent to the recipient VASP for processing. (vi) Upon receiving the PayReq, the recipient VASP creates an invoice corresponding to the payment details. The sending VASP settles this invoice, completing the transaction. (vii) After the transaction, both VASPs may engage in post-transaction compliance checks, such as record-keeping and reporting, to ensure adherence to regulatory standards.NOTE: The system automatically converts the sender's currency to Bitcoin, which is then transferred quickly via the Lightning Network. (The recipient's VASP converts the Bitcoin back to the recipient's preferred currency, completing the entire process almost instantly.

UMA Address

UMA (Universal Money Address) serves as user identifiers for transactions handled by Virtual Asset Service Providers (VASPs). These addresses streamline interoperability between different VASPs, ensuring seamless payments and regulatory compliance (e.g., Travel Rule compliance).How UMA Addresses Work with VASPs: (i) A UMA address (e.g., $alice@somevasp.com) represents an account managed by a VASP. (ii) domain name (somevasp.com) directs requests to the appropriate VASP. (iii) Address Resolution via VASP(iv) When a sending VASP processes a payment request to a UMA address, it performs a lookup on the recipient’s VASP using a .well-known UMA configuration endpoint (e.g., https://somevasp.com/.well-known/uma-configuration).

Virtual Asset Service Providers (VASP)

Virtual Asset Service Providers (VASPs) are entities that facilitate transactions involving virtual assets, such as exchanges, custodians, and payment processors. They are critical for regulatory compliance and seamless asset transfers.(i) User Onboarding & Compliance – Perform KYC/AML checks to verify users and meet regulatory requirements (e.g., FATF Travel Rule).(ii) Address Resolution: When a transaction is initiated, the sending VASP resolves the recipient’s UMA address to retrieve transaction details from the receiving VASP.(iii) Transaction Processing – The sending VASP requests payment parameters, including supported currencies and exchange rates, before generating a Lightning invoice or fiat transaction.(iv) Settlement & Record Keeping – Transactions are finalized on the Lightning Network or internally within the VASP. Regulatory data is stored and shared if required.

UMA Payment Process:

(i) UMA Address: A UMA address comprises a username and a domain, prefixed by a $ symbol (e.g., $alice@vasp.com). This format aligns with the Lightning Address (LUD-16) standard, ensuring compatibility and ease of use. (ii) The sending VASP retrieves the UMA configuration of the recipient’s VASP by accessing a JSON object located at https://vasp.com/.well-known/uma-configuration.(iii) Using the information from the UMA configuration, the sending VASP constructs an LNURL Pay (LNURLP) request to initiate the payment process. This request is sent to the recipient VASP’s designated endpoint, typically specified in the UMA configuration document. (iv) The recipient VASP responds with an LNURLP response containing necessary payment parameters, such as the recipient’s preferred currency, exchange rates, and compliance requirements. This step ensures that both VASPs are aligned on the transaction details and adhere to regulatory obligations like the Travel Rule. (v) Based on the LNURLP response, the sending VASP generates a payment request (PayReq) that includes specifics like the payment amount, currency, and any additional compliance information. This request is then sent to the recipient VASP for processing. (vi) Upon receiving the PayReq, the recipient VASP creates an invoice corresponding to the payment details. The sending VASP settles this invoice, completing the transaction. (vii) After the transaction, both VASPs may engage in post-transaction compliance checks, such as record-keeping and reporting, to ensure adherence to regulatory standards.NOTE: The system automatically converts the sender's currency to Bitcoin, which is then transferred quickly via the Lightning Network. (The recipient's VASP converts the Bitcoin back to the recipient's preferred currency, completing the entire process almost instantly.

Lightning URLs

LNURL	LNURL: Simplifies Bitcoin payments by providing reusable, user-friendly Lightning Network payment requests. Key innovations are static, reusable Lightning payment requests, removing per-transaction invoice generation, instead of generating new invoice (QR Code) each time. Example:lnurl1dp68gurn8ghj7cn5vdcxz7fwdd6kk6mn9ehhyee0gf2yxt64f9xyu42jfshhqcte9a5j75zjwpcywa66war9g5mxw4vng4zvgfxhq5jyya9mwp Created by Rusty Russell (Blockstream, 2019); enhanced by Anton Kumaigorodskiy (Wallet of Satoshi). 1. LNURL Channel Requests: Allows users to purchase inbound “liquidity” on the Lightning Network by scanning a QR code provided by a service provider. Upon scanning, the wallet makes an HTTPS callback request, receiving channel-opening instructions (node connection details, capacity limits). The wallet connects to the remote node, sends a second HTTPS callback and the service provider then opens a Lightning channel, enabling inbound payments without manually negotiating liquidity. 2. LNURL Withdraw Request: Enables Lightning Network withdrawals from services (e.g., Bitcoin ATMs) via a static QR code. A user scans the QR, starting an HTTPS callback request; the server responds with minimum and maximum withdrawal amounts. The wallet sends back the desired withdrawal amount and an invoice via a second HTTPS callback, enabling the server to execute the payment instantly over Lightning. 3. LNURL Pay Request: Allows static, reusable Lightning invoices, significantly improving payment usability (e.g., streaming tips or donations). Users scan a static QR code, prompting an HTTPS callback request; the server returns details (min/max payment, callback URL). The wallet then requests an invoice via a second HTTPS callback specifying the payment amount; the server returns a dynamic Lightning invoice, allowing immediate payment. Example of HTTPS callbacks to dynamically fetch invoices from fixed URLs or QR codes. OriginUser scan QR Code → Opens URL https://merchant.com/lnurl/payment-request?id=123456, Gets a URL with a callback:{ "callback": "https://merchant.com/lnurl/payment-callback?id=123456", "...": …,}Sends another request: GET https://merchant.com/lnurl/payment-callback?id=123456&amount=500000Receives Lightning network info{ "pr": "lnbc5u1ps....(lightning invoice)...", "routes": []}4. LNURL Auth: Enables website authentication using Bitcoin wallet signatures, eliminating usernames and passwords. Users scan a QR code, authenticate via wallet-signed cryptographic signatures, and websites validate against public keys. 5. LNURL Hosted Channel Request: Allows users to quickly establish Lightning channels managed by trusted third parties (custodians) without blockchain transactions. Users scan an LNURL, connect to the third-party node, and use hosted channels for payments—simple, fast, but relies on custodial trust. Use Cases: Popular real-world uses include tipping (“Zaps”) via NOSTR, intuitive payment methods resembling credit-card experiences, and easy-to-use Bitcoin ATMs, significantly lowering the barrier to Bitcoin adoption. Issues: Often this results in more centralization as it requires operators of centralized nodes and services.
UMA’s additiona on LNURL	Notes Jeremy Klein (Author/Maintainer): “UMA builds on LNURL and lightning addresses to add a few things. It was designed to be fully compatible with LNURL counterparties, but with progressive enhancement where needed. The first addition is cross-currency payments via this Lud-21 spec: github.com/lnurl/luds/pull/251. The second primary addition is a bunch of stuff that doesn't belong in LNURL to support regulated financial institutions (used by folks like Nubank, Xapo Bank, ZeroHash, etc.). A lot of this builds on LUD-18 (payerdata) to add signatures from counterparties and a bit more comprehensive counterparty data exchange mechanisms for stuff like travel rule. This payee data proposal is part of this: github.com/lnurl/luds/pull/252. We also have SDK support for 5 languages and a protocol built on Nostr Wallet Connect called UMA Auth, which allows you to connect your wallet to any 3P client application: docs.uma.me/uma-auth/introduction”Payee Identity: LUD 22: Introduces a method for the payer to request identity info from the payee before executing a Lightning payment. This enhances security by enabling the sender’s wallet to verify and display payee identity details, ensuring funds reach the intended recipient. Key Technical Changes: (i) Implements a payee-side equivalent of LUD-18 (payer-side verification). (ii) Includes an optional challenge-response authentication mechanism (k1) allowing payees to cryptographically verify identity, mitigating certain compromise risks.Multi-Currency: LUD21: Extends LNURL payRequest to support payments denominated in multiple currencies, facilitating seamless currency conversion in Lightning wallets and services. Key Technical Changes: (i) structured currency array (currencies) for defining currency support, preferences, and display parameters (e.g., displayDecimals).(ii) Implements a standardized multiplier field indicating the conversion rate to millisatoshis, aligning with existing UMA specifications.

LNURL

LNURL: Simplifies Bitcoin payments by providing reusable, user-friendly Lightning Network payment requests. Key innovations are static, reusable Lightning payment requests, removing per-transaction invoice generation, instead of generating new invoice (QR Code) each time. Example:lnurl1dp68gurn8ghj7cn5vdcxz7fwdd6kk6mn9ehhyee0gf2yxt64f9xyu42jfshhqcte9a5j75zjwpcywa66war9g5mxw4vng4zvgfxhq5jyya9mwp Created by Rusty Russell (Blockstream, 2019); enhanced by Anton Kumaigorodskiy (Wallet of Satoshi). 1. LNURL Channel Requests: Allows users to purchase inbound “liquidity” on the Lightning Network by scanning a QR code provided by a service provider. Upon scanning, the wallet makes an HTTPS callback request, receiving channel-opening instructions (node connection details, capacity limits). The wallet connects to the remote node, sends a second HTTPS callback and the service provider then opens a Lightning channel, enabling inbound payments without manually negotiating liquidity. 2. LNURL Withdraw Request: Enables Lightning Network withdrawals from services (e.g., Bitcoin ATMs) via a static QR code. A user scans the QR, starting an HTTPS callback request; the server responds with minimum and maximum withdrawal amounts. The wallet sends back the desired withdrawal amount and an invoice via a second HTTPS callback, enabling the server to execute the payment instantly over Lightning. 3. LNURL Pay Request: Allows static, reusable Lightning invoices, significantly improving payment usability (e.g., streaming tips or donations). Users scan a static QR code, prompting an HTTPS callback request; the server returns details (min/max payment, callback URL). The wallet then requests an invoice via a second HTTPS callback specifying the payment amount; the server returns a dynamic Lightning invoice, allowing immediate payment. Example of HTTPS callbacks to dynamically fetch invoices from fixed URLs or QR codes. OriginUser scan QR Code → Opens URL https://merchant.com/lnurl/payment-request?id=123456, Gets a URL with a callback:{ "callback": "https://merchant.com/lnurl/payment-callback?id=123456", "...": …,}Sends another request: GET https://merchant.com/lnurl/payment-callback?id=123456&amount=500000Receives Lightning network info{ "pr": "lnbc5u1ps....(lightning invoice)...", "routes": []}4. LNURL Auth: Enables website authentication using Bitcoin wallet signatures, eliminating usernames and passwords. Users scan a QR code, authenticate via wallet-signed cryptographic signatures, and websites validate against public keys. 5. LNURL Hosted Channel Request: Allows users to quickly establish Lightning channels managed by trusted third parties (custodians) without blockchain transactions. Users scan an LNURL, connect to the third-party node, and use hosted channels for payments—simple, fast, but relies on custodial trust. Use Cases: Popular real-world uses include tipping (“Zaps”) via NOSTR, intuitive payment methods resembling credit-card experiences, and easy-to-use Bitcoin ATMs, significantly lowering the barrier to Bitcoin adoption. Issues: Often this results in more centralization as it requires operators of centralized nodes and services.

UMA’s additiona on LNURL

Notes Jeremy Klein (Author/Maintainer): “UMA builds on LNURL and lightning addresses to add a few things. It was designed to be fully compatible with LNURL counterparties, but with progressive enhancement where needed. The first addition is cross-currency payments via this Lud-21 spec: github.com/lnurl/luds/pull/251. The second primary addition is a bunch of stuff that doesn't belong in LNURL to support regulated financial institutions (used by folks like Nubank, Xapo Bank, ZeroHash, etc.). A lot of this builds on LUD-18 (payerdata) to add signatures from counterparties and a bit more comprehensive counterparty data exchange mechanisms for stuff like travel rule. This payee data proposal is part of this: github.com/lnurl/luds/pull/252. We also have SDK support for 5 languages and a protocol built on Nostr Wallet Connect called UMA Auth, which allows you to connect your wallet to any 3P client application: docs.uma.me/uma-auth/introduction”Payee Identity: LUD 22: Introduces a method for the payer to request identity info from the payee before executing a Lightning payment. This enhances security by enabling the sender’s wallet to verify and display payee identity details, ensuring funds reach the intended recipient. Key Technical Changes: (i) Implements a payee-side equivalent of LUD-18 (payer-side verification). (ii) Includes an optional challenge-response authentication mechanism (k1) allowing payees to cryptographically verify identity, mitigating certain compromise risks.Multi-Currency: LUD21: Extends LNURL payRequest to support payments denominated in multiple currencies, facilitating seamless currency conversion in Lightning wallets and services. Key Technical Changes: (i) structured currency array (currencies) for defining currency support, preferences, and display parameters (e.g., displayDecimals).(ii) Implements a standardized multiplier field indicating the conversion rate to millisatoshis, aligning with existing UMA specifications.

Questions

What happens if a service provider VASP goes down. Can the transaction be routed to any bank or project that supports VASP?

References

https://github.com/lnurl/luds/pull/251
https://github.com/lnurl/luds/pull/252One note - UMA doesn't necessarily need to use Lightspark for Lightning services because it's just an open protocol, so any Lightning node is fine.

!This config file is actually for something else. The lnurlp request just works the same as LUD-16 - the request endpoint is https://vasp.com/.well-known/lnurlp/<user_name> as shown in the little diagram you have above.

The WhitePaper Reading Club Singapore [27]	11 March 2025
Universal Money Address (UMA)
Other Summaries: https://bit.ly/WPRC_Analysis	Rongxin, L, Jeremy Klein (LightSpark)