Struct AccountState 

pub struct AccountState { /* private fields */ }

Implementations

impl AccountState

pub fn new( balances: FnvHashMap<AssetNameExchange, AssetBalance<AssetNameExchange>>, orders_open: OpenOrders, orders_cancelled: FnvHashMap<ClientOrderId, Order<ExchangeId, InstrumentNameExchange, Cancelled>>, trades: Vec<Trade<AssetNameExchange, InstrumentNameExchange>>, ) -> Self

pub fn orders(&self) -> &OpenOrders

This account’s open orders, indexed for lookup and ordered for matching.

pub fn orders_mut(&mut self) -> &mut OpenOrders

This account’s open orders, for a venue booking, matching or cancelling one.

pub fn ack_cancelled( &mut self, order: Order<ExchangeId, InstrumentNameExchange, Cancelled>, )

Records that order was cancelled, so it is reported by a later account snapshot and a second cancel for it can be told apart from a cancel for an order that never existed.

pub fn is_cancelled(&self, cid: &ClientOrderId) -> bool

Whether cid names an order this account cancelled.

pub fn ack_filled(&mut self, cid: ClientOrderId)

Records that cid filled, so a cancel that loses the race to it can say so.

pub fn is_filled(&self, cid: &ClientOrderId) -> bool

Whether cid names an order this account filled.

pub fn ack_expired( &mut self, order: Order<ExchangeId, InstrumentNameExchange, Expired>, )

Records that order reached its own deadline, so it is reported by a later account snapshot and a cancel arriving after it can be told apart from a cancel for an unknown order.

pub fn is_expired(&self, cid: &ClientOrderId) -> bool

Whether cid names an order that reached its deadline while this account held it.

pub fn update_time_exchange(&mut self, time_exchange: DateTime<Utc>)

Restates every balance as of time_exchange.

Open orders keep their own stamps

Open::time_exchange is the instant the venue accepted the order, and an order does not become a different order because time passed. This used to rewrite it on every advance, which was invisible only because nothing rested: the venue filled every order on arrival, so orders_open held at most what an initial_state seeded.

It is not invisible once orders rest. Arrival order is half of price-time priority, so rewriting it would make a matching engine’s tie-break depend on when the clock last moved rather than on when each order arrived — and since every order would be rewritten to the same instant, there would be no tie-break left at all. It would also make every open order look newer than the engine’s copy on each advance, which is exactly what the rustrade engine’s OrderManager recency guard reads to decide whether an update is stale.

pub fn balances( &self, ) -> impl Iterator<Item = &AssetBalance<AssetNameExchange>> + '_

pub fn orders_open( &self, ) -> impl Iterator<Item = &Order<ExchangeId, InstrumentNameExchange, Open>> + '_

Every open order, in no particular order — see OpenOrders::resting for the order a venue matches in.

pub fn orders_cancelled( &self, ) -> impl Iterator<Item = &Order<ExchangeId, InstrumentNameExchange, Cancelled>> + '_

pub fn orders_expired( &self, ) -> impl Iterator<Item = &Order<ExchangeId, InstrumentNameExchange, Expired>> + '_

pub fn trades( &self, time_since: DateTime<Utc>, ) -> impl Iterator<Item = &Trade<AssetNameExchange, InstrumentNameExchange>> + '_

pub fn balance_mut( &mut self, asset: &AssetNameExchange, ) -> Option<&mut AssetBalance<AssetNameExchange>>

pub fn ack_trade( &mut self, trade: Trade<AssetNameExchange, InstrumentNameExchange>, )

pub fn reserve( &mut self, asset: &AssetNameExchange, amount: Decimal, time_exchange: DateTime<Utc>, ) -> Result<AssetBalance<AssetNameExchange>, BalanceInsufficient>

Holds amount of asset against an order, moving it out of free.

total is untouched: the asset is still held, it is merely no longer spendable. The held portion is total - free, which is what Balance::used reports and what a venue restates to its client.

Errors

BalanceInsufficient if free does not cover amount. The ledger is left untouched, so a caller may reject the order and carry on.

Panics

Panics if asset has no balance. The balances are the venue’s own fixture, so an absent one is a mis-specified account rather than a runtime condition — see SimulatedVenue’s caller obligations.

pub fn settle( &mut self, asset: &AssetNameExchange, amount: Decimal, time_exchange: DateTime<Utc>, ) -> AssetBalance<AssetNameExchange>

Settles amount of asset already held by reserve out of the account.

Only total moves: free was reduced when the amount was reserved. Reserving and then settling the same amount therefore lowers both by it, which is what an order that fills on arrival does.

Panics

Panics if asset has no balance — see reserve. Settling more than is held would take total below free and break the ledger’s invariant, so it panics in debug builds; callers settle an amount they reserved.

pub fn release( &mut self, asset: &AssetNameExchange, amount: Decimal, time_exchange: DateTime<Utc>, ) -> AssetBalance<AssetNameExchange>

Gives amount of asset back to free, undoing a reserve that will never be settled.

Only free moves: nothing left the account, so total is unchanged. This is what a cancelled, expired or rejected order does to the balance held against it.

Panics

Panics if asset has no balance — see reserve. Releasing more than is held would take free above total and break the ledger’s invariant, so it panics in debug builds; callers release an amount they reserved.

pub fn commit( &mut self, debit: &Debit, time_exchange: DateTime<Utc>, ) -> Result<AssetBalance<AssetNameExchange>, BalanceInsufficient>

Commits one arriving order’s whole ledger effect, or none of it.

One order’s arrival can both settle a fill and take a hold: a taker that the book could only partly fill settles what traded and reserves against the remainder it leaves resting. Those are one event at the venue, so they are one operation here — and because reserve tests free before it moves anything, an arrival this account cannot afford leaves the ledger exactly as it found it.

Why this is not two calls

Settling first and reserving second is the same two moves in the order that can fail halfway: the settle commits, the reserve is refused, and nothing puts back what total has already lost — release moves only free, and its own assertion fires if it is used as a rollback. The venue would then hold a balance its client never hears about, silently and for the rest of the run. Asking for the whole requirement up front is what makes that state unreachable rather than merely avoided.

One arrival, one restatement

The returned balance is the only one an arrival owes. A balance is an absolute restatement rather than a delta, and a fill is atomic at the venue, so emitting the state between the settle and the hold would report a balance the account never held — for the same reason a conservative reservation that had to be released and re-debited would.

Errors

BalanceInsufficient if free does not cover settled + reserved, leaving the ledger untouched.

Panics

Panics if the asset has no balance — see reserve.

Trait Implementations

impl Debug for AccountState

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl From<AccountSnapshot<ExchangeId, AssetNameExchange, InstrumentNameExchange>> for AccountState

fn from(value: UnindexedAccountSnapshot) -> Self

Converts to this type from the input type.