> ## Documentation Index
> Fetch the complete documentation index at: https://docs.0xmonaco.com/llms.txt
> Use this file to discover all available pages before exploring further.

# V1.0.44

# Monaco Protocol SDK v1.0.44

This release adds an opt-in `asErc20` deposit path for the chain's wrapped-native asset, so you can deposit it as its ERC20 (approve + `depositERC20`) instead of the native-coin default introduced in 1.0.43; and a `withdrawableCollateral` figure on portfolio margin that names the amount that can actually leave a margin account or risk bucket. It also documents a server-side correction to `replaceOrder`: `newOrder.quantity` now names the order's new **total** quantity, and the replacement inherits the original's fill history. One thing to act on: if you replace a partially filled order by `quantity`, pass the new total rather than the remainder — see the change below.

## Added

### `asErc20` deposit option for the wrapped-native asset

`sdk.vault.deposit()` accepts an `options.asErc20` flag (`@0xmonaco/core`; `DepositOptions` and `DepositSchema` in `@0xmonaco/types`). Since 1.0.43 the chain's wrapped-native asset (e.g. WSEI) deposits as native coin through the payable `depositNative` with no ERC20 approval. Passing `asErc20: true` instead deposits it as its ERC20 through the standard approve + `depositERC20` flow — for wallets that hold the wrapped ERC20 itself — and `sdk.vault.needsApproval()` with the same option reads the real WSEI allowance rather than short-circuiting to `false`. Every other asset, and a wrapped-native deposit without the flag, is unchanged.

`options` is the fifth argument to `deposit()` and the third to `needsApproval()`. The ERC20 path is not auto-approved — `deposit()` throws a `ContractError` (`code === "CONTRACT_ERROR"`) whose `revertReason` is `"APPROVAL_REQUIRED"` if the allowance is short, so approve first exactly as you would for any ERC20:

```ts theme={null}
// deposit the wrapped-native asset as its ERC20 (approve + depositERC20)
if (await sdk.vault.needsApproval(assetId, amount, { asErc20: true })) {
  await sdk.vault.approve(assetId, amount);
}
await sdk.vault.deposit(assetId, amount, /* autoWait */ true, /* target */ "spot", { asErc20: true });
```

### `withdrawableCollateral` on portfolio margin

`sdk.portfolio.getMargin()` (`GET /api/v1/accounts/me/portfolio/margin`; gRPC `AccountsService.GetPortfolioMargin`) adds `withdrawableCollateral` (decimal string) to both `PortfolioMarginTotal` and each `PortfolioRiskBucket` in `@0xmonaco/types`. It is the largest amount that can actually leave the parent margin account or risk bucket — the bound the engine enforces on transfers-out and withdrawals, and the effective ceiling on funding new isolated / first-use positions (bucket allocation passes the same principal-gated door). Unlike `parentAvailableCollateral` / `freeCollateral` (equity figures) it excludes unrealized gains and non-principal balances such as banked realized PnL; on the parent it is `min(deposited principal − bucket allocations, freeCollateral − max(unrealizedPnl, 0))`, floored at zero. Size transfers, withdrawals, and new isolated positions from `withdrawableCollateral`; keep `freeCollateral` as trading-margin headroom for existing cross exposure. The `GetAvailableCollateralResponse.marginAvailableCollateral` doc was clarified to say the same.

## Changed

### `replaceOrder`'s quantity is the order's new total

`sdk.trading.replaceOrder()` (`PUT /api/v1/orders/{orderId}`; gRPC `OrdersService.ReplaceOrder`) now treats `newOrder.quantity` as the order's new **total** quantity. On a partially filled order the replacement rests `total - filled` and locks collateral for that remainder only (FIX cancel/replace convention: `LeavesQty = OrderQty - CumQty`); the total must exceed the filled amount. Previously the value was placed as a fresh order size, so replacing a 96/100-filled order with `quantity: "200"` rested 200 and locked for all 200 (total exposure 296) — it now rests 104 and reads as 96/200 filled. A replace that omits `quantity` keeps the order's total, derived against the live fill state inside the matching step, so a fill landing while the request is in flight can no longer make the replacement rest more than the true remainder; the response's `updatedFields.quantity` reports that total (previously a point-in-time remainder snapshot). Unfilled orders are unaffected, and margin reduce-only replacements are exempt (explicit quantities stay close sizes). `batchReplace` items (`BatchReplaceOrderItem.quantity`) carry the same total semantics.

The replacement also inherits the original's fill history — filled quantity, VWAP, and realized fee / payment aggregates carry onto the new order's row, exactly as if the order had been edited in place. The retired original keeps its own terminal row, so summing fill aggregates **across** a replacement chain's rows double-counts the carried history; per-order reads and trade-level data are unaffected. Types and wire shape are unchanged — this is a server-side semantics correction, so clients on any SDK version get the new behavior.

### Package metadata points at the public docs site

Every published package drops its `repository` field and sets `homepage` to the public docs. The previous `repository` URL referenced a private GitHub repository, so the Repository and Homepage links on the package page returned 404 for anyone outside the org; there is no public source repository to point at, so the field is omitted rather than redirected. The five npm packages (`@0xmonaco/core`, `@0xmonaco/types`, `@0xmonaco/react`, `@0xmonaco/contracts`, `@0xmonaco/mcp-server`) point at `https://docs.0xmonaco.com/sdk/typescript`; the two published Rust crates point at their own reference — `monaco-sdk` at `https://docs.0xmonaco.com/sdk/rust-rest` and `monaco-grpc-sdk` at `https://docs.0xmonaco.com/sdk/rust-grpc` (their rustdoc landing link follows the same target, and `documentation` still points at docs.rs). No code, type, or behavior changes — this is why `@0xmonaco/react`, `@0xmonaco/contracts`, `@0xmonaco/mcp-server`, and both Rust crates bump to 1.0.44 with no behavior change.

## Upgrade

```bash theme={null}
npm install @0xmonaco/core@1.0.44 @0xmonaco/types@1.0.44 @0xmonaco/react@1.0.44 @0xmonaco/contracts@1.0.44
# or bun
bun add @0xmonaco/core@1.0.44 @0xmonaco/types@1.0.44 @0xmonaco/react@1.0.44 @0xmonaco/contracts@1.0.44
```

The MCP server ships at `1.0.44` too; it runs via `npx -y @0xmonaco/mcp-server`, so restarting your assistant picks up the new version. The API changes are additive and backward-compatible — a new optional `withdrawableCollateral` response field on portfolio margin and the new opt-in `DepositOptions` / `DepositSchema` types — and every SDK bump is a patch release, so the upgrade is drop-in for almost everyone. The one compatibility boundary is behavioral: `replaceOrder`'s `quantity` is now the order's **total**, so a partially filled `replaceOrder` that used to pass the remaining quantity now rests the wrong size — and is rejected outright when that value is at or below the amount already filled. Audit those calls before upgrading; everything else is backward-compatible.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.