Security overview
The Mattheus security boundary for AI-prepared execution, approvals, signing, policy checks, and protocol permissions.
Short answer
Mattheus separates AI preparation from signing and submission. Supported execution requires preview, policy checks, approved-address validation, manual approval, signing after approval, and append-only receipt or order tracking.
Risk remains
Manual approval and policy controls do not remove smart contract, market, oracle, liquidation, bridge, wallet, operational, or user decision risk.
Clear boundary
The AI prepares executable actions. Signing and broadcast happen only after approval and required checks.
Who This Is For
Security reviewers, integrators, and operators assessing the execution and signing boundary.
Before You Begin
- A supported action
- Signing method readiness
- Approved contract or address checks
- Receipt or fill tracking
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.
Plain-language walkthrough
- 1
AI layer
researches, drafts, composes, previews, and explains actions.
- 2
Policy layer
checks configured limits and blocks unsafe or out-of-scope requests.
- 3
Approval layer
records explicit user approval for the exact preview.
- 4
Signing layer
signs only after approval and required checks.
- 5
Execution layer
broadcasts or submits and records receipts, fills, or order status.
Expected result
Common errors
- Signer not ready: wallet or signing infrastructure is missing or not approved for the action.
- Address not approved: target contract or address is outside the allowlist.
- Receipt tracking missing: execution must block if the system cannot record the submitted action.
- Preview rejected: balances, allowance, liquidity, route, simulation, policy, or approved-address checks did not pass.
- Approval required: an interactive request has no approved, unexpired, exact one-time approval artifact, or an API-key request has no active scoped agent session.