> ## 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.87 # Monaco Protocol SDK v1.0.87 Order-create idempotency keys now replay for 15 minutes after acceptance instead of 24 hours. The deprecated PitPass aliases are gone: `sdk.pitpass`, `PitpassAPIImpl`, the React `usePitpass` module and the `/api/v1/pitpass/...` paths. A wallet keeps its first referrer, and sign-in reports why a presented TraderCode did not apply. Frontends can set a maker add-on beside the builder fee, and account movements now list deposits and withdrawals that go straight into or out of the parent margin account. **Action items:** never retry an unresolved order submission past 15 minutes; replace any `sdk.pitpass`, `usePitpass` or `/api/v1/pitpass/...` use with `sdk.tradercodes`, `useTraderCodes` and `/api/v1/tradercodes/...`. ## Breaking ### Idempotency keys replay for 15 minutes `idempotencyKey` on `placeLimitOrder` / `placeMarketOrder` (`POST /api/v1/orders`; gRPC `OrdersService.CreateOrder`) and each item's `idempotencyKey` on `batchCreate` (`POST /api/v1/orders/batch-create`; gRPC `OrdersService.BatchCreateOrders`) now replays for 15 minutes after the original acceptance, down from 24 hours. Request and response fields are unchanged. * Retrying the same key and normalized payload within 15 minutes still returns the original committed result without executing again. Retries do not extend the window. * After 15 minutes the same key is a new submission and can place a new order. Never retry an unresolved submission past that window; reconcile on the order stream instead. * Keys accepted before this release keep their original 24-hour expiry. * The engine caps how many unexpired keys it retains. At that ceiling a new key is refused with the existing retryable `ORDER_SUBMISSION_CAPACITY_EXCEEDED` (HTTP `503` / gRPC `UNAVAILABLE`, or a per-item batch error), which accepts and reserves nothing. Retries of an already accepted key, and orders without a key, are unaffected. See [Safe Retries](/developers/trade#safe-retries-with-idempotency-keys). ### PitPass aliases removed The PitPass names deprecated in v1.0.82 are removed. Each had the same methods, messages and responses as its TraderCodes replacement: * `@0xmonaco/core`: the `sdk.pitpass` property and the `PitpassAPIImpl` class. Use `sdk.tradercodes` and `TraderCodesAPIImpl`; since v1.0.82 `sdk.pitpass` was the same object, so renaming the property is the only change. * `@0xmonaco/types`: the `PitpassAPI` type and the `pitpass` field on `MonacoSDK`. Use `TraderCodesAPI` and `tradercodes`. The wire types drop the `/api/v1/pitpass/...` operations and their `pitpass_` prefixed operation ids. * `@0xmonaco/react`: the `usePitpass` module. Import the same hooks (`useMyTraderCode`, `useSetTraderCode`, `useClearTraderCode`, `useTraderCodeAvailability`, `useTraderCodeInfo`, `useRewardsBalance`, `useTransferRewards`, `useMyReferralPosition`, `useMyReferralDownline`, `useMyReferralTree`) from `useTraderCodes` or the package root. * REST: `/api/v1/pitpass/...` returns `404`. Use `/api/v1/tradercodes/...`. * gRPC: `monaco.api.pitpass.TraderCodeService` returns `UNIMPLEMENTED`. Use `monaco.api.tradercodes.TraderCodeService`. * Rust: the `pitpass_` prefixed methods leave `monaco-sdk`, and the `monaco.api.pitpass` module leaves `monaco-grpc-sdk`. See [TraderCodes](/sdk/typescript/tradercodes). ## Added ### Why a referral did not apply `AuthState`, returned by `sdk.auth.authenticate` and `sdk.auth.verifySignature` (`POST /api/v1/auth/verify`; gRPC `AuthService.Verify`), may carry `referralNotAppliedReason` when a TraderCode presented on a first sign-in did not record a referral: * `REFERRAL_NOT_APPLIED_REASON_ALREADY_REFERRED`: the wallet already has a different referrer from an earlier sign-up, on this or another application * `REFERRAL_NOT_APPLIED_REASON_UNKNOWN_CODE`: the code matches no TraderCode * `REFERRAL_NOT_APPLIED_REASON_SELF_REFERRAL`: the code is the wallet's own The key is absent when the code applied, when none was presented, for a returning user, and against an older server. The new `ReferralNotAppliedReason` type is widened to `string` for values added later. A wallet now keeps its first referrer across applications. A first sign-in to another application with a different referrer's code records no referral and returns `referralApplied: false` with `ALREADY_REFERRED`, where it previously recorded one. Sign-in succeeds either way, and a code from the same referrer is still recorded. See [Auth](/sdk/typescript/auth) and [TraderCodes](/developers/tradercodes). ### Builder maker add-on `setBuilderFee` (`PUT /api/v1/buildercodes/builder-fee`; gRPC `BuildercodeRewardsService.SetBuilderFee`) takes optional `makerBps` beside `bps`: an add-on your frontend charges makers, from `0` up to `builderFeeCapBps` (at most `100`). Omitting it leaves the maker add-on unchanged, and one call that sets both sides counts as one change against the two-per-24-hours limit. A new maker add-on applies to orders placed after the next BuilderCodes enrollment refresh, shortly after it is saved; resting orders keep the rate they were placed with. * `SetBuilderFeeResponse` adds `builderMakerFeeBps` and `previousBuilderMakerFeeBps`; `getConfig` adds `builderMakerFeeBps`; `BuilderFeeChange` adds `oldMakerBps` and `newMakerBps`. * Payout kind `BUILDER_MAKER_FEE` is accepted by the `listPayouts` `kind` filter and appears on payouts and `byTokenAndKind`. `getPayoutSummary` adds `builderFeeByToken` (`BUILDER_FEE` plus `BUILDER_MAKER_FEE` per token). * `simulateFees` (gRPC `FeesService.SimulateFees`) adds `applicationMakerFee` and `applicationMakerFeeBps`, and `makerTotalReceipt` nets the add-on. * `getApplicationStats` (gRPC `ApplicationsService.GetAppStats`) adds `applicationMakerFee` and `builderFeeTotal`; `applicationTakerFee` stays taker-only. * On a maker's trade row and order event, `builderFee` is the maker add-on. See [BuilderCodes](/developers/buildercodes). ## Fixed ### Margin account deposits and withdrawals in movements `getPaginatedUserMovements` (`GET /api/v1/accounts/movements`; gRPC `AccountsService.GetMovements`) listed only spot wallet movements, so a deposit routed into the parent margin account and a withdrawal paid out of it never appeared. They now appear as `DEPOSIT` / `CREDIT` and `WITHDRAWAL` / `DEBIT` rows with the token amount, `referenceType` `margin_account_deposit` or `margin_account_withdrawal`, and `referenceId` set to the margin account id. A margin deposit carries its `txHash`. `balanceBefore` and `balanceAfter` are `0` on these rows, because margin collateral is not a wallet balance. The `DEPOSIT` and `WITHDRAWAL` filters include them. Earlier margin movements are not backfilled. See [Account Balances](/developers/account-balances#movements). ## Upgrade ```bash theme={null} npm install @0xmonaco/core@1.0.87 @0xmonaco/types@1.0.87 @0xmonaco/react@1.0.87 # or bun bun add @0xmonaco/core@1.0.87 @0xmonaco/types@1.0.87 @0xmonaco/react@1.0.87 ``` Rename any `sdk.pitpass` to `sdk.tradercodes` and any `usePitpass` import to `useTraderCodes`. Check that order-submission retries stop within 15 minutes of acceptance. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.