The proposal suggests avoiding the creation of a vendor-specific extension to PSBT (Partially Signed Bitcoin Transactions) for demonstrating that all inputs meet this criteria. Instead, it advocates for a specialized protocol tailored to this requirement. This approach is recommended to avoid the potential risks associated with under-specifying the PSBT-based extension, which could lead to vulnerabilities if implementations fail to perform necessary checks on the PSBT. Such oversights could compromise the security by allowing an attacker to introduce additional fields into the transaction.

For standard on-chain spend protocols, the use of PSBT is deemed fairly safe, as its application does not deviate significantly from operations performed by hardware wallets. In these scenarios, Bob, the recipient, does not have a stake in the funds and essentially acts as an external hardware wallet for Alice, the sender. This arrangement, while posing certain risks for Alice, particularly in terms of the security implications of using a hot wallet model implied by Lightning Network transactions, does not present new risks for Bob.

The novelty and associated risk come into play with trust-minimized 0-conf Lightning funding transactions. These transactions are considered potentially risky due to the introduction of new PSBT fields. The acceptance of zero-confirmation (0-conf) off-chain operations by Bob is contingent upon the assurance that all inputs originate from swap-in-potentiam funds. If the source of funds does not meet this criterion, Bob must wait for confirmation before proceeding. The primary benefit of utilizing swap-in-potentiam funds lies in the ability for Alice to go offline after initiating the transaction, aligning with use cases where Alice operates a mobile wallet and is seldom online. This feature is crucial for maintaining correct behavior in common scenarios, although it may also accommodate edge cases that arise when Alice is online.