Jupiter Dev Notifications
الذهاب إلى القناة على Telegram
Important announcements for anyone developing with Jupiter. Docs: https://dev.jup.ag/ Twitter/X: https://twitter.com/JupiterExchange Discord: https://discord.gg/jup
إظهار المزيدلم يتم تحديد البلدالتكنولوجيات والتطبيقات28 178
2 368
المشتركون
لا توجد بيانات24 ساعات
+17 أيام
+730 أيام
جاري تحميل البيانات...
القنوات المماثلة
لا توجد بيانات
هل تواجه مشاكل؟ يرجى تحديث الصفحة أو الاتصال بمدير الدعم الخاص بنا.
سحابة العلامات
الإشارات الواردة والصادرة
---
---
---
---
---
---
جذب المشتركين
يوليو '26
يوليو '26
+33
في 0 قنوات
يونيو '26
+39
في 0 قنوات
Get PRO
مايو '26
+46
في 0 قنوات
Get PRO
أبريل '26
+101
في 0 قنوات
Get PRO
مارس '26
+92
في 0 قنوات
Get PRO
فبراير '26
+123
في 0 قنوات
Get PRO
يناير '26
+130
في 0 قنوات
Get PRO
ديسمبر '25
+45
في 0 قنوات
Get PRO
نوفمبر '25
+59
في 0 قنوات
Get PRO
أكتوبر '25
+79
في 0 قنوات
Get PRO
سبتمبر '25
+97
في 0 قنوات
Get PRO
أغسطس '25
+120
في 0 قنوات
Get PRO
يوليو '25
+105
في 0 قنوات
Get PRO
يونيو '25
+93
في 0 قنوات
Get PRO
مايو '25
+109
في 0 قنوات
Get PRO
أبريل '25
+119
في 0 قنوات
Get PRO
مارس '25
+154
في 0 قنوات
Get PRO
فبراير '25
+270
في 0 قنوات
Get PRO
يناير '25
+334
في 0 قنوات
Get PRO
ديسمبر '24
+876
في 0 قنوات
| التاريخ | نمو المشتركين | الإشارات | القنوات | |
| 28 يوليو | 0 | |||
| 27 يوليو | +1 | |||
| 26 يوليو | +1 | |||
| 25 يوليو | 0 | |||
| 24 يوليو | +1 | |||
| 23 يوليو | 0 | |||
| 22 يوليو | +2 | |||
| 21 يوليو | +2 | |||
| 20 يوليو | 0 | |||
| 19 يوليو | +3 | |||
| 18 يوليو | 0 | |||
| 17 يوليو | +3 | |||
| 16 يوليو | 0 | |||
| 15 يوليو | +2 | |||
| 14 يوليو | 0 | |||
| 13 يوليو | 0 | |||
| 12 يوليو | 0 | |||
| 11 يوليو | +2 | |||
| 10 يوليو | +2 | |||
| 09 يوليو | +2 | |||
| 08 يوليو | +3 | |||
| 07 يوليو | +1 | |||
| 06 يوليو | +2 | |||
| 05 يوليو | +1 | |||
| 04 يوليو | 0 | |||
| 03 يوليو | 0 | |||
| 02 يوليو | +3 | |||
| 01 يوليو | +2 |
منشورات القناة
Suggested events endpoint deprecation
Hi all, heads up for teams using the Prediction Market API suggested events endpoint.
We are deprecating the wallet-specific suggested events endpoint on Friday, 10 July 2026:
GET https://api.jup.ag/prediction/v1/events/suggested/{walletAddress}
For suggested events, use the category-based endpoint instead:
GET https://api.jup.ag/prediction/v1/events/suggestedSupported query parameters:
provider, category, excludedEventId, and limit.
Update your integrations before 10 July 2026 to avoid relying on the deprecated wallet-specific suggestion flow.
If you're unsure how this affects your integration, reach out to @anmoldotsol and we'll help verify.| 2 | Final reminder on the Developer Platform migration (portal.jup.ag → developers.jup.ag)
The cutoff is 7th july 9am UTC. if you haven't claimed your legacy org and set up billing on the new platform yet, do it before then or your rate limits drop to free tier (1 RPS).
set up here: developers.jup.ag/portal
Reach out to @anmoldotsol / @Yankee0x for any questions | 790 |
| 3 | Update
The Content API deprecation is now in effect. Stated endpoints are no longer publicly accessible and will return a 403
If this broke an existing integration, reach out to @nineyoi and we'll help you sort it out. | 1 096 |
| 4 | JupiterZ integrator fees on Swap API
Hi all, quick update for teams using the /order path of the Swap V2 API
Integrator fees are now supported on JupiterZ/RFQ routes. You can pass referralAccount + referralFee like any other /order request and still receive JupiterZ/RFQ quotes when it is the best eligible route
Relevant docs:
- Changelog
- Referral fees setup/usage | 1 364 |
| 5 | Content API Deprecation Notice
Heads up, we are deprecating the beta Content API on 1 July 2026.
- /tokens/v2/content
- /content/feed
- /content/cooking
In the coming months, we will be sharing more about an update to the Tokens API, including a comprehensive replacement for the Content API.
If you currently rely on/or were planning to use the Content API, reach out to @9yointern. We'd love to hear your feedback and discuss how we can help. | 1 468 |
| 6 | Hi all, quick heads up for teams working with Jupiter's Prediction Markets API.
We're shipping the next step of the fractional contracts migration on Thursday, 4 June 2026 at 6:00 AM UTC (2:00 PM SGT, UTC+8). No downtime is expected.
What's happening
The previous migration on 27 May was step one. On-chain storage moved to micro-contracts and the new *Micro / *Decimal fields became available. This Thursday is step two: the keeper starts executing partial / fractional fills.
What this means for your integration
Legacy fields like contracts and filledContracts are floored to whole numbers, the fractional part is dropped. Until Thursday, fills are always whole numbers, so this has no effect. From Thursday onwards, fills can be fractional, and any integration reading these legacy fields will get the truncated value. The *Micro fields carry the exact amount.
Example (an order partially filled for 2.5 contracts):
filledContracts: "2" ← legacy, floored, do NOT use
filledContractsMicro: "2500000" ← exact, use this
filledContractsDecimal: "2.5" ← exact, for display
What you need to do before Thursday
1. Order creation: send contractsMicro instead of contracts. Send exactly one quantity field per order as providing multiple of contracts, contractsMicro, or contractsDecimal is rejected. The legacy contracts field still works for whole-contract orders but cannot express fractions.
2. Reading responses: switch any calculation or accounting logic from legacy fields to their *Micro siblings:
- contracts → contractsMicro
- filledContracts → filledContractsMicro
- contractsSettled → contractsSettledMicro
- newContracts → newContractsMicro
- totalContracts → totalContractsMicro
- totalActiveContracts → totalActiveContractsMicro
Use *Micro for math, *Decimal for display.
3. Number types: *Micro values are returned as strings (u64/u128) and can exceed JavaScript's safe-integer range. Parse with BigInt or a decimal library, never parseFloat or Number. Those will silently produce wrong values for large positions.
What's not changing
USD / price fields stay in micro-USD. depositAmount is unchanged, denominated in the deposit token's native decimals (e.g. 6 for USDC).
Legacy field handling
Legacy whole-contract fields will remain available for backwards compatibility, we won't be removing them anytime soon. There is no firm deprecation date. However, they will continue to return values floored to whole numbers, so you must migrate to the *Micro fields to read accurate data from Thursday onwards.
Full migration guide: https://gist.github.com/julianfssen/322fb55fc6f1eb575a60e7e350ebe822
If you're unsure how this affects your integration, reach out to @anmoldotsol and we'll help verify. | 1 359 |
| 7 | Prediction Markets API maintenance complete ✅
The fractional contracts migration is done. Trading, claims, and settlement have all resumed.
If you haven’t already, please migrate to the new contractsMicro / contractsDecimal fields within the next week, the legacy whole-contract fields (contracts, filledContracts, totalContracts) will be deprecated after that.
If you're facing any issues post maintenance, feel free to ping @anmoldotsol. | 1 040 |
| 8 | Hi all, quick heads up for teams integrating with Jupiter Prediction Markets API.
We’re shipping a coordinated migration to add fractional contracts support, scheduled for Wednesday, 27 May 2026 at 6:00 AM UTC (2:00 PM SGT, UTC+8).
Estimated downtime: up to ~4 hours (may complete earlier if everything goes smoothly).
What’s changing
Contract quantities are migrating from whole-contract units to micro-contract units, enabling fractional positions.
Example:
- Before: 5
- After: 5000000 micro-contracts (= 5 contracts)
This enables positions such as 5.777773 contracts, partial fills with exact fractional accounting, and better compatibility with external liquidity venues.
Order sizing precision: Effective fill sizes will be floored to 0.01-contract increments on the keeper to stay aligned with external venue precision. You can submit finer-grained sizes, but executed amounts will round down to the nearest 0.01.
Compatibility (non-breaking at deploy time)
Existing legacy fields will continue to work for backwards compatibility:
- contracts
- filledContracts
- totalContracts
New exact fields will be added:
- contractsMicro
- contractsDecimal
USD fields remain unchanged (still micro-USD). Orderbook sizes will be returned as decimal strings.
During the migration window
- Trading and order creation will be paused
- Claims and settlement will be paused
- Read APIs may be temporarily stale or inconsistent
- Integrators generally do not need to make changes to keep working after the migration
Recommended action
Legacy whole-contract fields will be deprecated roughly one week after the migration. Within that week, please migrate to the new exact-quantity fields:
- Use *Micro fields for calculations and order creation
- Use *Decimal fields for UI display
- Treat legacy whole-contract fields as compatibility-only
We’ll post another reminder closer to the maintenance window and confirm once the migration is complete. If you’re unsure how this affects your integration, reach out to @anmoldotsol and we’ll help verify. | 980 |
| 9 | 🛠 Metis V8 is live
Focused on closing Quotation–Execution Drift, the gap between the price you're quoted and what actually lands.
• Route splits finalized onchain at execution, instead of ~400ms before
• Sub-2 slot state freshness on every routing decision (gRPC streaming + own validator shreds)
• Landing via Beam, direct to validator leaders, p95 0–1 slots
• Rapid Quotation: <100ms quotes that skip marginal optimization, better shot at landing in the next slot when speed beats bps
Docs: https://developers.jup.ag/docs/swap
Run your own: https://github.com/jup-ag/metis-binary/releases/tag/v7.0.13
Read more: https://x.com/JupiterExchange/status/2057037276295864734 | 1 306 |
| 10 | Hi everyone, we apologize for a brief outage that caused intermittent transaction submission and landing issues across Jupiter Spot products and APIs, including Swap, Limit Order, and DCA.
The issue appears related to DNS resolution affecting our transaction landing infrastructure. We deployed a hotfix around 30 minutes ago, and services appear to have recovered. We’re continuing to monitor and investigate the root cause, and we’ll share an incident report once complete. | 1 285 |
| 11 | Hi all, quick heads up for teams using Trigger API V2.
We’re shipping a breaking request validation change for price-order deposits on Thursday, May 14, 2026 at 4:00 AM UTC.
If your integration calls:
POST https://api.jup.ag/trigger/v2/deposit/craft
please make sure you send both of these fields in the request body:
{
"orderType": "price",
"orderSubType": "single"
}
Set orderSubType based on the order:
1. single = standalone price order
2. oco = OCO / take-profit-stop-loss order
3. otoco = OTOCO / conditional chain order
No change is needed for:
POST https://api.jup.ag/trigger/v2/orders/price
Keep using the deposit requestId returned by /deposit/craft when creating the order.
After the change is live, /deposit/craft requests missing orderType or orderSubType will return a 4xx.
Docs:
https://developers.jup.ag/docs/trigger/create-order
Please update/check your integration before the change goes live. If you’re unsure which orderSubType maps to your flow, reach out to @anmoldotsol and we’ll help verify. | 1 315 |
| 12 | Pump.fun gasless swaps temporarily disabled
If you sponsor gas on Pump.fun swaps (anyone other than the end user as fee payer), quotes have been returning errors since April 27. We disabled the path while patching a rent reclaim vulnerability that was draining payer wallets of SOL. Hotfix went live immediately. Program upgrade for the proper fix is in progress; we'll post here when it ships.
Two safeguards worth implementing going forward:
1. Only proceed with quotes where rentFeeLamports can be recouped through fees or otherwise
2. Reject quotes where rentFeeLamports is abnormally high
Heads up: we also fixed the rentFeeLamports calculation itself. It previously missed rent from inner instructions and is now accurate via full transaction simulation.
Apologies for the late notice on this. We're working on a better process for incidents going forward. | 1 429 |
