One key change that has been implemented is the transition from CheckSequenceVerify (CSV) to CheckLockTimeVerify (CLTV) in locking leasor funds, a move motivated by the need to resolve complications associated with anchor outputs and updating commitment transactions. The concept of 'lease locked' transactions has been introduced to protect leasor funds from being prematurely accessed, notably when HTLCs are part of the leasee's commitment transactions. This security measure ensures that the leasor cannot claim their funds before the lease period concludes and was developed as a response to vulnerabilities highlighted by @morehouse.

In addition to these security measures, the system now permits variable lease terms, contrasting with the previous model of fixed one-month durations. Leasors can adjust their rates based on the length of the leases they offer, likely leading to increased costs for longer commitments. Fee structures have also been refined, with more granular increments allowing for better pricing precision. Current discussions include contemplating whether to maintain a fixed base fee cap or adopt a variable approach, as suggested by @t-bast.

An issue currently at the forefront is the necessity for remote peer signatures in 2nd-stage lease locked transactions and the implementation challenges it presents. Directly incorporating additional CLTV constraints into outputs to avoid second-stage transactions altogether is being considered but remains uncertain in feasibility. A related concern involves the behavior of Replace-By-Fee (RBF) attempts, which has sparked proposals to treat RBF as independent renegotiations, distinct from prior liquidity purchase terms. The introduction of new funding tlv fields for RBF messages aligns with this approach and would be compatible with splicing methodologies.

The discussion extends to the concept of fraud proofs within channel fee commitments. The idea is to hold leasors accountable if they commit to specific fee caps and later exceed them. There is interest in implementing a bond or penalty for such violations, but creating cryptographic commitments for value ranges is technically challenging, and community input is sought on this matter.

The Liquidity Ads specification itself has been revised based on community feedback since its initial release in core-lightning v0.10.1. Contributions during the CLN hack week and subsequent interactions have played a crucial role in refining this proposal. For those interested in an in-depth exploration of these updates, the draft and commits are accessible through the links provided in the correspondence.