TRAIN Protocol Documentation

Core Mechanism

The Reward-Slashing Mechanism incentivizes proper Solver behavior. The process begins when a Solver locks funds for a user. At this point, they must also lock an additional reward amount secured by a timelock. This reward serves as an incentive - if the Solver successfully transfers the user’s assets before the timelock expires, they receive their reward back. However, if they fail to act within the specified timeframe, the reward transfers to whoever executes the function to release the user’s assets.

Implementation Details

When a Solver locks funds for a user, the solverLock function escrows an additional reward amount along with a rewardTimelock parameter. This timelock must be set to a future timestamp and cannot exceed the timelock duration of the associated lock. The reward details are recorded in the SolverLocked event and stored inside the solver’s lock itself — solver locks are keyed by (hashlock, solver address), so anyone can read the reward for a given swap by calling getSolverLock(hashlock, solver).

The rewardTimelock must always be set to a future timestamp and cannot exceed the HTLC timelock duration.

Redemption Process

The redeemSolver function routes the reward differently based on timing. The logic is illustrated below using pseudocode:

transfer(funds, recipient);
if (!rewardTimelock.expired) {
    transfer(reward, rewardRecipient);  // the Solver acted in time
} else {
    transfer(reward, msg.sender);       // bounty for whoever redeems
}

Security Considerations

The rewardTimelock serves as a crucial protection against MEV attacks. It provides Solvers adequate time to assess whether they can execute the redeemSolver function within the specified timeframe. Even if Solvers miss their initial window, they can still call the function later to retrieve their reward, provided no one else has already executed it.