Custody & Authority Notice
Effective August 30, 2026 | Version 2026-08-30
1. What non-custodial means here
Felix is designed so the owner private key is generated and retained on an owner-controlled client, such as the local MCP process and its operating-system key store. The plaintext owner private key and seed phrase are not sent to Felix servers. PredictEngine does not hold customer funds in an omnibus account and does not receive an unrestricted key that can choose an arbitrary withdrawal destination.
This boundary reduces a custody risk; it does not eliminate software, signing, contract, venue, bridge, owner-device, credential, or market risk. “Non-custodial” is not a promise that loss is impossible.
2. Owner key
The owner key is the root authority for the Felix account. It signs account onboarding, policy and limit grants, protected transfers, and withdrawals where required. The owner is responsible for backup, recovery, device security, and verifying every message or transaction before signing. Felix cannot recover a lost owner key or reverse a valid blockchain transaction.
3. Safe wallet and contracts
Felix accounts may use established Safe smart-account contracts for owner-controlled assets and transaction execution. Safe is third-party software with its own governance, deployments, audit history, and risks. Felix also uses a policy module and integration code to enforce narrower agent authority. That Felix-specific module and its configuration are separate from the Safe core contracts and do not inherit every assurance associated with a Safe audit.
4. Owner-signed mandate
Before live agent activity, the owner signs a mandate that identifies the account, approved authority, limits, and expiry. Account-level ceilings are immutable after creation. A key may be revoked and replaced with tighter or different limits inside those ceilings; increasing an account ceiling requires a new account and owner-controlled migration. An owner signature authorizes only the exact message presented, not unlimited future authority.
5. API and agent keys
API keys authenticate requests but are not the owner private key. Keys have explicit scopes such as read, trade, manage, or transfer and may carry live limits. A child account cannot read another user’s account. Trade-scoped agent keys are not permitted to choose arbitrary off-platform withdrawal destinations. A compromised API key can nevertheless cause loss within its valid scope and limits and must be revoked immediately.
6. Attested signing
For authorized unattended activity, Felix may use a signer in an AWS Nitro Enclave or equivalent attested environment. The signer evaluates an exact request against account ownership, key scope, owner mandate, allowlists, caps, freshness, nonces, current risk state, and other policy checks before signing. The host should not receive private signing material from the enclave. Attestation and policy checks are defense in depth; bugs, compromised dependencies, configuration errors, cloud failures, or signing defects remain possible.
7. What scoped authority may do
Subject to the current owner mandate and runtime controls, scoped authority may prepare or sign allowlisted wallet deployment, token approval, venue funding, routing, trading, position management, redemption, fee, and return-to-owner actions. Each venue has a different signing and settlement model. Felix may refuse an action if authoritative balance, ownership, risk, venue, or reconciliation state is unavailable.
8. Withdrawals and transfers
Protected withdrawals require transfer authority and an exact owner-controlled signing flow or owner-authorized policy. Destination, token, amount, nonce, chain, expiry, and calldata are validated before submission where applicable. An agent trade key alone cannot withdraw to an arbitrary address. A withdrawal may still fail or be delayed by a venue, blockchain, bridge, compliance requirement, or ambiguous transaction state.
9. Emergency controls
Felix may provide pause, panic, revocation, lockdown, anomaly, and circuit-breaker controls. Their exact effect is shown by the applicable response. They may stop new managed actions or revoke a key but may not close an existing position, revoke every token allowance, cancel a transaction already broadcast, reverse a fill, or recover a compromised owner key. Owners must separately inspect positions, balances, approvals, and venue state after an emergency action.
10. Where funds can exist
Funds may exist in an owner wallet, Safe, venue-specific wallet or account, bridge or relayer flow, settlement contract, or as open positions and claim tokens. A displayed aggregate may depend on multiple providers with different freshness. Felix reports unavailable or stale components instead of treating them as zero where designed to do so, but provider and reporting defects remain possible. Confirm material balances with venue and on-chain records.
11. User responsibilities
- protect and back up the owner key without disclosing it to Felix or support;
- use least-privilege API keys and low limits appropriate for the strategy;
- review owner-signing prompts, destination, chain, token, amount, caps, and expiry;
- monitor agents, positions, balances, allowances, venue status, and incident notices;
- pause and revoke suspected credentials promptly; and
- keep enough native gas where an owner-paid transaction may be required.
12. No guarantee or insurance
PredictEngine does not guarantee that the custody or signing architecture cannot be compromised and does not insure user funds against loss. The disclaimers and limitation of liability in the Terms of Serviceapply to the fullest extent permitted by law. Material technology and security risks are described in the Risk Disclosure.