Lightning Labs launches Wavelength ark-style Bitcoin payment platform. 21 July 2026, 20:38:02 GMT +0000 Lightning Labs has launched Wavelength, an Ark-style Bitcoin payment platform, marking a new entry in the effort to make Bitcoin more usable for everyday payments. What Lightning Labs announced with Wavelength. Lightning Labs, the company behind much of the Lightning Network's core software, has introduced Wavelength as a Bitcoin payment platform. Details on the launch are published on the project's own site at Wavelength's documentation. For related coverage, see Bitcoin $84,000 CME Gap: What Traders Are Watching. The platform is positioned specifically around Bitcoin payments rather than a broader multi-asset use case. At this stage, the confirmed scope is limited to the launch itself and the way Lightning Labs frames the product. For related coverage, see Solv Protocol Integrates Utexo for Native Bitcoin Income on RGB and Lightning. No launch markets, user numbers, or release timelines beyond the announcement are established in the available material. Readers should treat the launch as the confirmed event and wait for further reporting on rollout specifics. For related coverage, see Top Bitcoin Casino Sites In 2026. What "ark-style" Means in the Wavelength framing. Wavelength is described as "Ark-style," a reference to Ark, a proposed Bitcoin scaling and payments design. Ark's stated goal, per its introductory documentation, is to let users transact off-chain while retaining a path back to the base Bitcoin blockchain. For related coverage, see How To Buy Bitcoin With Visa Gift Cards in 2026. The Wavelength project publishes its own explanation of how users can exit the system in its "leaving Ark" concept notes. That framing signals a design centered on off-chain payments with an on-chain fallback. It is important to separate the headline framing from verified technical specifics. Custody arrangements, throughput, and settlement flow are not independently confirmed here, so the "Ark-style" label should be read as a design descriptor, not a validated performance claim. Why Wavelength matters for Bitcoin payment infrastructure. A launch, rather than a concept discussion, is what makes Wavelength notable. New Bitcoin payment infrastructure tends to draw attention because Bitcoin's base layer is slow and costly for small, frequent transfers. Wavelength enters a space where other teams are also targeting faster Bitcoin payments. GoMining recently launched GoBTC Pay for native instant Bitcoin payments, and Solv Protocol has integrated Utexo across RGB and Lightning, underscoring active competition around Bitcoin usability. The significance here is inferred from the launch framing, not proven adoption. Wavelength's relevance to scaling and everyday spending remains a potential outcome rather than a demonstrated result. Why Lightning Labs is central to the Wavelength story. Lightning Labs is the main actor readers will search for, as it is the company directly tied to the Wavelength launch. Its established role in Lightning Network development is why this product carries more weight than a generic wallet or app release. No other company or network operator is named in connection with Wavelength in the available context. That keeps the story centered on Lightning Labs as both the builder and the brand behind the platform. FAQ about Lightning Labs Wavelength and ark-style Bitcoin payments. What is Wavelength? Wavelength is a Bitcoin payment platform launched by Lightning Labs and described as Ark-style, according to the project's official announcement on X. Who launched Wavelength? Lightning Labs launched Wavelength. The company is the sole entity named as the builder in the available information. What does "Ark-style" mean in this story? It refers to a Bitcoin payments design in the style of Ark, which enables off-chain transactions with a route back to the main chain. The label describes the approach, not confirmed technical performance. Why does this matter for Bitcoin payments? Bitcoin's base layer is not well suited to small, frequent payments, so infrastructure launches like Wavelength are watched for their potential to improve usability. Concrete adoption and performance data are not yet established. Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice. Cryptocurrency and digital asset markets carry significant risk. Always do your own research before making decisions. Rate this post No tags available. Digital marketing pro | | Crafting content that connects Coincu.com | Educating on crypto trends, market moves, and meme coins | | Japan to the moon | #CryptoEducator #MarketMaker #Coincu

Lightning Labs launches Taproot Assets v0.8 for Bitcoin stablecoin development. Phemex News 2026/06/23 17:56 Lightning Labs has unveiled Taproot Assets v0.8 and an accompanying SDK, facilitating the integration of stablecoin capabilities on the Bitcoin network. The SDK introduces features like backup and recovery, multi-asset liquidity control, and enhanced proof verification, aimed at boosting infrastructure efficiency. Lightning Labs emphasized the arrival of a multi-asset Bitcoin future and urged developers to begin utilizing these tools. Disclaimer: The content provided on Phemex News is for informational purposes only. Phemex do not guarantee the quality, accuracy, or completeness of the information sourced from third-party articles. The content on this page does not constitute financial or investment advice. Phemex strongly encourage you to conduct you own research and consult with a qualified financial advisor before making any investment decisions.

Announcing LND v0.21-beta: grown up, sped up, locked down. Mohammad Suheb Khan June 11, 2026 Lightning is excited to announce the release of LND v0.21! Fittingly, its latest release lands on a number that bitcoiners know well, a nod to the 21 million bitcoin supply cap, and this release is something of a coming-of-age moment for LND. This release brings privacy-preserving onion message support to LND for the first time, graduates simple taproot channels to a production-ready feature, and continues its journey of moving LND's data stores onto a native SQL backend. Together, these changes lay the foundation for a more private, more capable, and more performant Lightning Network. Some of the release highlights include: * Basic onion messaging support, a privacy-preserving way for nodes to send messages through the network without revealing the sender or route, introduced via a new peer-to-peer message type. This paves the way for advanced privacy features and future protocol upgrades like BOLT 12 offers. * Production-ready simple taproot channels with the finalized taproot channel scripts, optimized signature checks, and RBF cooperative close support. This sets the stage to finalize taproot gossip, eventually leading to public taproot channels. * Payment store migration to native SQL, continuing the data store modernization journey, for better performance and scalability. * Fast initial sync for Neutrino nodes which cuts the initial sync for a fresh light-client node from hours to minutes on mainnet, by bootstrapping its block and filter headers from a file or URL instead of fetching them one at a time from peers. As always, Lightning is grateful for the ongoing support of its external contributors and community across development, review, and testing. For the complete list of changes included in this release, check out the full release notes. Onion messaging arrives in LND. Onion messages are a privacy-preserving way for Lightning nodes to send messages to one another through the network without exposing the sender or the route the message follows. This is the same mechanism that powers BOLT12 offers, a Lightning specification for reusable invoices. With v0.21, LND can now forward onion messages on behalf of its peers, taking its first step toward becoming a full participant in the messaging layer for BOLT12. For node operators, this means your node can now relay these private messages for its peers, helping the network move toward features like BOLT12 invoice requests, improving receiver privacy for BOLT12 offers. The idea builds on something Lightning already does: today, payments are routed using onion encryption, where each node in the path peels back a single layer to learn only the next hop, never the full route or the original sender. Onion messaging applies that same routing technique to standalone messages that aren't tied to a payment, so nodes can pass information through the network with the same sender and route privacy that payments already enjoy. Because these messages aren't attached to a channel update, relaying one is lightweight: there's no commitment transaction and no on-chain footprint. Since your node relays these messages on behalf of others, LND ships with sensible defaults so the feature can't be abused at your expense. Messages from peers without an open channel are dropped by default, so only peers that have committed capital can use your node as relay infrastructure, and per-peer and global rate limiters cap how much traffic any peer can drive. Operators who want to accept messages from all peers can opt in via protocol.onion-msg-relay-all=true, with the rate limiters still applied. For the full adversary model, defaults, tunable flags, and operator recipes, see the onion messaging rate limiting section on the LND repo. Simple taproot channels are ready for production. Simple taproot channels bring the privacy and efficiency benefits of taproot to Lightning channel funding. By using taproot key-path spends, the on-chain footprint of a Lightning channel can look indistinguishable from any other taproot transaction, improving privacy for all Lightning users. With v0.21, this graduates from its previous experimental status to a production-ready feature, meaning taproot channels are now safe to use on mainnet with the finalized channel scripts (feature bits 80/81). Taproot channels also now support the RBF (Replace-By-Fee) cooperative close protocol via -protocol.rbf-coop-close, which lets you bump the fee on a stuck, unconfirmed cooperative close transaction, just like you can on legacy channels. Behind the scenes this uses MuSig2, a scheme for combining multiple signatures into one, with careful handling to prevent nonce reuse across fee-bump attempts. Being able to raise the fee on a stuck close transaction is a meaningful quality-of-life improvement in volatile fee environments. The SQL migration continues. Continuing its quest to make node operations more performant and scalable, v0.21 migrates the payments database to native SQL. For node operators, this means faster, more scalable payment-history queries. Under the hood, this release introduces a payment store interface, implements the SQL schema with query and insert methods, threads context through the payment DB layer, and adds the KV-to-SQL payments migration. Users already on postgres or sqlite backends with -db.use-native-sql set will have their payments migrated automatically on startup. As with the SQL migrations in previous versions, nodes still on bbolt, the key-value (kvdb) database LND has historically used, can use the lndinit tool to migrate to sqlite or postgres first to take advantage of these new capabilities. For nodes that have completed the migration to postgres or sqlite, Lightning has measured over 97% wall-time reduction on the ListPayments RPC for large databases after migrating over to native SQL. If you've been holding off the DB migration for performance reasons, this is a good release to commit to the move. Lightning encourage operators who haven't already, to run the migration process with this release and see the gains firsthand. Faster sync for Neutrino nodes. If you run LND in Neutrino mode, the light-client backend that works without a full Bitcoin node, spinning up a fresh node used to mean waiting hours while it fetched block and filter headers one at a time from peers. With v0.21, a new node can instead bootstrap those headers from a local file or HTTP(S) URL on first startup, cutting initial sync on mainnet from hours to minutes. Imported headers are still validated for proof-of-work, and once the import finishes the node falls back to normal peer-to-peer sync to reach the chain tip. Quality-of-Life and usability improvements. This release also brings several updates designed to make day-to-day node management more convenient and to add additional safety margins to operations. Safer Channel Closes: Channel closes now require between 3 and 6 confirmations instead of being finalized immediately on spend detection. The requirement scales linearly with channel capacity up to the standard maximum and large "wumbo" channels (those above the standard capacity limit of ~16.7M sats) always require 6 confirmations. Waiting for confirmations protects your node against chain reorganizations: rather than acting the moment it sees a close, LND waits until the close is buried deep enough that a reorg is very unlikely to undo it, keeping your view of channel state consistent with the chain. Faster Startup After Restart: The channel graph cache now loads asynchronously on startup. Queries are served directly from the database until the cache is ready, so LND becomes query-ready sooner after a restart. The previous behavior is still available via -db.sync-graph-cache-load. Run Multiple Read-Only RPC Middlewares: LND lets external tools register as RPC middleware to observe your node's API traffic. Until now, only one read-only middleware could be registered at a time, which created a real conflict: if you ran Lightning Terminal, Lightning Labs' node management interface, its built-in logging middleware took the only slot, so you couldn't attach a read-only middleware of your own. v0.21 lifts that limit, so multiple read-only middlewares can run side by side, each independently observing RPC activity. More Granular Forwarding History Management: The new DeleteForwardingHistory RPC on the router sub-server lets operators selectively purge old forwarding events. These events record the payments your node has routed for others, including amounts, timing, and the channels involved. Clearing them reduces the sensitive routing data your node keeps on hand, so less is exposed if your node or its data is ever compromised. Deletion requires a cutoff timestamp at least 1 hour in the past to prevent accidental removal of recent data. The LND release for 21 million bitcoin. The architectural advances in v0.21, namely onion messaging support, production-ready taproot channels, and the continued migration of LND's data stores to native SQL, are foundational steps toward a more private, more performant, and a more capable Lightning implementation. Onion messaging unlocks an entire category of future privacy-preserving features. Production taproot channels lay the groundwork for splicing and other advanced channel management workflows. And each step in the SQL migration journey moves LND further away from the kvdb data stores that have historically held back LND's performance at scale. Upgrade to v0.21 today to get all the benefits of the latest release. Lightning'd like to thank the entire community for their feedback on and contributions to this release, and Lightning look forward to hearing from you. You can find Lightning on the LND Slack, reach out to Lightning on Twitter/X, contribute a PR, or subscribe to its newsletter.