Monaco Protocol SDK v1.0.96
This release rolls up the consumer-facing changes shipped since v1.0.94. Funding now charges the window’s mean premium divided by 60, sub-accounts gain a lifetime cap on how many can be created, and the orderbook subscribe-time snapshot added in v1.0.94 now arrives. Action items: expect funding rates about 1/60 of what the same book produced before, and rescale any display, alert or strategy threshold built on the old size; readmarket_stats funding_clamp_small / funding_clamp_big as the settled-rate bound, now 0.000125; once a user reaches the lifetime sub-account cap, re-open a closed sub-account instead of creating a new key. No field is added, removed or renamed.
Changed
Funding is the window’s mean premium over 60
A window’s funding rate is now its mean premium divided by 60: a premium held for a whole hour is charged at 1/60 of its size for that hour, so a book 0.6% over the index pays 0.01%. Each premium sample is still bounded to ±0.75%, so a settled rate is at most 0.0125% per hour. The interest-rate component stays zero. Settled rates use the divided rate:currentFundingRate on sdk.market.getFundingState (GET /api/v1/market/pairs/{tradingPairId}/funding; gRPC MarketService.GetFundingState), fundingRate, fundingDeltaPerUnit and cumulativeFundingPerUnit in funding history (GET /api/v1/market/pairs/{tradingPairId}/funding/history and GET /api/v1/market/funding/history), and every funding payment. A window that settles at the carried last rate is not divided again.
Estimates follow: estimatedNextFundingRate on the funding state, the perp summary (GET /api/v1/market/pairs/{tradingPairId}/perp/summary) and the screener (GET /api/v1/market/screener) is the open window’s mean premium over 60, or the already-settled rate while a settlement is pending. On the market_stats channel, funding_rate is the same estimate, while premium stays the raw window mean premium, so funding_rate = premium / 60 while no settlement is pending. funding_clamp_small and funding_clamp_big now carry the highest settled rate, 0.000125, instead of 0.0075. See Funding Rates.
A window settles on its own premium with 360 accepted samples
A funding window now needs 360 accepted samples, half the window at the 5-second cadence, to settle at its own premium; it needed 600. A window with fewer still settles at the last settled rate. See Window Aggregation.A lifetime cap on sub-accounts created
Besides the cap on open sub-accounts, an owner may now create at most three times that many distinct sub-accounts, closed ones included: 30 at the first volume tier, up to 150.createMarginSubAccount (POST /api/v1/margin/sub-accounts; gRPC MarginAccountsService.CreateSubAccount) refuses a new key past it with 400 (INVALID_ARGUMENT) and the message sub-account limit reached: at most {n} sub-accounts can be created; re-open a closed one instead. Re-opening a closed key never counts toward it, and copy-trading sub-accounts count toward neither cap. See Sub-Accounts.
Fixed
The orderbook subscribe-time snapshot arrives
Anorderbook subscribe now gets its subscribe-time snapshot. Before, the server answered every one with SNAPSHOT_UNAVAILABLE, so onSnapshot on sdk.ws.orderbook never fired. Keep the REST read for when the channel still answers SNAPSHOT_UNAVAILABLE. See Subscribe-time snapshots.
Concurrent sub-account creates respect the open cap
Sub-account creates sent in parallel could each pass the open-sub-account check and together open more than the cap. The cap is now counted as each create is applied, so the creates past it are refused with the same400 as a single create past the cap.