Solver Implementation

Describes the protocol implementation for the Solcer

1. Monitor the source chain

   Subscribe to TokenCommitted events to detect any commitments made to your address.

2. Lock funds on the destination chain

   • Generate S and hashlock.
   • When a commitment is detected, call lock() on the destination chain and pass the generated hashlock with timelock of $T + 2\Delta$.
3. Verify the commitment lock

   • Monitor the source chain for the TokenLockAdded event (or getDetails() function) on the existing commitment.
   • Once detected, verify that the hashlock matches the one you previously generated.
   • Verify that the timelock provides sufficient time to act, ensuring it is at least $T + \Delta$.
   • Verify that the Id is equal to the original commitment Id in the TokenCommitted event.
4. (signature flow) addLockSig — only when user chose signature flow

   Only applicable if the user explicitly chose the signature flow (see dApp implementation). In that case the user will provide a signed addLock message. The solver (or any authorized submitter) may call addLockSig() providing the user’s signature and the signed message data (Id, hashlock, timelock) to finalize the lock on behalf of the user.

   If the user did not choose the signature flow (i.e., they will call addLock() on-chain themselves), the solver MUST NOT call addLockSig().

5. Complete the exchange

   • Once verified, call redeem() on both the source and destination chains.
   • Pass in the previously generated S value.

Edge Case: User Fails to Act on the Solver’s Lock

• If the commitment is not locked, wait for the timelock to expire.
• Call refund() on the destination chain to reclaim your funds.