> ## Documentation Index
> Fetch the complete documentation index at: https://docs.train.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Reward-Slash

> Explains how the system penalizes Solver misbehavior and rewards others for acting to release user funds.

<Warning>
  While users can always manually claim their funds, this protocol aims to prevent delays and inconvenience through economic incentives.
</Warning>

Solvers can exhibit unpredictable behavior that leads to various edge cases, such as refusing to release user funds. While users always retain the ability to manually claim their funds, preventing any permanent loss, this situation creates significant inconvenience.

## 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)**.

<Warning>
  The `rewardTimelock` must always be set to a future timestamp and cannot exceed the HTLC timelock duration.
</Warning>

## Redemption Process

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

```solidity theme={null}
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.