Lightning Labs opened Wavelength's public mainnet on October 23, 2026. The announcement covers bitcoin payments, describes stablecoins as a future addition and still calls the software alpha. Its linked browser demo uses signet. A public mainnet launch therefore does not mean every demonstration or every asset mentioned in the roadmap is ready for real-value payments.
Identify which component the launch actually covers
The v0.2.0 release independently identifies itself as the first public mainnet release. Its notes concern the daemon and wallet behavior, including clearer payment states and recovery. That is useful version evidence, but it does not establish that an arbitrary web application has adopted the release or configured the same network.
| Item being evaluated | Evidence to record | Assumption to avoid |
|---|---|---|
| Public mainnet release | Exact release and its current setup instructions | Every example already uses production settings |
| Browser demonstration | Its explicitly selected Bitcoin network | A demo balance is a real bitcoin balance |
| Stablecoin roadmap | Whether support is announced as available or still planned | Any stablecoin ticker can be sent now |
| An app's payment request | Asset, network, payment type and displayed costs | A launch headline confirms this particular request |
| An app or agent credential | The permissions actually granted | A credential described as receiving-only can also spend |
Keep this record about the deployed component, not just the product name. A development team might read the correct launch post while still testing a separate browser package against a test environment. A person paying that application needs the application's real instructions. Matching names are not enough to establish matching networks or permissions.
The documentation currently needs a version check
The SDK network-configuration page reviewed for this article still says its presets cover signet and testnet, and includes an older statement that there is no public mainnet deployment. That conflicts with the dated launch and v0.2.0 release. Treat it as a documentation-scope problem to resolve before deployment, not as proof that the launch never occurred.
Do not fix that disagreement by copying a flag from a different example and sending funds. Ask which package version and deployment instructions apply to your integration. The same configuration guide requires backend services to use the same Bitcoin network. A mixed configuration is not made consistent by changing only the label shown in the interface.
A signet demonstration is a separate environment
Suppose a developer demonstrates a completed payment in signet and then describes the product's mainnet announcement. The demonstration proves only what was tested in that environment. It does not test mainnet fees, receiving availability or recovery under production conditions. Record the test network plainly in screenshots and handover notes instead of letting a successful animation stand in for deployment evidence.
Permission and payment amount are different controls
The launch post describes receiving-only credentials that cannot sign, recover or administer the wallet. That is a boundary on actions, not a universal spending budget. A service that needs to receive money should not be assumed to need a credential with broader powers merely because the toolkit also supports automated spending.
For any integration that will authorize payments, define the intended operations and how their results will be reviewed before connecting real funds. Keep the wallet's secrets outside ordinary app support conversations. Do not interpret automation in the announcement as a requirement to give an assistant unrestricted access or paste a recovery phrase into its chat.
Free refresh does not mean every operation is free
The v0.2.0 notes distinguish free-only automatic refresh from paid refresh requested explicitly and exits that can incur on-chain mining fees. Those are different operations. Read the current preview for the action you intend; a zero-cost maintenance path is not a quote for sending, receiving or leaving the system.
A practical release-reading checklist
- Write down the exact client or package version rather than relying on the product name.
- Confirm the network for the wallet and every required backend component.
- Check that the intended asset and payment type are supported now, not merely on a roadmap.
- Review the permission scope and the current operation's cost preview separately.
- Resolve conflicting setup instructions with the maintainer before using real funds; keep test results labelled with their actual environment.
If a later ordinary swap is needed, inspect its supported assets and exchange process independently. Wavelength's mainnet launch does not establish KOT.CASH integration or support for a particular Lightning route. An invoice, an on-chain address and an exchange order each belong to their own stated operation.
No wallet was created, package installed or real payment tested for this review. Before adopting the toolkit, check stablecoin availability, the release status and the conflicting SDK page. Preserve the distinction between a dated product launch and evidence that a specific application can accept a specific payment today.
FAQ
Does the Lightning Wavelength mainnet launch include stablecoins?
The October 23 announcement describes bitcoin payments and says stablecoins are coming later. Do not infer support for a particular stablecoin from that roadmap statement.
Does the Wavelength Lightning Labs demo prove my app is ready for mainnet?
The launch post identifies the browser demo as signet. A test in that environment does not establish your application's production configuration or receiving path.
Can a Lightning invoice from a test demonstration be treated as a real payment request?
First identify the environment and the request's intended operation. A mainnet product announcement does not change the network of an existing demonstration or validate its payment details.