The idea is to use the fact that a Lightning channel already has on-chain funds locked up, which can be moved into the 2/3 MultiSig output needed for the escrow scheme by cooperating off-chain. The proposed solution includes three scenarios: Smart Contracts in a Lightning Channel; Single Hop Smart Contracts, useful if someone wants to provide a hub that matches users wanting to enter smart contracts; and Fully Routed Smart Contracts. Each scenario presents its own set of challenges and problems, including ensuring that only B can claim the 2/3 MultiSig from C in the Single Hop Smart Contracts scenario. Transporting over multiple hops requires compliance to make one side reveal information that the other side does not know, together with some kind of timeout/backoff. Therefore, far fewer contracts can be transported over the network. A Lightning channel is itself a contract and is transportable only within a direct channel, forming the basis of channel factories. Additionally, the email notes that escrow services are essentially oracles and that it may be possible for Smart Contracts Unchained to transport the federation/escrow signatures over multiple hops if DLCs can transport their oracle signatures over multiple hops.