> For the complete documentation index, see [llms.txt](https://moni-ai.gitbook.io/moni/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://moni-ai.gitbook.io/moni/fees/solana-network-fees.md).

# Solana Network Fees

Trading on Solana involves several parameters that affect execution speed, transaction success, and final price. Some fees are obvious, some are optional, and some are chosen to improve the chance your transaction lands successfully during congestion.

## Glossary

<table><thead><tr><th align="center" valign="top">Word</th><th>Definition</th></tr></thead><tbody><tr><td align="center" valign="top"><strong>Slippage</strong></td><td>The maximum price movement you allow between the moment you submit a trade and the moment it executes.</td></tr><tr><td align="center" valign="top"><strong>Priority Fee</strong></td><td>An additional fee you optionally pay to increase the chance your transaction is processed faster.</td></tr><tr><td align="center" valign="top"><strong>Bribery</strong></td><td>An optional extra incentive used by some execution routes to improve inclusion during competition. In practice it behaves like an extra tip used by certain infrastructure providers.</td></tr><tr><td align="center" valign="top"><strong>Base Network Fee</strong></td><td>The normal transaction fee required to submit any transaction.</td></tr></tbody></table>

{% hint style="info" %}
Base network fee is usually small. Slippage affects your execution price. Priority fees and bribery affect speed and inclusion probability.
{% endhint %}

## How it works?

{% hint style="success" %}
The Moni Discover Extension does not charge any additional fees for priority fees or bribery. These costs are paid directly to the Solana network and its validators as part of transaction execution. Moni does not collect, redirect, or profit from these fees in any way.
{% endhint %}

### Slippage

Slippage is not a fee that is taken from you as a line item. It is a trading protection setting. It defines how much worse your execution is allowed to be compared to the price you saw when you clicked buy or sell.

When you place a trade, the price can change before your transaction executes. This happens because:

* price moves naturally while your transaction is pending
* your own trade can move the price if liquidity is low
* other trades hit the pool before you
* the token is volatile or being actively traded
* the market is congested and confirmation takes longer

{% hint style="info" %}
Slippage is expressed as a percentage. If slippage is set too low, the transaction can fail. If it is set too high, the transaction can still succeed, but you risk getting a noticeably worse price than expected.
{% endhint %}

#### Example

Imagine you are buying a token and the current quote says:

* You spend 100 $USDC -> you receive 1,000 $TOKEN

This implies a price of 0.10 USDC per $TOKEN. If you set slippage to 1 percent, you are telling the system:

> **I am willing to accept an execution price that is up to 1 percent worse than the quote.**

So the worst acceptable outcome might be approximately:

* You spend 100 $USDC -> you receive 990 $TOKEN.

Because receiving 990 instead of 1,000 is about 1 percent worse.

{% hint style="info" %}
If, during confirmation, the market moves and the best execution becomes 985 TOKEN, the trade will likely fail because it breaks your tolerance.&#x20;

If you set slippage to 5 percent, the trade could still succeed at 985 TOKEN. You accepted that risk.
{% endhint %}

#### **Why trades fail with low slippage?**

A failed trade with low slippage usually means price moved beyond your tolerance. You did not lose the traded amount, but you may still pay a small network fee, and you lose time.

Common situations where low slippage fails:

* low liquidity tokens
* fast pumps or dumps
* new launches (huge moves on the chart)
* heavy network congestion
* large order size relative to pool size

{% hint style="info" %}
Higher fees can sometimes fix a low-slippage failure. A higher priority fee gets your trade confirmed faster, so the price has less time to move past your slippage limit. With a lower fee, confirmation is slower — the price can drift out of range and the trade fails, leaving you to either raise slippage or raise the fee and retry.
{% endhint %}

### Priority Fees

Priority fees are optional and are used to make your transaction more attractive to validators during periods of high activity. Paying a higher priority fee does not guarantee instant execution, but it significantly improves the chances of your transaction being processed sooner.

In practice, most active traders already include priority fees by default. When you exclude them, your transaction is often placed at the very end of the processing queue. This can leave you in a vulnerable position, especially during volatile market conditions, as your transaction waits longer (sometimes it can be too long) and becomes more exposed to price movement.

#### Why you might use priority fees:

* network congestion and slow confirmations
* competitive token trades where execution speed matters
* reducing the risk of being delayed behind other transactions

#### Why you might keep them low:

* normal market conditions with low congestion
* small trades where speed is not critical

{% hint style="info" %}
When transactions are slow, increasing the priority fee is often safer than increasing slippage. It shortens confirmation time and reduces the window in which price can move against you.
{% endhint %}

### Bribery

Bribery is an additional execution incentive used by some routing and inclusion systems. It is optional and not required for every trade. When present, it works as an extra signal to improve transaction inclusion during highly competitive conditions.

In practice, many traders have become accustomed to setting bribery values higher than necessary, because in certain situations it can be difficult to get a transaction included without it. At the same time, it is important to understand that bribery is less critical than the priority fee.

If overall execution importance is rated as 10, priority fee accounts for roughly 6.5, while bribery accounts for about 3.5. Bribery is an important component and should not be ignored, but it should also not be overvalued at the expense of priority fees.

#### When bribery can help:

* highly contested launches
* moments when many users submit transactions simultaneously
* cases where priority fees alone are not sufficient for timely inclusion

#### When bribery is unnecessary:

* normal market conditions
* liquid markets with low execution competition

### Putting it together

#### If your transaction fails, the likely causes are:

* slippage too low for current volatility
* confirmation too slow causing price to move out of range
* low priority fee during congestion

#### If your transaction succeeds but the price is worse than expected, the likely causes are:

* slippage too high for the token liquidity and volatility
* large order size relative to pool depth
* fast moving market while pending

#### A solid workflow is:

* keep slippage low for liquid tokens
* increase priority fee when speed matters
* increase slippage only when necessary, and understand the risk
* avoid extremely high slippage in illiquid tokens unless you accept worst case outcomes


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://moni-ai.gitbook.io/moni/fees/solana-network-fees.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
