Skip to main content
The Stock Orderbook suite consists of a single deployable contract (StockCustody) with external dependencies on StockToken, USDC, a LiquidationRouter, and optionally a lending market. This page covers the contract’s architecture, state layout, and complete function reference.

Architecture

StockCustody maintains an internal ledger of user balances using a keccak256(user, token) key scheme. Deposits move tokens from the user into the contract and credit the internal balance. Withdrawals debit the internal balance and transfer tokens out. Trade settlements move balances between users internally without any on-chain token transfer. For compliance-checked tokens (security tokens), the contract calls ISecurityToken.canTransfer on deposit and withdrawal. Internal transfers during trade settlement skip this check entirely - compliance validation is the matching engine’s responsibility.
The IdentityRegistry is never called directly by StockCustody. It is referenced indirectly through StockToken’s canTransfer validation during deposit and withdrawal of compliance-checked tokens.

StockCustody

UUPS-upgradeable custody contract with internal ledger, trade settlement, liquidation handling, and emergency controls.

Initialization

The initializer sets up the admin, operator, liquidation router, and USDC address. If _operator is address(0), it defaults to the admin address.

State Variables

Access Control

Admin Management

Admin transfer is a two-step process to prevent accidental transfer to an incorrect address.

Token Configuration

The complianceChecked flag determines whether the token requires ISecurityToken.canTransfer validation on deposit and withdrawal. Set to true for security tokens, false for USDC and other standard ERC-20s. Removing a token from the supported list does not lock user funds. Users can still withdraw unsupported tokens. New deposits and trade settlements for the removed token are blocked.

Deposit and Withdrawal

Transfers tokens from the caller into custody. For compliance-checked tokens, validates canTransfer(caller, custody, amount) before transfer. The caller must have approved the custody contract for the deposit amount.
Withdraws available (unlocked) tokens from custody. Blocked if the user is frozen or withdrawals are globally paused. For compliance-checked tokens, validates canTransfer(custody, caller, amount). Allows withdrawal of unsupported tokens to prevent fund lockout after token removal.
Pre-checks whether a compliance-checked token transfer would succeed. Returns success for non-compliance-checked tokens. Use this off-chain before deposit or withdrawal to avoid wasted gas.

Balance Locking

The operator locks user balances when orders are matched, before settlement.
Locks amount from the user’s available balance (total minus already locked). Reverts with InsufficientBalance if available balance is insufficient.
Unlocks previously locked tokens. Reverts with InsufficientLockedBalance if the locked balance is less than amount.

Trade Settlement

Atomically transfers locked base tokens from seller to buyer and locked quote tokens from buyer to seller. Both parties must have sufficient locked balances. The settlementId must be unique - reuse reverts with SettlementAlreadyProcessed.
Settles multiple trades in one transaction. Skips already-processed settlement IDs. Includes a gas guard that stops processing if remaining gas drops below 80,000 per iteration. Emits BatchSettled(batchId, settledCount, totalSubmitted) so callers can detect partial completion.
The batchSettleTrades function takes 9 calldata array parameters, which exceeds the legacy compilation pipeline’s stack limit. The Solidity compiler must use viaIR: true. See Integration for compiler configuration.
Priority settlement for liquidated positions. The liquidated user’s tokens must be locked first. Use freezeUser() before locking to prevent withdrawal front-running between the lock and settlement steps. Emits both PrioritySettlement and TradeSettled.

Liquidation

Receiving Collateral

Called by the liquidation router to deliver seized collateral into custody. Tokens are pulled from the router (which must have approved the custody contract) and credited to an internal liquidation pool keyed to address(this).

External Sale Settlement

Settles after the operator sells tokens through an external venue. Stock tokens transfer to tokenRecipient. USDC is pulled from the operator and sent to the liquidation router. The lending market receives a receiveLiquidationProceeds callback. If the callback reverts, settlement still completes - off-chain systems must reconcile via events.

Internal Buyer Settlement

Matches liquidation tokens with a buyer who has USDC in custody. Tokens move from the liquidation pool to the buyer’s custody balance. USDC is deducted from the buyer’s internal balance and transferred on-chain to the router. Supports partial fills - the liquidation remains open until the full amount is matched. The lending market is notified via callback.

Emergency Controls

Per-user withdrawal freeze. Used to prevent front-running during liquidation or for compliance holds. Does not affect the user’s ability to have their balances settled by the operator.
Global withdrawal circuit breaker. Blocks all withdrawals for all users.

Stock Split Reconciliation

Adjusts internal balances after a stock token split. Both total balances and locked balances are multiplied by numerator / denominator using floor division. The liquidation pool balance for the token is also adjusted. Dust from rounding stays unallocated in the contract’s ERC-20 balance. Only forward splits are accepted (numerator must exceed denominator).

View Functions

Events

Errors


ILendingMarket

Callback interface that lending market contracts must implement to receive liquidation settlement notifications.
Called by StockCustody when a liquidation is settled (both settleLiquidation and settleLiquidationWithBuyer). If the callback reverts, settlement still completes. Off-chain systems must reconcile via LiquidationSettled or LiquidationSoldToBuyer events.