1. Status Quo**: Packet-Forward Middleware and current issues with it.**

Union in its most basic form is a decentralized general message passing interoperability chain [1]. Where:

1. Chain A can send a transfer request to Union.
2. Union then passes this request along to chain C.
3. Chain C receives this request and will assume the transfer request must be valid because Union, which chain C trusts, confirms that Chain A wants to send this to Chain C.

flowchart LR
    id1[Chain A] --> id2[Union] --> id3[Chain C]

These transfers are currently relayed through Union by using Packet-Forward Middleware (PFM). PFM has multiple issues associated with it.

Transfers-only: One of the biggest limitations of the PFM is that it's primarily designed to handle IBC transfers [2]. This means it focuses on moving tokens or assets between different blockchains. However, IBC is more than just transfers; it's a general protocol for sending packets of data between chains. PFM doesn't handle non-transfer packets, which means if you need to relay other types of data (like governance proposals or complex smart contract interactions), you’ll need to tinker around this, and basically re-implement PFM. The reason for this, is that a transfer is a specialization of a packet (packet contains bytes, a transfer contains a structured message). PFM attaches the forwarding data to the structured message, instead of generically wrapping any bytes.

Alteration of Original Transfers: When using PFM, the original transfer contains the appropriate forwarding information to go from origination chain, via Union, to any destination chain [2]. On Union, the forwarding information in the original IBC transfer is stripped, thus altering the original packet data, and a new transfer is created (see the example below). This new transfer is then being send from Union to the destination chain. Because the original packet data was altered, the merkle inclusion proof is different. This makes it more difficult to audit or trace the transaction back to its origin. Although it is possible to trace a transaction back as an off-chain party, on-chain it is almost impossible.

Chain A → Union Transfer:

{
	sender: Karel
	recipient: PFM
	amount: 10
	extension: {
		forward: {
			port: 1,
			channel: 3,
			recipient: Robert
		}
	}
}

Union → Chain C (after PFM rewrites) Transfer:

{
	sender: Karel
	recipient: Robert
	amount: 10
}

Complex Routing Limitations: In IBC, each packet is assigned a sequence number that helps track the order of transactions and if a packet has already been handled. As previously stated, when Union forwards a packet by using PFM, Union creates a new transaction with a new sequence number, disrupting the continuity of transaction history. This loss of continuity complicates scenarios where you need to follow the exact order of events across multiple chains. Like in complex routing, where packets pass through multiple chains with specific instructions, the new sequence numbers on each leg make it significantly harder to maintain the correct order of execution.

2. State lenses: How they fix the above

A state lens is a conditional light client that is designed to extract state roots of specific chains from the state root of Union.