Among these, the notion of "Bundled Payments" stands out as a pivotal addition. This concept allows for the creation of invoices that can accommodate two separate preimages and amounts, primarily targeting services that require an upfront mining fee. This is especially relevant for non-custodian exchanges and plays a crucial role in submarine swaps and Just-In-Time (JIT) channels, which are critical for secure transactions within the blockchain network.

One of the notable gaps identified in the BOLT12 specification is the absence of a defined prefix for invoices. To bridge this gap, there's a proposal to adopt the lni prefix, which, while not officially specified, has found its application in Core Lightning (CLN) for certain Remote Procedure Calls (RPC), such as fetchinvoice and pay. The use of lni in these contexts suggests an emerging standard within the community, highlighting the need for a formalized approach to invoice prefixes.

Interestingly, the proposed enhancements to BOLT12, including the adoption of the lni prefix and the introduction of bundled payments, are suggested to be implemented as a bLIP (Bitcoin Improvement Proposal) rather than amending the existing specifications. This approach ensures that the core functionalities of BOLT12 remain accessible to users who may not opt for the new features. Further insights into the implementation of trusted contacts within BOLT12, without disrupting its foundational operations, are discussed comprehensively at delvingbitcoin.org.

Recent developments have seen BOLT12 merged into the main repository, marking significant progress in its practical application. This merger initiates discussions on further enhancements, such as the need for invoice_request and invoice writers to replicate all fields from their predecessors, including unknown ones. This introduces a level of structural flexibility that could facilitate the addition of new fields in a backward-compatible manner. Proposals under consideration include adding a user field within the invoice_request and introducing a refund_invoice_required field for offer writers, which would streamline the refund process by automating refunds and eliminating the need for direct interaction with customers for each transaction. Moreover, the suggestion to establish an offer_max_amount within the offer structure aims to address operational constraints and preferences, enhancing transaction management and customer relationship expectations.

The absence of an expiration mechanism for invoice_requests poses challenges in managing offer lifecycles, particularly where timing is crucial. Implementing an expiry similar to that of offers and invoices could improve the protocol's efficiency and reliability. These discussions reflect a collective effort to refine BOLT12, inviting community feedback to guide its evolution in addressing the diverse needs and challenges of real-world implementations.