A function that takes a Transaction object
Grant session authority over the Account until now + durationMs.
Authority is derived from the transaction SENDER, so the owner must sign this.
durationMs must be > 0 and <= MAX_SESSION_DURATION_MS; an Account holds at
most MAX_SESSIONS_PER_ACCOUNT distinct addresses. Re-authorizing an address
replaces its expiry in place and consumes no additional slot.
The owner's canonical ACCOUNT id — a different derived object from the wrapper. The session grants hang off this one, so this is what deriveSessionsFieldId and decodeSessions work from.
The object id of the owner's DataKey<SessionsApp> dynamic field —
fetch this object and pass its BCS contents to decodeSessions. There is no
bulk on-chain read, so this is the route to enumerating grants.
A function that takes a Transaction object and returns the record id (u64)
A function that takes a Transaction object and returns the record id (u64)
A function that takes a Transaction object and returns the record id (u64)
A function that takes a Transaction object and returns the new record id (u64)
A function that takes a Transaction object and returns the new order id (u256)
Mint by spending up to a premium budget, flooring the quantity received.
The chain requires maxCost > 0.
Retired by delayed execution (DBU-885): always aborts through Predict v4. Use SessionsContract.enqueueExactAmount.
Mint within an all-in budget as a session. Amounts are raw Move units. Requires Sessions/Predict v2 or later.
Retired by delayed execution (DBU-885): always aborts through Predict v4. Use SessionsContract.enqueueExactCost.
A function that takes a Transaction object and returns the new order id (u256)
Mint a position of an exact payout quantity, as session. Pass
u64::MAX for maxCost / maxProbability to leave either slippage cap
effectively unbounded — the chain asserts value <= cap, so the max value can never
trip. Both are required; there is no default.
Retired by delayed execution (DBU-885): always aborts through Predict v4
(EDelayedExecutionRequired). Use SessionsContract.enqueueExactQuantity.
A function that takes a Transaction object and returns Option<u256> — the
replacement order id when a partial close leaves quantity open
Close part or all of a live position at the pricer's mark, as session.
minProbability / minProceeds are close-side slippage floors; 0 disables either,
and OMITTING them is 0 — unlike the mint caps, which are required. On a delegated
key this is the direction that closes a position at any price, so pass real floors
unless you mean to accept whatever the mark gives you.
Retired by delayed execution (DBU-885): always aborts through Predict v4. Account positions then have no early exit; queued fills are Open records sold with SessionsContract.enqueueRedeemOpen.
A function that takes a Transaction object
A function that takes a Transaction object
Remove session's grant. Owner-signed, like authorizeSession.
Deliberately takes no SessionsConfig: revocation is not version-gated, so it keeps
working after the package is retired. Revoking an address that holds no grant is a
silent no-op — it neither aborts nor emits, so read before and after if you need to
distinguish "revoked" from "was never granted".
A function that takes a Transaction object
StaticactiveGrants from decodeSessions that are still live at nowMs.
StaticdecodeDecode an Account's stored grants from the raw BCS content of its
DataKey<SessionsApp> dynamic FIELD object — the whole
Field<DataKey<SessionsApp>, SessionsData>, as the core API returns it, not the
inner SessionsData. Get the id from deriveSessionsFieldId.
There is no bulk on-chain read — sessionExpirationMs answers one address at a time —
so listing grants means fetching that field and decoding it here. Note the field hangs
off the DERIVED ACCOUNT address, not the wrapper address; they are different objects.
Expired grants are never pruned automatically and keep occupying slots, so callers managing the MAX_SESSIONS_PER_ACCOUNT cap should list, drop anything already expired, and revoke before granting again.
StaticexpiredGrants that are already dead at nowMs — the complement of
activeSessions, and the list to revoke when reclaiming slots. Use this rather
than filtering by hand: nowMs > expiresAtMs looks equivalent but leaves the grant
expiring exactly at nowMs occupying a slot forever.
SessionsContract — time-limited trading sessions over a canonical Account.
An Account owner authorizes an ephemeral address to submit a bounded set of transactions on the Account's behalf until a fixed expiry. The session key never receives a reusable
Auth: each wrapper mints app authorization internally and consumes it in the same call.WHAT A SESSION KEY CAN DO. It cannot withdraw to an address, cannot grant or revoke sessions, and cannot outlive its expiry — those all require owner auth. It CAN trade the Account's full balance: the spot wrappers take a caller-chosen
Pooland, throughdeepbook_core_account, pull the account's entire Base, Quote and DEEP balance (stored plus unsettled) into the embedded manager for the duration of the call, withprice_limitsupplied by the caller. Nothing caps notional, restricts which pools are reachable, or bounds loss to adverse pricing. Treat a session key as authority over everything the Account holds, and fund an ephemeral-session Account accordingly.Operational precondition: an admin must have authorized
SessionsAppon the account registry. Until then — or after adeauthorize_app— the TRADING wrappers abort withEAppNotAuthorized;authorizeSession,revokeSessionandsessionExpirationMsuse owner auth or no auth and keep working. Note thatdeauthorize_appdoes not clearSessionsData, so re-authorizing makes every still-unexpired grant live again at once — it is a pause, not a kill switch. Revoking, and reading expirations, also keep working if the sessions package is later version-gated.This class wraps the session lifecycle and the Predict entrypoints. The DeepBook spot session wrappers are generated (see
sessionsMoveCalls) but are not wrapped here — noteplaceLimitOrderandplaceMarketOrderputaccountRegistryat index 2 andsessionsConfigat 4, becausedeepbookRegistrysits between them; the other three (cancelLiveOrder,cancelLiveOrders,withdrawSettledAmounts) take nodeepbookRegistryand so keep 1 and 3 like the Predict wrappers: the surrounding spot-over-Account workflow — discovering the embedded balance manager, reading resting orders and locked balances — is not modelled yet, so a wrapped builder would be hard to use well. They are reachable from the generated bindings meanwhile.