# History

History is a complete log of every market-making campaign you have launched on the platform  across Price Boost, Price Drop and Smart Buy/Sell. Use it to review past performance, audit on-chain activity, replicate successful configurations, or investigate failed runs.

***

### Campaign Type Filters

At the top of the page you can switch between campaign types using the tabs. Each tab displays only campaigns of the selected type.

| Tab                | Description                                                                         |
| ------------------ | ----------------------------------------------------------------------------------- |
| **Price Boost**    | Campaigns aimed at pushing the token price upward through coordinated buy pressure. |
| **Price Drop**     | Campaigns designed to lower the token price through controlled sell pressure.       |
| **Smart Buy/Sell** | Limit-order campaigns combining buy and sell orders for flexible market-making.     |

<figure><img src="/files/OJWviaKx8pwIOD1hMrUz" alt=""><figcaption></figcaption></figure>

> **Tip:** Use the tabs to compare how different strategies performed for the same token over time.

***

### Campaign List

Each row in the list represents one campaign. Click a row to expand its detail view.

| Column      | Description                                                                   |
| ----------- | ----------------------------------------------------------------------------- |
| **Date**    | Campaign start date and time in `DD.MM.YY HH:MM` format. Sorted newest first. |
| **Status**  | Current state of the campaign. See Status Types below.                        |
| **Token**   | Name and ticker of the token used in the campaign.                            |
| **Budget**  | Total amount of SOL allocated to or spent during the campaign.                |
| **MKT CAP** | Goal market capitalization                                                    |

***

Pagination controls below the list let you navigate between pages of historical campaigns.

#### Status Types

| Status               | Description                                                 |
| -------------------- | ----------------------------------------------------------- |
| **Active**           | Campaign is currently running                               |
| **Target Completed** | Target price or growth goal achieved                        |
| **Budget Used**      | Campaign stopped after the allocated budget was fully spent |
| **Stopped**          | Campaign manually stopped by user                           |
| **Failed**           | Campaign stopped due to an error or failed execution        |

### Campaign Details

Click any campaign in the list to open its detail view. It shows the full configuration used at launch alongside every on-chain transaction the campaign produced.

#### Header

The header displays the campaign's identifying information:

* **Token name and ticker** — e.g., `Wolfun (WOLFUN)`
* **Campaign type badge** — `Price Boost`, `Price Drop`, or `Smart Buy/Sell`
* **Budget** — spent vs. total budget (e.g., `0.16 / 0.07286 SOL`)
* **Target MKT CAP** — target market cap configured at launch
* **Status** — current campaign status
* **Start Date** — when the campaign was launched
* **Hide details / Show details** — collapse or expand the configuration block

#### Configuration Parameters

The detail view exposes every setting used at launch. This is useful for replicating successful runs or auditing what went wrong.<br>

| Parameter                   | Description                                                               |
| --------------------------- | ------------------------------------------------------------------------- |
| **DEX**                     | Decentralized exchange used for trade execution (e.g., Raydium, PumpFun). |
| **Validator**               | Solana RPC node that broadcasted transactions during the campaign.        |
| **Wallet pool**             | Identifier of the wallet pool used to execute trades.                     |
| **Slippage**                | Maximum acceptable price deviation per transaction.                       |
| **Priority fee**            | Validator tip applied to push transactions to the front of the queue.     |
| **Min time between trans.** | Minimum delay (in seconds) between consecutive transactions.              |
| **Max time between trans.** | Maximum delay (in seconds) between consecutive transactions.              |
| **Min trans. budget range** | Smallest single transaction size in SOL.                                  |
| **Max trans. budget range** | Largest single transaction size in SOL.                                   |
| **Target**                  | Configured target percentage growth (Price Boost) or drop (Price Drop).   |

> **Tip:** If a campaign performed well, use these parameters as a reference when configuring a new one of the same type.

***

### Transactions

Below the configuration block, every on-chain transaction produced by the campaign is listed individually.

| Column     | Description                                                                   |
| ---------- | ----------------------------------------------------------------------------- |
| **Time**   | Timestamp of the on-chain transaction.                                        |
| **Status** | Result of the transaction — `Success` or `Failed`.                            |
| **Hash**   | Transaction signature on the Solana blockchain. Click to open in an explorer. |
| **From**   | Sender wallet address — typically a wallet from your selected pool.           |
| **To**     | Recipient wallet address — typically the DEX program or liquidity pool.       |
| **Amount** | SOL amount transferred in the transaction.                                    |

A copy icon next to each hash and address lets you copy the full value to your clipboard.

> **Note:** Use the Hash links to verify trades directly on Solscan or Solana Explorer.

***

### Best Practices

1. **Audit before relaunching.** Open a campaign's detail view to verify slippage, validator tip, and time intervals before copying the setup into a new campaign.
2. **Reference Budget Used campaigns.** Campaigns that ran to completion (`Budget Used`) usually represent the most fully-tuned setups and are the best reference for replication.
3. **Investigate Stopped campaigns.** A `Stopped` status indicates manual intervention. Review the transactions to confirm whether the goal was reached early or the campaign was aborted.
4. **Diagnose Failed campaigns.** If a campaign is marked `Failed`, check the failed transactions in the detail view — most issues stem from insufficient SOL balance, incorrect DEX selection, or validator congestion.
5. **Compare strategies side by side.** Switch between Price Boost, Price Drop, and Smart Buy/Sell tabs to evaluate how each strategy performed for the same token.
6. **Verify on-chain.** Use the Hash links in the transactions table to cross-check trades on Solscan or Solana Explorer.

***

### FAQ

**Q: Can I delete or edit a campaign from History?** No. History is read-only. Campaigns and their transaction records are permanent and cannot be modified or removed.

**Q: Can I rerun a past campaign directly from History?** Not directly. To rerun a campaign, copy its configuration parameters into a new campaign through the relevant module (Price Boost, Price Drop, or Smart Buy/Sell).

**Q: How long is campaign history retained?** All campaign history is retained indefinitely. You can review campaigns from any point in your account's lifetime.

**Q: What's the difference between `Stopped` and `Failed`?** `Stopped` means the campaign was manually halted by you. `Failed` means the campaign stopped automatically due to an execution error — for example, insufficient balance or repeated transaction failures.

**Q: Can I export campaign history?** Direct export is not currently available in the UI. For audit purposes, you can capture transaction hashes and review them on Solscan or Solana Explorer.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://tsunammi.gitbook.io/tsunammi/market-making/history.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
