Skip to main content
0x1 is built on the premise that a mirror trading platform should never need to hold assets, see raw private keys, or take actions that the user has not explicitly authorized. This page explains the architecture decisions that make that possible.

Non-custodial design

Funds stay on Aster

0x1 never holds, moves, or custodies user funds. All deposits, margin, PnL settlement, and withdrawals happen directly on the user’s Aster account. 0x1 has no ability to withdraw funds to an address the user has not authorized.

No omnibus accounts

There are no pooled accounts or omnibus wallets. Each follower’s capital stays in their own Aster account throughout the life of any mirror. What the engine does is place orders — it does not move funds.

Agent keys

The mirror engine needs to place orders on a follower’s Aster account in real time — faster than a human can approve each transaction manually. Agent keys solve this without giving the engine access to the user’s primary wallet.
An agent key is a delegated signing key, scoped to a specific set of operations on Aster: placing and closing orders within the bounds the user has configured. It cannot move funds, modify account settings, or take any action outside that scope.The user generates or imports the agent key once. After that, the engine uses it autonomously within the limits the user has set (allocation, leverage cap, slippage tolerance).
Agent keys are encrypted at rest using AES-256. The decryption key is never stored alongside the encrypted agent key in the same system. Keys are decrypted in memory only for the duration of a single signing operation — they are not held in plaintext in any persistent storage layer.
At any time, from the Security section of your 0x1 dashboard, you can:
  • Rotate — generate a new agent key and invalidate the old one. Any in-flight orders signed by the old key are not affected.
  • Revoke — invalidate the agent key entirely. After revocation, the engine cannot place new orders on your account until you provision a new key. Existing open positions remain open; you manage them manually or through Aster.
Because the agent key is scoped to order placement only, a compromised agent key cannot drain funds. The worst-case scenario is unauthorized order placement within the limits you have configured (allocation cap, leverage cap). Revoking the key immediately removes all further order-placement capability.

EIP-712 signing

All orders placed by the mirror engine are signed transactions using EIP-712 structured data signing. This provides two guarantees:

Human-readable intent

EIP-712 structures the data being signed so that a wallet UI can display exactly what is being authorized — asset, direction, size, and price bounds — rather than an opaque hex string.

Replay protection

Each signed message includes a domain separator and nonce. A signature for one specific order on one specific chain cannot be replayed as a different order or on a different chain.
The engine constructs and signs EIP-712 messages for every order it places. The signature is verified by Aster’s smart contracts on-chain before the order executes. 0x1 never submits unsigned or weakly-signed transactions.

Risk guards

The engine enforces limits on every order it places. These guards run in the hot path — between signal detection and order submission — so they cannot be bypassed by a fast-moving market.
The engine tracks how much of the user’s allocated margin is currently committed to open mirror positions. If placing a new order would exceed the allocation cap the user set, the order is sized down to the remaining headroom. If there is no headroom, the order is skipped.

What the engine never does

Agent keys are decrypted in memory for the duration of one signing operation, then cleared. No component of the system stores decrypted agent keys in a database, log file, or cache.
The agent key delegation scope is order placement only. The engine has no ability to initiate withdrawals, transfers, or any operation that moves funds between accounts.
Every order passes through all four risk guards before submission. There is no code path that bypasses a user’s allocation cap, leverage cap, slippage tolerance, or margin check.
The engine cannot change a user’s Aster account configuration, fee tier, or any setting. It can only place and close orders.
0x1 has been designed for non-custodial operation from the ground up. Security audit reports will be published in this section when available. If you find a security issue, report it via the contact information on the 0x1 website.