Atomic pool
Explains the mechanics of the Atomic Stake pool and how Solvers get punished for misconduct
In the Atomic Stake pool, Solvers voluntarily stake a small portion of their funds as a guarantee to ensure they release the user’s funds. If they fail to do so, they are penalized by having their staked funds, or a portion thereof, slashed. Solvers with locked amounts in the atomic pool will be more favorable to users during the Solver selection process. It’s important to emphasize that even if the Solver fails to release the user’s funds, those funds are still recoverable by the user through a manual claim, preserving the atomic nature of the process.
This outlines the standard PreHTLC flow in the scenario where the Solver releases their funds but fails to release the user’s funds in the destination network:
User Commit
The user creates a commit object on the source network.
Solver Lock
The Solver creates a lock object with the hashlock on the destination chain.
User AddLock
The user observes the transaction on the destination chain, retrieves the Hashlock, and converts their PreHTLC to an HTLC on the source chain.
Solver Unlock
The Solver releases their funds in the source network but does not take action on the destination network.
Slash
The user retrieves the secret from the unlock transaction on the source network and then accesses the Atomic Stake Pool to call the slash function, providing the hashlock and the secret. If half of the time has passed from the Solver’s lock timelock, this action slashes the Solver’s locked funds as a penalty for their misconduct.
Unlock
The user then reveals the secret in the destination contract to release their own funds.
The only scenario where the destination chain lock remains unreleased but the secret becomes public occurs when the Solver claims their funds on the source network before releasing the user’s funds. If the destination chain lock is still active and someone provides the secret to unlock it, this serves as proof of the Solver’s misconduct.
The slash function should also verify that the lock’s timelock is at least halfway expired to prevent MEV attacks, such as extracting the secret from the mem-pool and unfairly punishing the Solver.