> ## Documentation Index
> Fetch the complete documentation index at: https://ducs.surchi.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Execution Safeguards: How SURCHI Protects Automated Trades
> The built-in safeguards that prevent the SURCHI Execution Sentinel from taking actions outside your defined risk parameters or authorization.
Automated execution is powerful — and that power demands proportionate safeguards. The SURCHI Execution Sentinel can act faster than any human trader, which means the boundaries you set for it must be ironclad. SURCHI's execution safeguard architecture ensures that the Sentinel can only ever operate within the exact parameters you define. No overrides, no exceptions, no "it was acting in your best interest" rationalizations. Your limits are the Sentinel's limits.
## User-Defined Risk Limits
Every action taken by the Execution Sentinel is bounded by risk parameters you configure. These limits are enforced at the smart contract level — the Sentinel is technically incapable of exceeding them, not just instructed not to.
Set both an **absolute maximum** (e.g., no single trade exceeds 500 USDC) and a **portfolio percentage cap** (e.g., no single trade exceeds 5% of total portfolio value). Both limits must be satisfied simultaneously.
Set a maximum total value of trades the Sentinel can execute within a 24-hour rolling window. Once the daily cap is reached, all execution halts until the window resets — regardless of signal strength.
Specify an explicit list of tokens the Sentinel is permitted to trade. The Sentinel cannot execute trades involving any asset not on your whitelist, even if it identifies a high-confidence signal on that asset.
Define the maximum acceptable price impact for any single trade. Trades that would exceed your slippage tolerance are automatically cancelled rather than executed at a worse-than-expected price.
Separate from slippage, price impact limits prevent the Sentinel from executing trades that would meaningfully move the market — protecting you from both bad fills and unintended market impact.
Optionally restrict Sentinel execution to specific hours or block ranges. This allows you to pause automated activity during high-volatility periods (e.g., major economic events) when you prefer manual oversight.
## Emergency Stop
If you ever need to immediately halt all Execution Sentinel activity — for any reason — you have three independent mechanisms to do so.
The SURCHI dashboard displays a prominent **Emergency Stop** button on the Execution Sentinel panel. Clicking it submits a pause transaction immediately. This is the fastest method for most users.
You can submit a pause transaction directly to the Sentinel smart contract — bypassing the SURCHI frontend entirely. This is available even if the SURCHI website is down, experiencing issues, or you have reason to distrust the frontend. Contract addresses and ABI are published in this documentation.
The Sentinel monitors its own behavior for anomalies. If execution patterns deviate significantly from your historical norms — unusual trade frequency, unexpected asset types, atypical size patterns — the circuit breaker automatically pauses execution and sends you an alert. You must manually re-authorize execution after a circuit breaker event.
If you suspect unauthorized activity on your account or in the Sentinel contract, **immediately activate the Emergency Stop** using whichever method is fastest, then contact **[security@surchi.io](mailto:security@surchi.io)**. Do not wait to gather evidence or confirm your suspicion — stop first, investigate second.
## Multi-Step Authorization
Not all Sentinel actions are created equal. Standard recurring execution within your established parameters runs on your initial authorization. But certain actions require you to explicitly re-authorize before they proceed:
* **High-value trades** — individual trades above a configurable "high-value" threshold require fresh authorization, even if they're within your maximum trade size limit
* **Novel strategy types** — if the Sentinel proposes executing a type of trade or strategy it has not previously used for your account, it must pause and request explicit approval before proceeding
* **New asset types** — even if an asset would qualify under your whitelist, adding a new asset class to active execution requires confirmation
* **Parameter changes** — any modification to your execution parameters requires wallet-signed confirmation before taking effect
This ensures that the Sentinel's expanding capabilities never silently expand what it does on your behalf.
## Audit Trail
Every action the Execution Sentinel takes on your behalf is permanently recorded on-chain. The audit trail includes:
| Field | Description |
| --------------------- | --------------------------------------------------- |
| **Transaction Hash** | Unique on-chain identifier for every execution |
| **Timestamp** | Block time of execution |
| **Action Type** | Trade, parameter update, pause, resume |
| **Assets Involved** | Input and output tokens |
| **Amounts** | Exact values in and out |
| **Execution Price** | Price at which the trade was filled |
| **Signal Reference** | Which Sentinel signal triggered the action |
| **Parameters Active** | Your risk limits in effect at time of execution |
| **Outcome** | Success, partial fill, rejection, or failure reason |
This record is publicly verifiable on Solana Explorer and cannot be altered or deleted. You can audit your complete Sentinel history at any time, share it with any third party, or use it for tax reporting purposes.
Start with conservative limits and gradually increase them as you become comfortable with the system. A Sentinel running with tight limits on a small allocation teaches you how it behaves at low stakes before you scale up. Most experienced users ran limited pilots for several weeks before expanding their Sentinel parameters.