# Risk management \[Exposure caps, emergency controls, and the on-chain audit trail]

:::info
In Railnet smart contracts, an Allocation Strategy is implemented as a **MultiVehicle** and an Advanced Strategy as a **Specialized Vehicle**.
:::

## Exposure caps

The [Vehicle Manager](/developers/contracts/multi-vehicle) stores a cap per authorized yield source, and the accounting engine checks it before every allocation. Allocation queues add a second layer: deposit targets are ceilings, so capital flows to the next source once a target is reached, and redeem targets are floors that keep a source from being drained. Both are enforced by the contracts, not by convention. See [Operate an Allocation Strategy](/strategies/allocation/operate) to configure them, and [Guardrails and mandates](/strategies/allocation/guardrails) for who is allowed to change them.

For Advanced Strategies the equivalent limits are spending allowances and calldata bounds in the [policy engine](/strategies/advanced/policy-engine), plus the vault's [NAV guardrails](/strategies/advanced/vault#nav-guardrails) and deposit cap.

## Emergency controls

**Pause** is a reversible halt. While a contract is paused, no deposits, redemptions or allocations execute. Use it during an incident or while investigating unexpected behaviour, then unpause.

**Freeze** is irreversible. Once a beacon is frozen, its implementation can never be upgraded again, which gives depositors and regulators a provable guarantee that the rules cannot change. The two are independent: a contract can be paused without being frozen and vice versa.

**Module timelocks** impose a waiting period between requesting a module change and activating it, so stakeholders can review it first.

Failures stay local. Each [STEAM](/developers/contracts/steam-standard) Query has its own state machine and ID; `RECOVERING` reclaims assets from a failed operation and `REJECTED` returns them to the sender, without touching other queries or other yield sources in the same strategy.

## Audit and compliance

* Every capital flow is an on-chain event with a block timestamp, and sector-based double-entry accounting keeps books an auditor can verify without your internal records
* Role grants and revocations are on-chain, so who was authorized to do what, and when, is reconstructable
* Fee accrual and distribution are on-chain and verifiable
* [AccountList](/conduits/compliance) supports allowlists, blocklists and sanctions oracles
* A Conduit's shares are mint-and-burn only until its owner flips the one-way `transferEnabled` latch; with transfers on, an AccountList in `STRICT` mode still restricts them to approved accounts

Positions, Query lifecycle, fee accrual and sector balances are all queryable through the [API](/developers/api).

## Next steps

<Cards>
  <Card title="Guardrails and mandates" description="What the owner keeps, what an asset manager gets." icon="shield" to="/strategies/allocation/guardrails" />

  <Card title="Policy engine" description="Calldata checks and spending limits." icon="shield-half" to="/strategies/advanced/policy-engine" />

  <Card title="Compliance" description="AccountList modes, precedence, and forced redemptions." icon="scale" to="/conduits/compliance" />
</Cards>