Intents can be defined in various ways depending on the context. Generally, they involve users specifying their desired outcomes rather than dictating the exact steps to achieve them. With intents, you essentially say, "I want to reach this end state," and let others figure out the different ways to get there [1]. In the case of cross-chain intents, intents revolve around allowing third parties, rather than smart contracts, to fulfill the transfers, offering greater flexibility and efficiency in reaching the user’s goals.
Users currently experience long wait times for cross-chain interactions due to the slow finalization of L2s. This is particularly true for optimistic L2s, known for their delayed finalization time, due to fraud proofs [2]. Union has to wait for finalization, to protect itself against double-spend attacks. Intents bridging addresses this issue by allowing solvers (also known as market makers) to instantly fulfill user intents where they become the counterparty, instead of Union. This bypasses the wait for the user.
Thus, for users intents bridging is appealing because they get to experience near-instantaneous order fulfillment. For solvers, it's attractive because new business opportunities are unlocked. And for Union, relying on solvers to provide the near-instant transfer experience is crucial, because Union itself cannot fulfill these orders due to the risk of fund loss caused by a potential reorg or delayed block inclusion [3]. Therefore, solvers enable near-instant transfers for users, though they take on the risk of potential losses. This risk is compensated by the potentially higher fees paid from the users to the solvers.
By introducing intents bridging, Union essentially gets three modus operandi that you can categorize by risk to the filler (or protocol) as follows:
| Risk | Cost | Latency | |
|---|---|---|---|
| Direct verification | Low | Average | Average |
| Indirect verification (Aligned layer) | Low | Semi-low | High |
| Intents bridging | High | Low | Low |
Because there is a higher risk involved with intents bridging, there is also more upside to be gained.
Union architecture does not yet support intents, due to constraints imposed by the Packet Forward Middleware (PFM), as detailed in our state lenses article [4]. Here we describe how to enable intents such that users can dynamically benefit from high trust and low latency transactions
State lenses create a direct connection between Chain A to Chain C, bypassing the need for costly re-execution of transfers as seen in the PFM approach [4]. Therefore, unlike PFM, state lenses allow third parties to anticipate and execute transfers swiftly, even before the originating chain finalizes them. This expands the fulfillment implementation options by enabling multiple third parties to fulfill orders instead of relying on a single protocol. As a result, solvers can fulfill user intents almost instantly, providing users a near-instantaneous fulfillment experience instead of the long transfer completion time they are used to.
For example, when a transfer from Chain A is expected at Chain C, a solver can predict this transfer and submit the transfer to chain C before chain A finalizes. The solver tells chain C to mark the transfer as completed and release the funds. If the actual transfer from Chain A arrives, the contract will recognize it as already completed and reject it. In case the solver provided incorrect details, the hash would differ, avoiding any conflicts (though the solver would incur a loss). IBC’s acknowledgements can then be utilized to reimburse the solver along with any applicable fees.