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

# Set your rules

> How risk band, protocol whitelist, and chain whitelist work, and how to change them.

> Compass operates inside three rules attached to your smart account: a risk band, a protocol whitelist, and a chain whitelist. All three are stored on-chain and checked before any route executes. The agent has no authority to widen them — only your owner key can.

This page covers what each rule does, how to set it, and when changes take
effect.

## The three rules

| Rule                   | What it bounds                               | Set by |
| :--------------------- | :------------------------------------------- | :----- |
| **Risk band**          | The highest-risk venue the agent may use     | Owner  |
| **Protocol whitelist** | The set of protocols the agent may call      | Owner  |
| **Chain whitelist**    | The set of chains the agent may move USDC to | Owner  |

Every plan the chat agent generates is checked against all three before
execution. A plan that fails any check is rejected and never broadcast.

## Risk band (1–10)

A single integer from `1` (most conservative) to `10` (most aggressive). Each
supported protocol is assigned a risk score; the agent may only route to
protocols **at or below** your band.

The mapping from band to protocols is published in
[Supported chains & protocols](/overview/supported-chains-protocols#risk-band-mapping).
This page is the source of truth — Compass does not list APR estimates in
docs because real yields move daily and testnet yields are not meaningful.

<Info>
  Risk scores are assigned manually as part of venue review. New protocols
  cannot be added by the agent and cannot self-assign their score. See
  [Authority & upgrade model](/contracts/authority-upgrade-model).
</Info>

## Protocol whitelist

A list of protocols the agent is allowed to call. The list is a strict
subset of [Supported chains & protocols](/overview/supported-chains-protocols).

* The agent can route to any **whitelisted** protocol that also satisfies your
  risk band.
* The agent **cannot** route to a non-whitelisted protocol, even if you ask
  it to in chat — the policy check runs after the LLM generates the plan.
* You can whitelist a protocol on one chain and not on another. The whitelist
  is per (protocol, chain) pair.

## Chain whitelist

A list of chains the agent may move USDC to via Circle Gateway. Same model as
the protocol whitelist:

* Arc Testnet is always whitelisted — it's your home chain.
* Adding a chain to the whitelist does **not** automatically whitelist
  protocols on it. You whitelist each (protocol, chain) pair explicitly.

## Per-route and daily caps

In addition to the three whitelists, your policy includes spending limits:

* **Per-route cap** — the maximum USDC amount a single route can move.
* **Daily cap** — the maximum USDC amount the agent can move across all
  routes in a 24-hour window.

Both caps default to conservative values on a new account. You can raise or
lower them in the same UI as the whitelists.

## How to set or change your rules

1. Open the app and click **Rules** in the sidebar.
2. Adjust the risk slider, toggle protocols and chains, set caps.
3. Click **Save rules**.
4. Your owner wallet will prompt for **one signature** to commit the new
   policy on-chain.

Once the transaction confirms (sub-second on Arc), the new rules are
**immediately active**. The agent re-evaluates any in-flight plan against the
new policy before the next tick.

<Info>
  Rule changes are owner-only. The agent's session key has no permission to
  modify any of the rules above. See [Session keys](/contracts/session-keys).
</Info>

## What happens if a rule is broken

Rules are checked at the contract level on every route. If the agent ever
attempts a call that violates your policy:

* The call **reverts** before USDC moves.
* The attempt is logged to the audit trail with the failed check.
* The agent does **not** retry the same plan — it generates a new one or
  pauses.

The agent cannot "exceed" your rules. The worst-case outcome is that it
proposes a plan you reject, or it pauses because no valid plan exists inside
your current rules.

## Tightening rules during a route

You can change rules at any time, including while the agent has an open
position:

* **Tightening the whitelist or lowering risk band** — existing positions
  stay where they are, but the agent will not open new positions in venues
  that no longer satisfy the rules. You can `Withdraw All` to exit existing
  positions manually.
* **Loosening rules** — the agent immediately becomes eligible to route to
  newly whitelisted venues on its next tick.

## Next steps

<CardGroup cols={2}>
  <Card title="Supported chains & protocols" icon="list" href="/overview/supported-chains-protocols">
    The full list of what you can whitelist today.
  </Card>

  <Card title="Policy engine" icon="shield-check" href="/architecture/policy-engine">
    How rules are encoded and enforced on every tick.
  </Card>

  <Card title="Session keys" icon="key" href="/contracts/session-keys">
    The on-chain layer that makes "agent can't break rules" true.
  </Card>

  <Card title="Audit trail" icon="scroll" href="/architecture/audit-trail">
    Every rule check, pass or fail, logged.
  </Card>
</CardGroup>