Introduction

The proposed flow with two transactions ensures that users can securely validate the bridging transaction without relying on any third party. However, two on-chain transactions create several UX issues, such as running out of gas for the second transaction. We propose a "1 transaction + signature" flow, where bridging can ultimately happen with only one transaction.

1 transaction + signature

As described in the protocol specification, the first transaction represents the user's intent and commitment, while the second transaction confirms the LP's transaction. We propose a new function lockCommitment_Signature that will receive the user's signature to confirm the LP's hashlock. This transaction can be executed by the LP.

Transaction Flow

sequenceDiagram
    participant P1 as Party 1
    participant SC as Source Chain
    participant P2 as Party 2
    participant DC as Destination Chain

	
    P1->>SC: commit()
    SC-->>P2: TokenCommitted
    P2->>DC: lock()
    DC-->>P1: TokenLocked
    P1->>P2: Signature(Hashlock)
    P2->>SC: lockCommitment_Sig()
    SC-->>P2: TokenLocked
    P2->>DC: redeem()
    DC-->>P1: TokenRedeemed
    P2->>SC: redeem()
	  SC-->>P2: TokenRedeemed

Conclusion

Instead of the user performing a second transaction, the user now only needs to complete one transaction and provide a signature for the second one. This signature is then used to lock the commitment object created by the user. With the addition of the Ensure User Funds Are Released in Any Case proposal, which ensures LP actions with strong guarantees, this provides a significant UX improvement over the previous two-transaction flow.