Skip to main content

​
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.

​
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.

​
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 and 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.

​
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.

​
Upgrade

Rename any sdk.pitpass to sdk.tradercodes and any usePitpass import to useTraderCodes. Check that order-submission retries stop within 15 minutes of acceptance.