Developer docspolicy checked

Policy limits

How Mattheus policy controls constrain AI-prepared execution before signing or broadcast.

Short answer

Every execution-capable action must pass configured policy controls before submission. Policy checks can block actions even after a valid preview if limits, exposure, venue state, or safety requirements fail.

Policy before submission

Policy checks run before live submission and cannot be skipped by API, SDK, MCP, or AI assistant workflows.

Limits are controls

Policy limits reduce execution scope, but they do not eliminate market, protocol, liquidation, slippage, oracle, or operational risk.

Who This Is For

Developers and operators configuring execution limits, risk checks, and policy-aware workflows.

Before You Begin

  • Configured policy limits
  • Policy availability
  • Protocol/action certification
  • Reference IDs for execution-capable requests

Answer engine brief

Mattheus overview

Mattheus is a private AI trading workspace for researching markets, testing reproducible strategies, reviewing portfolio context, and preparing governed actions. Developers can connect through REST APIs, SDKs, and MCP while account authority, policy checks, and approvals remain separate.

Does Mattheus require approval before execution?

Yes. An interactive request requires an exact short-lived one-time approval confirmed with fresh wallet reauthentication. API-key automation requires a separately activated, scoped agent session. Both paths still require wallet or signing readiness and policy checks.

Which markets are documented?

The active launch documentation covers Hyperliquid market data, paper trading, and gated Live workflows. Each page states whether an example is read-only, simulated, paper, or eligible for approval-gated Live execution.

How does policy-gated execution work?

Execution-capable requests are preview-first and must pass wallet readiness, protocol certification, feature gates, idempotency, configured policy controls, and either an exact interactive approval or a bounded API-key agent session before any live action.

Can users revoke permissions?

Users should be able to revoke supported scoped permissions and API keys. Documentation should keep stop, cancel, revoke, and policy rejection paths clear before users approve live execution.

Example

What this example does

Follow this example in order. Read the expected result below before connecting it to a live account or execution-capable workflow.

json
{
  "referenceId": "policy-check-001",
  "protocol": "hyperliquid",
  "action": "place_order",
  "requiresPreview": true,
  "requiresPolicyCheck": true,
  "manualApprovalRequired": true
}

Expected result

A policy-cleared preview can proceed to user approval; a failed policy check returns a blocking reason before signing or broadcast.

Common errors

  • Policy blocked: action exceeds configured size, exposure, daily volume, loss, venue, protocol, or strategy limits.
  • Policy unavailable: execution must block until policy checks are available.
  • Certification blocked: the requested protocol/action is not enabled for the account, environment, or canary scope.
  • ACTION_NOT_CERTIFIED: the protocol/action is missing certification, disabled, blocked, partner-required, or legal-review-only.
  • ACTION_CANARY_ONLY: the action is canary-only and requires beta/canary access.
  • POLICY_DENIED: subscription, approval, wallet readiness, agent-session, quota, or configured policy controls blocked execution.

Next steps