@0xmonaco/types 1.0.47 → 1.0.50-develop.9c1b239

package/dist/wire/schema.d.ts

@@ -869,6 +869,17 @@ export interface paths {
         };
         get?: never;
         put?: never;
+        /**
+         * @deprecated
+         * @description DEPRECATED (0XM-2632): this endpoint overloads two unrelated operations —
+         *      with `trading_pair_id` it allocates into that pair's isolated risk bucket
+         *      (crediting the sole open position's stored margin), without it it performs
+         *      a wallet-debiting deposit to the parent margin account. Use
+         *      `TransferCollateralToRiskBucket` for bucket funding (which now applies the
+         *      same position-margin credit) and `TransferCollateralToParentMarginAccount`
+         *      for wallet-to-margin deposits. Kept for backward compatibility; no removal
+         *      date scheduled.
+         */
         post: operations["transfer_collateral_to_margin_account"];
         delete?: never;
         options?: never;
@@ -1029,6 +1040,15 @@ export interface paths {
         };
         get?: never;
         put?: never;
+        /**
+         * @description Fund a risk bucket from the parent margin account's unallocated
+         *      collateral (no wallet movement; the bucket is created if needed). Since
+         *      0XM-2632, funding an ISOLATED bucket that holds an open position also
+         *      credits that position's stored margin — the same behavior as the
+         *      deprecated `TransferCollateralToMarginAccount` Adjust Margin rail — so
+         *      adding collateral to support a position has one behavior on every route.
+         *      A flat isolated bucket and the cross bucket stay plain allocations.
+         */
         post: operations["transfer_collateral_to_risk_bucket"];
         delete?: never;
         options?: never;
@@ -2072,23 +2092,29 @@ export interface paths {
          * Register a deposit address for monitoring
          * @description Register a deposit address for monitoring.
          *
-         *      Every (application, user) pair has a deterministic deposit address. This
-         *      registers the pair so the sweeper service watches that address and
-         *      automatically forwards every ERC20 deposit into the rollup, crediting the
-         *      user under the application.
+         *      Every (application, user, deposit target) triple has a deterministic
+         *      deposit address. This registers the caller's own address so the sweeper
+         *      service watches it and automatically forwards every ERC20 deposit into the
+         *      rollup, crediting the caller under the application.
+         *
+         *      Authenticated, and the whole identity comes from the session: the
+         *      application is the one `login` established the session under, and the
+         *      credited address is the session's own. Neither is a request parameter, so a
+         *      caller can only ever register their own address under their own
+         *      application. The only thing the body carries is which ledger to aim at.
          *
          *      Registration also runs a one-time initial check in the background: any
          *      balance already sitting on the address is swept without waiting for a new
          *      transfer. The response returns immediately with the derived address; it
          *      does not wait for that check.
          *
-         *      Idempotent and safe to retry: re-registering an existing pair returns
+         *      Idempotent and safe to retry: re-registering an existing triple returns
          *      `already_registered` with the same address and never re-triggers the
          *      initial check.
          *
-         *      Lightly rate-limited per client, and the client id must name an existing
-         *      application — the lookup is an exact string match, which is what pins the
-         *      one spelling the deposit address is derived from.
+         *      Globally rate-limited: registration creates durable state, so the endpoint
+         *      admits a bounded number per minute across all callers and answers `429`
+         *      beyond it.
          */
         post: operations["register_deposit_address"];
         delete?: never;
@@ -4064,6 +4090,14 @@ export interface components {
             riskBucketId?: string | null;
             marginMode?: string | null;
             selectedTradingPairIds?: string[] | null;
+            /**
+             * @description See `MarginAccountSummary.available_order_collateral`: the collateral
+             *      still available to open NEW orders in this risk bucket, the risk engine
+             *      admission gate's own bound with parent auto top-up included. Present only
+             *      on risk-bucket rows served from a live engine snapshot; absent on parent
+             *      rows and persisted-fallback reads.
+             */
+            availableOrderCollateral?: string | null;
         };
         GetMarkPriceResponse: {
             /** Format: uuid */
@@ -5706,6 +5740,42 @@ export interface components {
             marginMode?: string | null;
             /** @description Present for cross risk-bucket summary rows. */
             selectedTradingPairIds?: string[] | null;
+            /**
+             * @description The collateral still available to open NEW orders in this risk bucket:
+             *      the largest increase in the bucket's worst-case order reserve the risk
+             *      engine's admission gate accepts, automatic top-up from the parent margin
+             *      account's unallocated capacity included. Zero while the account or bucket
+             *      is frozen for liquidation, and for an isolated bucket whose market is
+             *      halted. (A cross bucket's market is chosen per order, so a halt cannot be
+             *      folded into its figure — a halted pair still refuses orders.)
+             *
+             *      The trading-side sibling of `withdrawable_collateral`, and deliberately a
+             *      different figure: this one credits an unrealized gain in full, because a
+             *      gain is legitimate initial margin for new positions, while a withdrawal
+             *      never counts one. It already contains the bucket's live free collateral —
+             *      do not add `free_collateral` or `unrealized_pnl` on top. It can also
+             *      legitimately differ from this row's `free_collateral`, which is a
+             *      persisted reconstruction that cannot see the engine's worst-case
+             *      resting-order reserve.
+             *
+             *      NOT additive across rows: every bucket's figure includes the SAME parent
+             *      unallocated headroom, so summing rows multiply-counts it, and committing
+             *      collateral in one bucket shrinks its siblings' figures.
+             *
+             *      This is a requirement budget, not an order size: an order is charged the
+             *      increase it causes in the bucket's worst-case per-pair reserve, so a
+             *      reducing, reduce-only, or opposite-side order sheltered by a larger
+             *      resting ladder needs less or none of it (and can be admitted even when
+             *      this field is zero), while an order crossing a losing position can need
+             *      more than its own margin-plus-fee. Divide by a market's initial margin
+             *      rate for indicative notional capacity; the authoritative per-order answer
+             *      remains `simulate_risk_bucket_order_risk`.
+             *
+             *      Present only on risk-bucket summary rows served from a live risk engine
+             *      snapshot; absent on parent rows and on persisted-fallback reads, where
+             *      neither of the gate's terms is reconstructable.
+             */
+            availableOrderCollateral?: string | null;
         };
         MatchResult: {
             /**
@@ -6081,6 +6151,19 @@ export interface components {
              *      may carry sub-tick tails).
              */
             withdrawableCollateral?: string | null;
+            /**
+             * @description The collateral still available to open NEW orders in this risk bucket —
+             *      the same engine-served admission bound as
+             *      `MarginAccountSummary.available_order_collateral` (see that field for the
+             *      full semantics: an envelope delta with parent auto top-up included, NOT
+             *      additive across rows, zero while frozen), truncated toward zero at quote
+             *      decimals like `withdrawable_collateral` beside it.
+             *
+             *      Present only when a live risk engine snapshot served the bound; absent on
+             *      persisted-fallback reads, where neither of the gate's terms is
+             *      reconstructable.
+             */
+            availableOrderCollateral?: string | null;
         };
         PortfolioSeriesWindow: {
             /**
@@ -6455,25 +6538,21 @@ export interface components {
         };
         RegisterRequest: {
             /**
-             * @description The application's client id — the same identifier rollup deposits carry and `login` takes. The deposit address is derived from these exact bytes and the application lookup is an exact string match, so the spelling must match the registered application precisely.
-             * @example 60eb377aab9f4ea18dcdf4747204c792
-             */
-            clientId: string;
-            /**
-             * @description Address credited on the rollup, and half of the deposit address derivation
-             * @example 0x742d35Cc6634C0532925a3b8D4060f31E2C3d8B5
+             * @description Which ledger swept deposits are requested to be credited to. `SPOT` (the default when omitted) credits the spot wallet; `MARGIN` asks for the parent margin account's collateral, skipping the separate collateral transfer. The target is part of the address derivation, so `SPOT` and `MARGIN` yield two different deposit addresses for the same pair, and each address carries its own request. `MARGIN` is a routing request rather than a guarantee: a deposit the matching engine cannot route to collateral — an unsupported collateral asset, or a margin account that fails validation — is credited to the spot wallet instead, so funds are never stranded. A `SPOT` address is never credited to margin.
+             * @example MARGIN
+             * @enum {string|null}
              */
-            userAddress: string;
+            depositTarget?: "SPOT" | "MARGIN" | null;
         };
         RegisterResponse: {
             /**
-             * @description `registered` when the pair was added, `already_registered` when it was known before this call
+             * @description `registered` when the triple was added, `already_registered` when it was known before this call
              * @example registered
              * @enum {string|null}
              */
             status?: "registered" | "already_registered" | null;
             /**
-             * @description The pair's deposit address. Stable, and valid to publish and fund before any contract exists there.
+             * @description The deposit address for this (application, user, deposit target) triple. Stable, and valid to publish and fund before any contract exists there.
              * @example 0xcf1eF339798914EF7Ee4984Ed45BD141D63a65C9
              */
             sweeperAddress?: string | null;
@@ -7298,6 +7377,16 @@ export interface components {
             marginMode?: string | null;
             /** @description Present for cross risk-bucket transfers. */
             selectedTradingPairIds?: string[] | null;
+            /**
+             * @description Whether the transfer was committed to a position's stored margin.
+             *      Present only when a position-margin credit was in play: true — the credit
+             *      landed; false — a credit was requested (or defaulted) but degraded to a
+             *      plain allocation because the bucket's persisted position row was stale
+             *      (close/reopen race) — re-issue the Adjust Margin once the new position
+             *      row lands if the commitment still matters. Absent on plain allocations,
+             *      parent deposits, and releases.
+             */
+            positionMarginCredited?: boolean | null;
         };
         TransferCollateralToParentMarginAccountRequest: {
             asset?: string | null;
@@ -7317,6 +7406,31 @@ export interface components {
             marginMode?: string | null;
             /** @description Trading pair UUIDs selected into the cross risk bucket. Required when marginMode is CROSS. */
             selectedTradingPairIds?: string[] | null;
+            /**
+             * @description What the transferred collateral becomes when the ISOLATED bucket holds an
+             *      open position. The two intents want opposite fates for the same dollars,
+             *      so the caller states theirs:
+             *
+             *      - true (and UNSET — the default is the human "Adjust Margin" gesture):
+             *       the amount is COMMITTED to the position's stored margin. Effective
+             *       leverage drops and stays down, initial margin required rises by the
+             *       amount, free collateral is unchanged — new orders cannot spend it.
+             *      - false: plain allocation. Free collateral rises and the next order can
+             *       spend it. Programmatic funding loops that top a bucket up to a free
+             *       collateral target MUST pass false, or each top-up converts into
+             *       requirement and the loop never converges.
+             *
+             *      Either way the liquidation cushion improves identically (the breach
+             *      check is bucket-equity based). On a FLAT isolated bucket there is no
+             *      position to commit to and both values are a plain allocation. Explicit
+             *      true is rejected for CROSS buckets (cross has no per-position margin);
+             *      unset/false is a plain allocation there.
+             *
+             *      The response reports what actually happened in `position_margin_credited`
+             *      — a credit can degrade to a plain allocation when the persisted position
+             *      row is stale (close/reopen race).
+             */
+            applyToPositionMargin?: boolean | null;
         };
         TransferRewardsRequest: {
             /**
@@ -11951,14 +12065,21 @@ export interface operations {
                 };
                 content?: never;
             };
-            /** @description Application not found */
-            404: {
+            /** @description Authentication required */
+            401: {
+                headers: {
+                    [name: string]: unknown;
+                };
+                content?: never;
+            };
+            /** @description The application for this session is not active */
+            403: {
                 headers: {
                     [name: string]: unknown;
                 };
                 content?: never;
             };
-            /** @description Registration rate-limit exceeded */
+            /** @description Registration admission limit exceeded; retry shortly */
             429: {
                 headers: {
                     [name: string]: unknown;

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@0xmonaco/types",
-	"version": "1.0.47",
+	"version": "1.0.50-develop.9c1b239",
 	"type": "module",
 	"homepage": "https://docs.0xmonaco.com/sdk/typescript",
 	"main": "./dist/index.js",
@@ -16,7 +16,7 @@
 		"lint": "biome lint ."
 	},
 	"dependencies": {
-		"@0xmonaco/contracts": "1.0.47",
+		"@0xmonaco/contracts": "1.0.50-develop.9c1b239",
 		"zod": "^4.1.12"
 	},
 	"peerDependencies": {