Accounts and custody

AccountCore is the canonical identity, authorization, custody, fee-policy, and product-routing boundary. Orderbooks and Engines hold accounting state, but no market contract independently holds user tokens.

Account identity

• Every registered address receives a nonzero uint40 account ID. Events and market storage use this ID instead of repeating addresses.
• Registration is lazy. A user's first deposit, direct signer authorization, or first interaction through a verified Spot orderbook may register the address.
• userRegistry(address) resolves address to ID; userAddressById(id) resolves ID to address.
• A root account owns itself. A subaccount has its own address, balance, signer set, and ID, but records the root ID and root owner.
• Creating a subaccount requires a deadline-bound EIP-712 consent signature from the proposed subaccount address. EOAs and ERC-1271 wallets are supported through the signature checker.

Delegated permissions

Permission	Capability
TRADE	Place, replace, cancel, swap, and manage passive liquidity; initiate perpetual trading actions
INTERNAL_TRANSFER	Move free balances within the same root tree, subject to sibling rules
WITHDRAW	Withdraw an account's free balance to the calling address
ADMIN	Authorize or revoke delegated signers

The account address and recorded owner are implicitly authorized for every permission. Delegated permissions may expire; expiry 0 means no expiry.

There is intentionally one TRADE permission for the complete order lifecycle, not a separate cancel-only signer. A subaccount or its local transfer signer can move value from that subaccount to its root. Moving value from the root into a subaccount requires authority over the root as the source; moving between sibling subaccounts likewise requires root-level authority.

Every signer authorization or revocation increments accountSignerAuthorizationNonces(account). Periphery contracts can bind standing intents to this epoch so revoke-and-reauthorize does not revive an old authorization.

Custody flows

Deposits and withdrawals

• deposit and depositForAccount accept configured ERC20 assets or native MON (address(0)).
• A third party may fund another account but gains no authority over it.
• ERC20 deposits transfer tokens into AccountCore; native deposits require exact msg.value.
• Withdrawals can use only free balance. Reserved Spot balance and allocated perpetual margin are not withdrawable through the free-balance path.
• withdrawFromAccount transfers to msg.sender, so WITHDRAW is an asset-transfer permission and must be granted conservatively.

Token configuration

Governance enables assets in AccountCore. ERC20 decimals are read from token metadata and cached; native MON uses 18. Decimals cannot silently change across disable/re-enable cycles. A token backing a registered PerpEngine cannot be disabled while that route exists.

Spot routing also requires the token to be whitelisted by SpotRouter. AccountCore enablement gates new deposits, internal free-balance transfers, and new market registration; disabling a token does not block existing withdrawals, reserve mutation, or settlement by an already verified Spot orderbook, and it does not revoke that book. Router whitelisting separately governs eligibility for future Spot deployment.

Distinct balance claims

For a given account and token, value may be:

1. free in AccountCore;
2. reserved for active Spot orders;
3. locked into a Spot passive-liquidity position whose inventory is tracked by the orderbook;
4. allocated to a quote-specific PerpEngine cross namespace; or
5. allocated to one isolated perpetual market namespace.

Moving value between these states reclassifies a claim atomically. The same token unit must never support two claims. Tokens allocated to an Engine remain physically in AccountCore, but are removed from the free ledger and cannot be withdrawn or reused for Spot.

Product adapters

IAccountCore is the product-neutral user surface. Product-specific mutation is split into narrow adapters:

• ISpotBalanceAccount registers verified Spot books, reserves/releases balances, settles active fills, and locks/releases passive liquidity.
• IPerpBalanceAccount routes margin, verified orderbook actions, risk updates, price/funding updates, and liquidation calls to the correct PerpEngine.

Only a router-registered orderbook may invoke its settlement adapter. A normal user cannot directly impersonate a market.

Fees and builders

Protocol fees and builder execution fees are separate:

• Spot starts from the market fee cap and applies active root-account/default/referral policy.
• Perpetuals use one global base maker/taker pair, then apply active root-account and referral discounts.
• Maker fees are snapshotted when an order rests. For Spot, the effective taker fee and builder approval/cap are validated before matching and passed into settlement; Perp resolves them in the AccountCore settlement action.
• A root account approves a builder, maximum PPS fee, and optional expiry. Subaccounts inherit that approval.
• Builder fees accrue per asset in AccountCore and are transferred only when the builder claims them.
• Builder referral tiers are fee discounts, not permission to charge a builder execution fee.

Rounding is product and path specific. Current Spot maker reserve and maker/taker/builder fee amounts use integer-floor division. Perp maker reserve, taker/builder fees, and liquidation action fees round up. A configured zero fee is valid.

Pause behavior

The AccountCore protocol pause blocks deposits, withdrawals, internal transfers, new reserve increases, Spot settlement, passive locks, margin movement, every ordinary Perp fill, and every Perp order increase—including reduce-only fills/orders. Spot reserve releases, passive exits, cancellation-only Perp accounting, manual Perp funding settlement, and liquidation entrypoints remain available. Release/exit paths reclassify claims to free balance, but external withdrawal remains blocked until AccountCore is unpaused.

Orderbook market state is a second, product-local gate. Operators must reason about both the AccountCore pause and each orderbook's state.