> ## Documentation Index
> Fetch the complete documentation index at: https://docs.limitless.exchange/llms.txt
> Use this file to discover all available pages before exploring further.
# Building Responsible Trading Agents
> What an automated trader may and may not do on Limitless, which safeguards the exchange enforces, which ones your agent must enforce itself, and how to report suspected abuse
An agent that trades on Limitless is bound by the same rules as a person trading in the app. This page is the developer-facing summary of those rules: the conduct the [Terms of Service](/user-guide/terms-of-service#6-prohibited-activities) prohibit, the safeguards the exchange enforces on every order, the safeguards your agent has to enforce on its own, and where to report something that looks wrong.
It applies to every automated path: the [MCP server](/developers/mcp-server), bots built on the SDKs or [agents-starter](/developers/build-a-trading-agent), and partner integrations placing orders for their own users through the [Programmatic API](/developers/programmatic-api). The Terms govern; this page does not replace them.
## Prohibited conduct
The Terms prohibit any activity intended to artificially influence market prices or outcomes. The list below is what that means for an agent. It is not exhaustive, and Limitless may monitor all platform activity and suspend accounts, restrict addresses, or share information with authorities without prior notice.
| Prohibited | What it looks like in an agent |
| ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| **Wash trading** | Trading between accounts you control, or routing volume through your own accounts to inflate volume, earn rewards, or print a last-trade price. |
| **Spoofing and layering** | Resting size you intend to cancel before it fills, so the book shows supply or demand that is not real. |
| **Coordinated trading** | Arranging fills, quotes, or timing with other accounts to move a price or split a reward. |
| **Multiple accounts to evade restrictions** | Creating another account or wallet to get around a block, a rewards exclusion, or a limit. |
| **Exploiting vulnerabilities** | Using a bug in the exchange, a contract, or a reward program for gain instead of reporting it. |
| **Fraud or illegal use** | False information, money laundering, or any use that is illegal where you operate. |
Market making is not on this list. Quoting both sides, cancelling and replacing quotes as fair value moves, and pulling quotes when inventory or risk limits trip are normal. The line is intent: every order your agent rests must be one it is willing to have filled.
## What the exchange enforces
These controls run on every order, whether it comes from the app, an SDK, or an assistant. They are what your agent can rely on.
| Safeguard | What it does | Conduct it addresses |
| ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| **Self-trade prevention** | `POST /orders` never matches an incoming order against the same profile's resting order on the same token. The default `cancel_maker` policy cancels your resting order and continues; `cancel_taker` rejects the incoming order with `execution.reason: "STP_TAKER_REJECTED"`; `cancel_both` does both. See [Create Order](/api-reference/trading/create-order#self-trade-prevention). | Accidental self-trades from one profile. It does not span profiles. |
| **Public book only** | The signed order's `taker` must be the zero address. Orders cannot be directed at a chosen counterparty. | Pre-arranged fills. |
| **Scoped API tokens** | Self-service tokens carry `trading` by default. `withdrawal` is a separate, partner-only scope. Revoking a token takes effect immediately. See [Authentication](/developers/authentication). | Limits what a leaked or runaway credential can do. |
| **Human approval on the MCP server** | Every new order is a proposal that the account owner approves in the browser. Cancels execute directly. No withdraw or transfer tool exists. See [MCP Server](/developers/mcp-server). | An assistant cannot add exposure on its own. |
| **Address blocklist at order submission** | A blocked trade-wallet address is rejected on every exchange with `TRADER_BLOCKED: address is currently blocked from order submission. Contact support.` | Enforcement outcome for Terms violations and for wallets that break settlement. |
| **Action attribution** | Every order create and cancel is recorded with the acting profile, the authentication method, and the request id. When a partner acts for a sub-account, the partner's own profile is recorded as the actor. | Every order is traceable to who submitted it and how. |
| **Maintenance mode** | Trading can be restricted to `post_only`, `cancel_only`, or `disabled`. Blocked actions return `425 Too Early`. See [Maintenance Mode](/developers/maintenance-mode). | Orderly halts during incidents. |
| **Rate limits** | Enforced at the API edge with `429 Too Many Requests`. See [Rate limits](/api-reference/introduction#rate-limits). | Runaway loops. |
**Cancel through the API, never on-chain.** Legitimate cancels go through `POST /orders/cancel` and the related endpoints. An on-chain `OrderCancelled` for a CLOB order is treated as a settlement-integrity signal, and the maker address can be blocked from order submission as a result.
### What the exchange does not do for you
Design your agent around these gaps rather than assuming they are covered.
* **No per-account exposure or position caps.** The only ceiling on an order is your collateral.
* **No account-wide cancel-all.** [`DELETE /orders/all/{slug}`](/api-reference/trading/cancel-all) cancels one market or one group. A full flatten loops over markets.
* **Self-trade prevention is per profile.** Two profiles you control can match each other. That is wash trading, not an STP gap.
* **Attribution is not your audit log.** The exchange records who acted, not why. Your decision log is yours to keep.
## What your agent must enforce
Each production safeguard below maps to a prohibited behavior or to a failure mode that turns into one. [Agents Academy](https://academy.limitless.exchange/academies/agents_academy/) Module 14 walks through the runtime code for all of them; the cross-market strategy in agents-starter ships them configured.
### Provenance logging
Send a `clientOrderId` on every order. It is your idempotency key, up to 128 characters, unique per profile, and it is the identifier you will use in a report or a support thread. Send an `x-request-id` header too; it is stored with the action record. Keep a local log that links each `clientOrderId` to the strategy, the signal, and the outcome, so that "why did my agent do this" has an answer.
### Spending limits
Enforce hard limits in code, before the SDK call, not in the prompt: a per-order cap, a daily notional budget, a maximum open-position count, and per-market exposure. The cross-market strategy in agents-starter adds a `max_loss_usd` circuit breaker that cancels all orders and halts, and a `max_net_shares` inventory guard that stops quoting while hedges catch up. Run with `DRY_RUN=true` until the limits have tripped in a log and you have read what they said.
### Anti-self-trading
If several strategies share one profile, set `stpPolicy` explicitly. `cancel_taker` protects resting quotes from your own taker orders; the default `cancel_maker` protects the taker at the cost of the quote. If you run several profiles, self-trade prevention does not apply between them, and your agent must never route an order that could fill against another account you control. Self-trades also earn no maker rebate, so there is nothing to gain.
### Manipulation checks
Before resting an order, the agent should be able to answer yes to "would I accept this fill". Cancel-replace to track fair value is fine; resting size to change what the book shows is not. Do not treat reward programs as a reason to trade against yourself or to coordinate with another account. Do not create a second account or wallet to get around a block, a rewards exclusion, or a limit.
### Kill switches
Wire a stop that works in seconds without touching the LLM: a file flag or panel button the loop checks at the top of every iteration. When it trips, cancel resting orders first, per market, with [`DELETE /orders/all/{slug}`](/api-reference/trading/cancel-all). Halting the loop does not cancel orders already on the book. If the credential itself is suspect, revoke the token with [`DELETE /api-token/{tokenId}`](/api-reference/api-tokens/revoke-token), or revoke the MCP grant from Limitless; both invalidate access immediately.
## Reporting suspected abuse
Report market manipulation, a suspected exploit, or an agent that is misbehaving to **[help@limitless.network](mailto:help@limitless.network)** with the subject line **Market integrity report**. Include:
* the market slug or group slug
* order ids, `clientOrderId` values, or transaction hashes
* UTC timestamps
* the wallet addresses involved
* what you observed and why it looks wrong
Reports are handled under the Terms of Service. Detection methods, thresholds, and the outcome of individual reports are not published. For integration questions rather than reports, use the [Builders Chat](https://t.me/LimitlessBuildersChat).
## Related
The prohibited-activities section this page summarizes.
`stpPolicy` values and the response fields they produce.
Hard limits, budgets, and the file-flag kill switch, in TypeScript and Python.
The agents-starter template with dry run and circuit breakers built in.