Cette page a été traduite automatiquement. La version anglaise fait référence. Lire en anglais →
Aller au contenu principal

Journal des modifications

Modifications et dépréciations de l'API pour le testnet et l'alpha du réseau principal de Hypercall.

Politique de modification de l'API expérimentale​

Tous les endpoints /experimental et les messages WebSocket explicitement expérimentaux sont instables. Des modifications incompatibles peuvent prendre effet avec un jour (24 heures) de préavis. Cela inclut la suppression ou le renommage de champs ou d'endpoints, la modification des types de champs et la modification du comportement des requêtes ou des réponses. Les avis publiés dans ce journal des modifications indiqueront les surfaces concernées, les modifications requises côté client ainsi que la date et l'heure d'entrée en vigueur. Les clients doivent suivre ces avis et se mettre à jour avant cette échéance. Cette politique ne modifie pas les engagements de compatibilité des endpoints et abonnements non expérimentaux.

Consultez l'API expérimentale de combos pour l'interface actuelle. Cette politique n'annonce ni une disponibilité ni une modification immédiate du schéma.

Voir aussi : Référence de l'API REST · API WebSocket · Authentification

Pas de nouvelle version - 6 octobre 2026​

Ajouts​

  • Politique de marge PM publique : GET /v1/pm-margin/policy renvoie la politique de marge de portefeuille active (type, version, mode de surcouche gamma et l'univers complet par sous-jacent) sans authentification. La réponse comporte un ETag fort et Cache-Control: public, max-age=60, stale-while-revalidate=300 ; envoyez If-None-Match pour obtenir une réponse 304 Not Modified sans corps tant que la politique n'a pas changé. Voir Paramètres de risque PM.
  • Compression WebSocket en production : la négociation permessage-deflate décrite au 30 septembre est désormais activée dans la configuration de production. Les clients qui ne proposent pas l'extension ne sont pas concernés.

Pas de nouvelle version - 5 octobre 2026​

Ajouts​

  • Aucune modification des limites de débit ni des niveaux n'a été livrée au cours de cette période ; les limites de débit sont inchangées, et les nouvelles soumissions de perpétuels TEE sont décomptées sur le gestionnaire du compte comme les autres soumissions d'ordres sur perpétuels. Aucun endpoint n'a été déprécié.
  • Routes de déclenchement et de lot pour les perpétuels TEE : POST /v1/tee-perp/orders/submit-trigger soumet un stop-loss ou un take-profit natif, et POST /v1/tee-perp/orders/submit-batch soumet un ordre groupé (na, normalTpsl ou positionTpsl). Les deux utilisent la même signature EIP-712 par clé d'application que POST /v1/tee-perp/orders/submit, passent le même contrôle de marge de portefeuille et portent toujours le code builder Hypercall.
  • Aperçu des perpétuels TEE : POST /v1/tee-perp/preview exécute le contrôle de marge pour un ordre, un lot ou un changement de levier sans écrire dans le journal, sans réserver de nonces ni appeler l'enclave, et renvoie la décision, un reasonCode stable, les montants de marge, les prix de liquidation de la plateforme et un maxSize obtenu par dichotomie. Les réponses de soumission d'ordre, de lot et de levier portent désormais le même reasonCode. Voir les codes de motif.
  • Marchés de perpétuels TEE : GET /v1/tee-perp/markets liste les marchés de perpétuels acceptés par Hypercall et leurs indices d'actifs. Tout marché disposant d'un flux de prix Hypercall, d'une grille de scénarios PM et d'un marché Hyperliquid margé en USDC est accepté sur toutes les routes TEE. Tout autre marché est refusé avec market_not_supported.
  • Rappel sur les routes : les routes TEE sont facultatives au niveau de l'API : les clients API les choisissent en appelant les endpoints /v1/tee-perp/, et les ordres qui ne les utilisent pas passent par le chemin des directives du contrat de compte. Dans l'application Hypercall, TEE est la route par défaut pour les perpétuels, la route par smart contract restant disponible comme paramètre avancé dans les Réglages.

Modifications​

  • Les identifiants de requête choisis par le client doivent être des UUIDv7 récents. POST /v1/tee-perp/cancels/submit-prepared (à la fois nonceReservationRequestId et requestId) et POST /liquidation/standard-margin (request_id) renvoient 400 lorsque l'identifiant de requête n'est pas un UUIDv7 (par exemple un v4 issu de crypto.randomUUID()), lorsque son horodatage intégré date de plus d'une heure, ou lorsqu'il se situe plus de 30 secondes dans le futur. Générez un nouvel UUIDv7 pour chaque nouvelle requête et ne le réutilisez que pour relancer cette même requête dans l'heure.
  • Les nouvelles tentatives d'ordres, d'annulations et de levier TEE à travers cette version sont rejetées. Les identités attribuées par le serveur pour POST /v1/tee-perp/orders/submit, POST /v1/tee-perp/cancels/submit, POST /v1/tee-perp/cancels/submit-by-oid, POST /v1/tee-perp/schedule-cancel/submit et POST /v1/tee-perp/leverage/submit ont changé dans cette version. Relancer une requête envoyée pour la première fois avant la mise à jour renvoie 400 pour un nonce réutilisé au lieu de l'acceptation d'origine ; la requête d'origine reste valable. Signez et envoyez une nouvelle requête avec un nouveau nonce.
  • La précision des tailles des jambes RFQ est vérifiée à la soumission : une taille de jambe RFQ comportant plus de 6 décimales (plus fine que 0.000001) est rejetée lors de la soumission de la RFQ, et l'erreur indique la plus grande taille exécutable à laquelle arrondir vers le bas. Auparavant, la RFQ était acceptée puis chaque cotation de teneur de marché échouait, de sorte que les preneurs voyaient un délai d'expiration générique sans cotation. Le hash des jambes signées est inchangé : arrondissez vous-même la taille avant de signer.

Pas de nouvelle version - 4 octobre 2026​

Ajouts​

  • Levier des perpétuels TEE : POST /v1/tee-perp/leverage/submit modifie le levier par marché et le mode croisé ou isolé via la route TEE, en appliquant la même règle de marge que pour l'admission des ordres. Un changement refusé renvoie un reasonCode stable tel que insufficient_margin ou leverage_requires_flat_account.

Pas de nouvelle version - 2 octobre 2026​

Ajouts​

  • Routes d'annulation et d'annulation programmée des perpétuels TEE : POST /v1/tee-perp/cancels/submit (par identifiant d'ordre client), POST /v1/tee-perp/cancels/submit-by-oid et POST /v1/tee-perp/schedule-cancel/submit (dispositif de l'homme mort) sont disponibles sur la route TEE.

Pas de nouvelle version - 30 septembre 2026​

Ajouts​

  • Compression WebSocket : /ws prend en charge permessage-deflate (RFC 7692) avec server_no_context_takeover, activé selon l'environnement. Les clients qui proposent l'extension reçoivent les messages volumineux sous forme compressée ; les autres ne sont pas affectés. Voir Compression.
  • Données de marché indicatives par lots : le nouveau canal indicative_market_data_v2 transmet les lignes de indicative_market_data sous forme de trames IndicativeMarketDataBatch, chacune contenant les lignes publiées pendant une fenêtre de lot (25 ms par défaut), dans l'ordre et sans agrégation. Sa confirmation est {"type":"Subscribed","channel":"indicative_market_data_v2","batch":true} ; en l'absence de ce marqueur, repliez-vous sur indicative_market_data, qui reste inchangé. Les lignes arrivent avec au plus une fenêtre de retard. Avec permessage-deflate, les trames par lots sont environ cinq fois plus petites que des lignes compressées une à une. Voir Livraison par lots. Le champ d'abonnement éphémère "batch": true est supprimé ; les serveurs l'ignorent.
  • Les canaux inconnus sont rejetés : un Subscribe vers un canal inexistant renvoie désormais {"type":"Error","code":"unknown_channel","channel":"<name>","message":"Unknown channel '<name>'"} au lieu d'une confirmation Subscribed suivie d'un silence. Les messages Error gagnent les champs optionnels code et channel. Les canaux retirés conservent leur erreur existante.
  • Client Rust : WsClient::subscribe_indicative_market_data(symbols) s'abonne à indicative_market_data_v2 et se replie sur indicative_market_data lorsque le serveur confirme sans le marqueur de lot ou rejette le canal. Désactivez ce comportement avec WsClient::with_batched_indicative(false), et arrêtez l'abonnement avec WsClient::unsubscribe_indicative_market_data(), qui fonctionne quel que soit le canal retenu. Changement incompatible (pré-1.0) : l'argument batch de la méthode est supprimé, WsMessage::Subscribe perd son champ batch, et WsMessage::Subscribed et WsMessage::Error gagnent des champs optionnels ; les littéraux de structure et les filtrages exhaustifs doivent donc être mis à jour.

Modifications​

  • Changement incompatible : la marge de portefeuille exige un compte HyperCore unifié. POST /margin-mode avec portfolio échoue désormais avec un 400 et le code pm_account_not_unified, sauf si HyperCore indique que l'Account est en mode unifiedAccount. Activez-le d'abord avec la directive hl_set_abstraction, attendez la confirmation, puis réessayez. Un Account PM non unifié ne pouvait jamais être valorisé ; cette vérification remplace donc un échec ultérieur et opaque.
  • GET /portfolio explique l'absence de flux d'equity PM. Lorsqu'un Account en marge de portefeuille n'a pas d'equity HyperCore à jour, la réponse est 409 pm_account_not_unified si HyperCore n'a jamais publié l'Account et indique un autre mode, ou un 503 pm_account_equity_pending pouvant être retenté jusqu'à ce qu'un instantané unifié à jour parvienne au moteur (en nommant le mode HyperCore lorsqu'il n'est pas unifié). Les autres échecs de valorisation PM conservent le 503 générique.
  • Le contrôle préalable des makers RFQ distingue les échecs de valorisation. Une cotation que la plateforme ne peut pas valoriser (par exemple, en l'absence de surface de volatilité implicite) est désormais rejetée avec le motif pricing_unavailable au lieu de margin_rejected. margin_rejected désigne désormais uniquement une décision de marge sur le compte du maker.

Pas de nouvelle version - 2 septembre 2026​

Ajouts​

  • Simulation de risque publique : POST /risk/simulate/portfolio prévisualise des superpositions ou des remplacements de positions valorisés au prix de marque. POST /risk/simulate/orders prévisualise l'admission financière d'ordres en attente ou atomiques. Les deux endpoints utilisent un seul instantané immuable du moteur, prennent en charge la marge standard et la marge de portefeuille, ne nécessitent aucune authentification et ne modifient jamais l'état du compte ni le journal. Les prévisualisations d'ordres excluent les garanties de routage, d'appariement, de nonce et de suspension de la négociation ; un ordre réel ultérieur peut donc différer une fois que l'état du moteur a évolué.
  • Bases d'ordres ouverts ordonnées : POST /risk/simulate/orders accepte le paramètre optionnel hypothetical_open_orders, les admet séquentiellement comme ordres GTC en attente et indique leur effet combiné avec l'ordre ou le package atomique proposé.

Migration des options en marge standard​

Périmètre : la marge standard reconnaît les spreads d'options compatibles, les butterflies et d'autres portefeuilles au sein de chaque sous-jacent et de chaque échéance. Les calendars conservent des groupes d'échéance distincts. Le financement en USDC et les routes d'ordres existantes restent inchangés.

Contrat de trésorerie additif : les résumés de portefeuille REST et WebSocket ajoutent standard_margin, qui contient cash_margin, initial_margin_headroom, maintenance_margin_headroom ainsi que des diagnostics sur les échéances compatibles. Les champs existants initial_margin et maintenance_margin conservent leur signification historique dérivée de la NAV. Utilisez les champs explicites de marge disponible en trésorerie pour l'admission et la liquidation en SM. Une ventilation manquante signifie que la fonctionnalité est indisponible, et non que le risque est nul.

Sémantique des positions (changement incompatible) : margin_posted et la maintenance_margin par position sont des diagnostics autonomes, calculés avant la protection de groupe. Ne les additionnez pas pour obtenir les exigences du compte ni pour estimer le coût de clôture d'une jambe. Utilisez les exigences du compte et la ventilation par groupe.

Champ nullable (changement incompatible) : les positions d'options en SM renvoient désormais liquidation_price: null dans les messages de portefeuille REST et WebSocket. Mettez à jour les décodeurs qui exigent une chaîne décimale et affichez un prix indisponible ou la marge disponible du compte. Renvoyer l'ancien prix donnerait une image erronée du risque de liquidation groupé. Ce changement nécessite une bascule coordonnée backend/client ; il ne prétend pas être compatible avec les anciens décodeurs stricts.

Migration des clients : mettez à jour le frontend et les consommateurs de risque automatisés avant de reprendre la négociation sur le nouveau backend. Annulez les anciennes cotations du maker et confirmez leur suppression, puis arrêtez l'ancien maker. Ne démarrez le maker mis à jour qu'une fois la nouvelle ventilation de trésorerie disponible. Les nouvelles versions du maker cessent de coter lorsque ce contexte est absent ; les anciennes versions utilisent la NAV pour le taux d'utilisation et ne conviennent pas aux nouvelles règles de risque fondées sur la trésorerie. N'exécutez pas de versions mixtes du backend pour les mêmes comptes de trading.

Bibliothèques Rust : les prix de liquidation des positions du portefeuille deviennent optionnels et les résumés de marge ajoutent un champ public de ventilation, ce qui impose de mettre à jour les littéraux de structure correspondants. Les signatures des fonctions utilitaires de marge dérivées de la NAV restent inchangées ; les consommateurs de risque tenant compte de la trésorerie doivent utiliser le contrat SM explicite. La bibliothèque de liquidation exige également une marge disponible maintenance_margin faisant autorité dans les instantanés de marge sérialisés et les candidats construits. Reconstruisez ces instantanés à partir de lectures à jour ; ne déduisez pas une marge disponible en trésorerie manquante à partir d'une NAV sauvegardée.

Validation : les consommateurs internes distinguent la PM de la SM, l'indisponibilité du contexte de trésorerie interrompt les décisions de risque automatisées, et les formats de requête et de signature des ordres restent inchangés. Cette entrée non publiée n'atteste ni d'un déploiement ni d'un déploiement à versions mixtes pris en charge.

Pas de nouvelle version - 15 août 2026​

Ajouts​

  • Volume par actif de la collection : GET /accounts/{wallet}/collection renvoie désormais, pour chaque actif, le notionnel canonique exact cumulé du sous-jacent sur toute sa durée de vie, sous forme de chaîne décimale, dans le champ additif assets[].volume.

Aucune nouvelle version - 14 août 2026​

Avis de dépréciation​

  • Champ de nom d'utilisateur du profil déprécié : le champ username de la réponse Rust GET /profile est déprécié et pourra être supprimé à partir du 7 septembre 2026. Lisez plutôt les noms d'utilisateur choisis via GET /username?wallet=... sur l'API Analytics. Si cet endpoint renvoie 404, dérivez adjective_noun.xx localement à partir du portefeuille canonique. Pendant la période de migration, les réponses /profile réussies incluent désormais les en-têtes Deprecation, Sunset, X-Deprecation-Removal-Unix et Warning.
  • Champs de nom d'utilisateur hérités restants : le champ username des réponses Rust héritées GET /username et POST /username, ainsi que des réponses de classement des compétitions, reste susceptible d'être supprimé selon le calendrier du 20 août 2026. Le contrat GET /username et POST /username signé de l'API Analytics remplace la gestion des noms d'utilisateur choisis. Les clients de classement doivent dériver localement les noms d'affichage adjective_noun.xx à partir du wallet ou du wallet_address canonique lorsqu'aucun nom choisi n'est disponible. L'algorithme déterministe de nom de compte ci-dessous est normatif.

Algorithme déterministe de nom de compte​

Entrée : supprimez les espaces et convertissez en minuscules une adresse de portefeuille EVM canonique. La valeur doit correspondre à ^0x[0-9a-f]{40}$. Une entrée invalide produit Unknown.

Listes de mots ordonnées : conservez exactement cet ordre.

adjectives = [swift, silent, long, short, deep, wide, sharp, calm, cold, quiet, bold, thin, idle, vivid, grim, amber, slate, rapid, steady, hollow, rogue, plain, lucky, brisk, stark]
nouns = [theta, vega, gamma, delta, rho, basis, carry, skew, strike, tenor, vol, wick, candle, ladder, condor, collar, straddle, strangle, butterfly, spread, hedge, premium, tick, lot]

Fonction de hachage : utilisez FNV-1a 32 bits sur les octets ASCII. Chaque multiplication boucle sur un entier non signé de 32 bits, ce qui équivaut à Math.imul(hash, 0x01000193) >>> 0 en JavaScript.

fnv1a32(value, seed = 0x811c9dc5):
  hash = uint32(seed)
  for byte in ascii(value):
    hash = uint32(hash XOR byte)
    hash = uint32(hash * 0x01000193)
  return hash

wallet = trim(input).lowercase()
adjective_hash = fnv1a32(wallet)
noun_hash = fnv1a32(wallet + "#2", adjective_hash)
adjective = adjectives[adjective_hash modulo 25]
noun = nouns[noun_hash modulo 24]
suffix = last 2 characters of wallet
display_name = adjective + "_" + noun + "." + suffix

Vecteurs de test :

PortefeuilleNom d'affichage
0x000000000000000000000000000000000000002avivid_candle.2a
0xd9fe4c6bf4271fd685409cd01b7eece052c886c8silent_theta.c8

Ajouts​

  • API publique des badges : le Worker analytics sert désormais le registre des badges sur GET /badges, les détenteurs paginés sur GET /badges/{slug}, l'état par compte sur GET /badges/accounts/{wallet} et des lots compatibles avec la mise en cache, jusqu'à 100 portefeuilles, sur GET /badges/accounts?wallet=.... Le podium et le volume historique utilisent les générations matérialisées du classement. L'éligibilité Founding est figée aux comptes vus pour la première fois avant le 1er août 2026 UTC. Le nombre de messages Trollbox liés à un portefeuille est actualisé toutes les heures, et les paliers obtenus sont conservés après la suppression d'un message.
  • Succès de série et de collection du profil : GET /accounts/{wallet}/streak?days=14|61|365 renvoie le calendrier de série. GET /accounts/{wallet}/collection renvoie la grille indépendante des actifs de la collection, sans paramètre de fenêtre temporelle. La série compte les jours UTC consécutifs comportant une exécution éligible. La collection compte les sous-jacents distincts négociés et les compare au catalogue actuellement listé. Les auto-appariements résolus ne sont pas comptabilisés. Une collection Complete reste acquise si le catalogue s'agrandit par la suite.
  • Noms Hyperliquid dans les lignes du classement : les lignes data[] renvoyées par les endpoints de classement des compétitions et de classement historique incluent désormais le champ nullable hyperliquid_name. Le Worker analytics ne résout les noms que pour les portefeuilles de la page renvoyée, regroupe les appels HyperEVM et met en cache les résultats positifs et négatifs pendant dix minutes. Ce champ est distinct du username généré déprécié. Les clients peuvent le privilégier lorsqu'il n'est pas nul et utiliser sinon le nom de compte déterministe.

Aucune nouvelle version - 3 août 2026​

Changements incompatibles​

  • Images de profil supprimées de l'API Rust : POST /profile/image n'est plus disponible, et GET /profile ne renvoie plus profile_image_url.

Aucune nouvelle version - 29 juillet 2026​

Changements incompatibles​

  • Endpoint REST des chandeliers supprimé : GET /candles n'est plus disponible et renvoie désormais 404. Les clients doivent cesser d'appeler cet endpoint.
  • Diffusion WebSocket des chandeliers retirée : Hypercall ne publie plus de messages CandleUpdate sur les canaux candles:<UNDERLYING>:<RESOLUTION>. Les clients doivent cesser de s'abonner à ces canaux. Aucun flux de chandeliers de remplacement n'est disponible dans cette version.

Aucune nouvelle version - 27 juillet 2026​

Ajouts​

  • Heure de publication indicative : chaque payload WebSocket indicative_market_data inclut désormais published_at, l'horodatage en millisecondes de l'horloge de l'API au moment de l'envoi de ce payload. Utilisez published_at - rfq_provider_quotes[].updated_at pour mesurer l'âge de la cotation du fournisseur au moment de la publication. Ne comparez aucune de ces valeurs à l'horloge murale du client. Le champ timestamp existant reste l'heure de mise à jour de l'agrégat source.
  • Horloge de transport WebSocket : les clients qui ont besoin d'une durée prudente entre publication et réception peuvent envoyer {"type":"ClockSync","nonce":"<client nonce>"} et attendre {"type":"ClockSynced","nonce":"<same nonce>","server_at":<API milliseconds>} avant de s'abonner. Combinez l'échantillon de l'API avec le temps écoulé monotone côté client. Ne comparez pas server_at à l'horloge murale du client.

Aucune nouvelle version - 22 juillet 2026​

Ajouts​

  • Sens de la transaction dans l'historique public : chaque transaction renvoyée par GET /trades inclut désormais taker_side, avec la valeur Buy ou Sell. Le côté maker est toujours l'opposé.
  • Pagination par curseur pour les transactions : passez after_trade_id à GET /trades pour récupérer les transactions plus récentes dans l'ordre croissant de trade_id. Poursuivez à partir du dernier ID renvoyé. Le mode curseur ne peut pas être combiné avec offset, option_id, underlying ou account ; les requêtes existantes par offset et filtrées restent inchangées.

Aucune nouvelle version - 20 juillet 2026​

Changements incompatibles​

  • Les consommateurs WebSocket lents sont déconnectés : les connexions /ws sont interrompues dès qu'un plafond de sécurité par connexion est franchi. Les plafonds appliqués sont de 16 384 messages en attente, 8 MiB de données encodées en attente, 5 secondes d'ancienneté de file d'attente et 5 secondes pour une écriture sur le socket. Il s'agit de plafonds de sécurité opérationnels, et non de garanties de débit ni d'engagements de compatibilité. Un dépassement de file, d'octets ou d'ancienneté envoie le code de fermeture 1008 avec une raison JSON compacte contenant error: "slow_consumer", class, cause et recovery. Une connexion incapable d'accepter même la trame de fermeture peut être interrompue sans raison lisible. Aucun curseur de rejeu n'est encore disponible. Les clients doivent se reconnecter, s'authentifier à nouveau si nécessaire, se réabonner et suivre l'action de récupération : récupérer un nouveau snapshot pour les données publiques ordonnées, rapprocher les événements privés durables via REST, ou récupérer à nouveau l'état du portefeuille. Les clients ne doivent pas supposer une livraison ininterrompue au travers d'une reconnexion. La route d'entrée des fournisseurs de cotations /ws/quotes est distincte et reste inchangée.
  • Les rafraîchissements indicatifs inchangés sont regroupés : indicative_market_data n'émet plus chaque rafraîchissement de cotation ne portant que sur l'horodatage. Lorsque les prix, tailles et disponibilités du fournisseur sont inchangés, chaque instrument émet au plus une mise à jour de fraîcheur par seconde. Les variations financières de prix ou de taille et les retraits de fournisseur sont toujours publiés immédiatement. Les clients qui traitaient chaque horodatage source comme un événement doivent désormais utiliser le dernier snapshot reçu.
  • Les commandes WebSocket partagent les limites de débit REST au sein d'un même processus API : les commandes signées /ws PlaceOrder, SubmitRfq, SubmitAutoExecuteRfq et AcceptRfqQuote utilisent désormais le même RateLimitCache en mémoire par portefeuille que leurs équivalents REST dans ce processus API. Les limites ne s'appliquent pas à l'échelle du cluster, et chaque réplique de l'API maintient ses propres fenêtres indépendantes. Le portefeuille n'est comptabilisé qu'après la récupération de la signature et l'autorisation de l'agent, de sorte que désigner un autre portefeuille ne peut pas consommer sa limite. Un pod dédié à la diffusion WebSocket ne contourne pas ces limites. Les commandes WebSocket dépassant la limite renvoient un message Error au lieu des en-têtes HTTP de limitation de débit.

Corrections​

  • Contre-pression mémoire WebSocket : le chemin propriétaire du socket conserve désormais la comptabilité de la file depuis l'admission jusqu'à l'écriture complète sur le socket. Il enregistre les octets encodés, l'ancienneté de la file, le temps de sérialisation, les octets effectifs des trames, la latence entre publication et écriture, les échecs d'écriture et les fermetures pour pression, par classe de livraison.
  • Bande passante indicative en double : les snapshots indicatifs répétés de la chaîne complète dont les champs financiers sont inchangés sont supprimés avant la diffusion publique.

Aucune nouvelle version - 13 juillet 2026​

Ajouts​

  • Codes d'erreur de l'API : les réponses d'erreur JSON HTTP 4xx et 5xx générées par l'API ajoutent code et message tout en conservant les champs existants. Basez votre logique sur le code stable et lisible par machine, et utilisez message pour l'affichage ou le diagnostic. Voir Erreurs et motifs de rejet.

Aucune nouvelle version - 3 juillet 2026​

Ajouts​

  • Visibilité des cotations des fournisseurs RFQ : GET /options-summary peut inclure les cotations indicatives brutes des fournisseurs de cotations RFQ en passant include_rfq_provider_quotes=true ou l'alias rétrocompatible rfq_provider_quotes=true. Limitez le nombre de cotations de fournisseurs par instrument avec rfq_provider_quotes_limit, provider_quotes_limit ou limit.
  • Flux de données de marché indicatives : les messages WebSocket IndicativeMarketData incluent désormais rfq_provider_quotes, afin que les clients puissent examiner l'ensemble des cotations indicatives RFQ par fournisseur à l'origine du bid et de l'ask agrégés.

Corrections​

  • Paramètres de requête de l'options summary : la référence de l'API REST documente désormais les nouveaux paramètres de requête de cotations fournisseurs de /options-summary.
  • Cotations fournisseurs indisponibles : les cotations des fournisseurs RFQ qui ne sont plus disponibles disparaissent rapidement des réponses de données de marché.

Aucune nouvelle version - 26 juin 2026​

Avis de dépréciation​

  • Route d'ordre omise : PlaceOrder accepte l'omission de route au moins jusqu'au 4 juillet 2026. POST /order traite l'omission de route comme best_execution et renvoie les en-têtes Deprecation, Sunset, X-Deprecation-Removal-Unix et Warning. Les clients doivent envoyer route et l'inclure dans les données typées de PlaceOrder. route ne deviendra pas obligatoire avant le 4 juillet 2026, mais pourra le devenir ultérieurement.

Ajouts​

  • Route d'ordre facultative : POST /order accepte désormais un champ signé facultatif route sur PlaceOrder. Les clients peuvent envoyer best_execution, book_only ou rfq_only. En l'absence de route, le comportement actuel best_execution s'applique par défaut pendant la période de dépréciation prévue.
  • Route d'ordre carnet uniquement : les clients peuvent envoyer route=book_only pour ignorer la recherche RPI/RFQ et transmettre directement l'ordre au carnet d'ordres. route=best_execution conserve le comportement existant RPI puis carnet. route=rfq_only est réservée et actuellement rejetée pour /order tant que la sémantique de l'historique des ordres RFQ uniquement n'est pas implémentée.
  • Validation de la route des ordres groupés : POST /bulk_order prend en charge route=book_only pour les requêtes tenant compte de la route. En l'absence de route, le comportement existant carnet uniquement est conservé. route=best_execution et route=rfq_only sont rejetées sur l'endpoint groupé, car celui-ci n'exécute pas le routage RPI/RFQ.

Aucune nouvelle version - 25 juin 2026​

Corrections de la documentation​

Aucune nouvelle version - 10 juin 2026​

Corrections de la documentation​

  • URL de base de la référence de l'API : correction de la référence de l'API REST générée afin d'indiquer les environnements publics https://testnet-api.hypercall.xyz pour le testnet et https://api.hypercall.xyz pour la production.

Aucune nouvelle version - 10 juin 2026​

Corrections​

Exécution​

  • Exécutions RPI sur carnet vide : le RPI à jambe unique traite désormais la limite de l'utilisateur comme plafond ou plancher d'exécution lorsqu'il n'existe aucune liquidité exécutable au repos dans le carnet. Les réponses d'amélioration de prix éligibles à la limite affichée peuvent être exécutées au lieu d'être rejetées pour ne pas améliorer la limite elle-même. S'il existe une liquidité exécutable au repos dans le carnet, les fournisseurs de cotations doivent toujours améliorer ce prix du carnet d'au moins un tick. Voir Priorité des ordres.
  • Réponses des fournisseurs de cotations : les réponses RFQ suivent désormais la même règle de prix limite que l'API. Les cotations naturelles à la limite du preneur sont acceptées lorsqu'aucune référence de carnet n'existe, tandis que les cotations en dehors de la limite du preneur ou celles qui n'améliorent pas la liquidité exécutable du carnet sont toujours refusées.

Trollbox​

  • Routage réseau principal : la Trollbox de production pointe désormais vers le worker du réseau principal, de sorte que le chat de l'application utilise l'environnement Trollbox en production.

Pas de nouvelle version - 1er juin 2026​

Voir aussi : Article de lancement du réseau principal

Changements incompatibles​

  • Environnement du réseau principal : les clients de production doivent utiliser l'application, l'API, les identifiants de chaîne, les adresses de contrat et le domaine de signature configurés pour le réseau principal. Ne réutilisez pas sur le réseau principal les signatures testnet, les clés API testnet, les clés d'agent testnet ni les hypothèses liées au faucet.
  • Périmètre de trading au lancement : l'alpha du réseau principal est limitée aux flux d'options à risque défini. Les positions courtes nues, la marge de portefeuille étendue, le financement par faucet et les parcours de compétition testnet ne sont pas activés pour les utilisateurs publics du réseau principal.
  • Route faucet bloquée dans les builds en argent réel : les parcours de financement propres au faucet ne sont pas disponibles dans les builds de production. Les utilisateurs du réseau principal se financent en USDC via le flux de financement de l'application.

Ajouts​

Réseau principal​

  • Alpha du réseau principal : Hypercall est en ligne sur app.hypercall.xyz avec un règlement en USDC réels et les options SPCX comme marché de lancement.
  • Marché de lancement SPCX : les options SpaceX sont disponibles sur le réseau principal avec des calls, des puts, des straddles, des strangles et des spreads à risque défini. Les contrats SPCX du réseau principal arrivent à échéance à 16 h 00 ET. Le marché utilise le même modèle de routage des ordres que celui documenté dans Priorité des ordres.
  • Configuration de chaîne du réseau principal : la connexion du portefeuille, la signature des ordres d'options, les adresses de contrat et les textes d'interface propres à chaque environnement dérivent désormais de la configuration réseau principal/testnet active, au lieu d'hypothèses testnet codées en dur.
  • Garde-fous de trading en production : la configuration de lancement maintient le trading actif tout en conservant des paramètres de risque contrôlés pour le déploiement de l'alpha.
  • API de production : l'API publique de production est disponible pour les clients du réseau principal.

Financement​

  • Dépôts en USDC : les utilisateurs peuvent déposer des USDC sur un compte Hypercall via l'application. Le flux affiche la route, la chaîne source, l'état du relais, le compte de destination et le montant crédité avant et après la soumission.
  • Attribution des dépôts sur l'Exchange : les événements de dépôt USDC de l'Exchange incluent explicitement le compte crédité, afin que les services backend créditent le compte Hypercall visé au lieu de déduire la propriété à partir de msg.sender. Voir Contrats : Onboarding.
  • Zaps de dépôt : le frontend prend en charge les flux de bridge et dépôt via l'application, y compris le suivi des cotations et de l'état du relais.
  • Retraits : la prise en charge des retraits sur le réseau principal passe par les actions système et apparaît dans les actions de financement du compte.
  • Sélection de la route de dépôt : les actions de dépôt choisissent la route active à partir de la configuration des contrats, ce qui permet à une même interface de suivre les parcours de financement propres à chaque environnement.
  • Acceptation des conditions juridiques : les flux de création de compte et de financement incluent l'acceptation des conditions juridiques du lancement, avec les Conditions d'utilisation et la Politique de confidentialité publiées.

Exécution​

  • RPI pour les ordres à une jambe : les options à une jambe passent par l'enchère Retail Price Improvement lorsqu'elles y sont éligibles, puis se replient sur le carnet d'ordres lorsqu'aucune cotation éligible ne l'emporte.
  • RFQ pour les packages multi-jambes : les packages de stratégies multi-jambes passent par le RFQ pour une exécution en tout-ou-rien. Les ordres bimodes en production privilégient le RFQ lorsque l'exécution en package est requise.
  • Frais de lancement : les frais maker et taker sont désactivés dans la configuration de lancement. Voir Frais.
  • Routage des ordres combinés : les ordres combinés passent par les chemins RPI/RFQ du backend plutôt que par des hypothèses de package propres au frontend.
  • Positions courtes des fournisseurs de cotations : les fournisseurs de cotations enregistrés peuvent exécuter les jambes courtes requises pour la liquidité RFQ/RPI, tandis que le périmètre public du lancement reste restreint.

Corrections​

  • Accès à la page de dépôt : les routes de financement tierces de l'hôte applicatif et le comportement de la fenêtre modale de dépôt ont été débloqués pour le flux de financement en production.
  • Suppression de la liste d'autorisation des dépôts : le filtrage par liste blanche des dépôts en production a été désactivé pour l'accès au financement au lancement.
  • Dimensionnement RFQ : les tailles RFQ en mode coût sont arrondies exactement avant la soumission, ce qui évite une dérive de précision fractionnaire dans le dimensionnement des packages.
  • Cotations de payoff multi-jambes : les graphiques de payoff multi-jambes utilisent le résolveur de cotations par jambe, afin que les valeurs affichées correspondent au package sélectionné.
  • Valeurs négatives : les valeurs négatives s'affichent désormais avec un signe explicite dans les interfaces de lancement.
  • Nettoyage des adresses de dépôt obsolètes : les adresses de dépôt obsolètes et l'état de bridge inutilisé ont été supprimés après la vérification du lancement.

Pas de nouvelle version - 22 mai-1er juin 2026​

Voir aussi : Article de lancement du réseau principal

Changements incompatibles​

  • Marge de portefeuille désactivée hors testnet : les environnements autres que testnet refusent désormais la configuration de la marge de portefeuille. L'alpha du réseau principal utilise uniquement la marge standard.
  • Normalisation de l'état des ordres : les libellés du cycle de vie des ordres distinguent de façon plus cohérente les états accusé de réception/ouvert et partiellement/entièrement exécuté. Les clients qui affichent les chaînes d'état brutes doivent les considérer comme les états canoniques présentés à l'utilisateur.

Ajouts​

Financement et comptes​

  • Sélection de la route de dépôt : l'application sélectionne les routes de dépôt à partir de la configuration des contrats active, au lieu d'hypothèses d'environnement codées en dur.
  • Zaps de dépôt sur l'Exchange : le testnet a reçu le flux de bridge et dépôt côté application, déployé ensuite sur le réseau principal, y compris la gestion des cotations et de l'état du relais.
  • Crédit explicite des dépôts : les dépôts USDC sur l'Exchange créditent le compte désigné dans l'événement de dépôt, ce qui évite toute attribution ambiguë lorsqu'un routeur ou un zap soumet la transaction.
  • Retraits USDC standard : les portefeuilles standard peuvent soumettre des retraits en USDC via le chemin API/actions système.
  • Initialisation de la marge à la création du compte : la configuration des clés API initialise désormais le mode de marge pris en charge pendant l'onboarding, ce qui réduit le risque qu'un compte financé se retrouve dans un état de trading invalide.
  • Paramètres de compte centralisés : les préférences et paramètres du compte ont été normalisés afin que le financement, les clés d'agent, la visibilité de la Trollbox et les paramètres de profil partagent une seule interface de compte.

Marchés et trading​

  • Marchés à venir : l'application peut afficher des cartes de marchés à venir sans les lister comme marchés négociables.
  • Intérêt ouvert fractionnaire par actif : l'intérêt ouvert par actif affiche des valeurs fractionnaires au lieu de tronquer les plus petits marchés.
  • Risque indicatif issu du catalogue en direct : les listes de marchés RFQ/risque indicatives sont dérivées du catalogue en direct plutôt que d'une liste frontend obsolète.
  • Caractère exécutable selon le bid/ask de référence : la saisie d'ordres utilise les données bid/ask de référence pour déterminer si un ordre est immédiatement exécutable.
  • Décroisement de l'IV multi-sources : les calculs de volatilité implicite du récapitulatif des options décroisent les prix bid/ask issus de sources multiples avant de dériver l'IV.
  • Lignes de mark fixes natives : les lignes de mark des stratégies utilisent désormais le comportement sticky natif pour un défilement plus fluide de la chaîne d'options.

Interface et contenu​

  • Mode sombre : l'application a reçu un passage complet en mode sombre sur l'ensemble de l'interface de trading.
  • États d'interaction : les états d'interaction du frontend ont été affinés pour la finition du lancement.
  • Séparation de la page d'accueil Hypercall et d'Insights : le routage web public a été remanié, avec Insights séparé sur sa propre propriété et la page d'accueil du produit pointant vers l'interface de trading en direct.
  • Article explicatif RPI vs RFQ : l'article sur l'exécution RPI a été publié et intégré aux supports de lancement.

Corrections​

  • Négociabilité dans le bandeau défilant : le bandeau défilant se limite aux marchés listés, afin que les utilisateurs ne voient pas d'actifs non négociables présentés comme actifs.

Aucune nouvelle version - 28 avril - 21 mai 2026​

Voir aussi : Mise à jour produit de la semaine 7

Changements incompatibles​

  • Suppression des surfaces d'API inutilisées : le point de terminaison inutilisé /limit_iv et la route en double /profile/username-request ont été supprimés. Les clients doivent utiliser les routes documentées dans la Référence de l'API REST.
  • Repli des paquets RFQ restreint : les RFQ multi-jambes sont des transactions de paquet et ne reposent plus sur la sémantique de repli vers le carnet d'ordres pour l'exécution multi-jambes arbitraire. Utilisez la soumission d'ordres à jambe unique pour le comportement de repli RPI/carnet d'ordres.
  • Chain IDs de signature configurables : la signature des ordres d'options ne suppose plus un chain ID de testnet unique. Les clients doivent déduire la chaîne de signature de l'environnement actif.

Ajouts​

Marchés​

  • Marché SPCX sur testnet : des options pré-IPO sur SpaceX ont été ajoutées au testnet, avec des échéances plafonnées à la date d'IPO du 12 juin.
  • Filtrage des marchés listés dans le bandeau défilant : en production et en staging, les bandeaux défilants des marchés n'affichent que les marchés listés, ce qui évite que des actifs indisponibles apparaissent comme négociables.
  • Modèle de volatilité par moneyness tenant compte des sessions : la modélisation de la volatilité prend en compte le contexte de session lors de la valorisation des marchés sensibles à la moneyness.

Constructeur de stratégies​

  • Constructeur de stratégies en 1 clic : les structures d'options courantes telles que les straddles, strangles, spreads verticaux et iron condors peuvent être sélectionnées dans une galerie de stratégies au lieu d'être assemblées jambe par jambe.
  • Constructeur avancé : le mode avancé ajoute des contrôles de plage de prix d'exercice, la sélection d'échéances lointaines pour les structures de type calendar, et la construction de stratégies avec jambes vendeuses.
  • Nouveau formulaire d'ordre multi-jambes : la saisie des paquets a été reconstruite avec une gestion des cotations par jambe, des comptes à rebours d'expiration des cotations, des messages sur le slippage et un parcours plus clair d'acceptation de la meilleure cotation.
  • Libellés et badges de stratégie : les en-têtes de stratégie affichent désormais des libellés compacts, la classification débit/crédit, et des noms plus courts lorsque le contexte du ticker ou de l'échéance est déjà clair.
  • Indicateurs de la chaîne d'options : les vues de chaîne ont gagné des pastilles de jambes sélectionnées, des lignes de mark fixes, des libellés DTE, des flèches de seuil de rentabilité et des indicateurs de position dans les vues chaîne, largeur et spread.

RPI et RFQ​

  • Retail Price Improvement : les ordres à jambe unique sur les instruments éligibles passent par l'enchère RPI avant de se replier sur le carnet d'ordres. Voir Priorité des ordres.
  • Flux de risque RFQ indicatif : les mises à jour des cotations indicatives et du risque sont diffusées via WebSocket, ce qui réduit l'interrogation périodique pour les surfaces de cotation actives.
  • Constructeur de client RFQ de haut niveau : le client Rust et la CLI de trading ont gagné des fonctions utilitaires pour construire des demandes de cotation RFQ.

Compte et clés d'agent​

  • Panneau de révocation des clés d'agent : les paramètres du compte listent désormais les clés d'agent actives avec un parcours de révocation. Voir Authentification des agents.
  • Notifications de clés d'agent : les utilisateurs disposant de trop de clés actives reçoivent une notification de recommandation renvoyant vers le panneau de révocation.
  • Sélection de chaîne prête pour le réseau principal : le chain ID de signature, la chaîne du portefeuille Privy et le comportement de changement de portefeuille sont désormais déduits de la configuration de l'environnement.

Trollbox​

  • Trollbox sur ordinateur : un panneau de discussion déplaçable est disponible dans l'application de bureau, avec des paramètres pour l'afficher ou le masquer.
  • Passerelle Telegram : les messages, réponses, médias, réactions, attributions de transfert, stickers et cartes de commande sont relayés entre la Trollbox web et Telegram.
  • Liaison de compte Telegram : les utilisateurs peuvent lier Telegram à un portefeuille via un parcours à code à usage unique.
  • Liens profonds et aperçus de la Trollbox : les liens de messages disposent d'aperçus OG, d'images de médias et de routes d'application pour les messages partagés.

Profil et interface​

  • Images de profil : les utilisateurs peuvent téléverser, recadrer ou importer des images de profil, avec des avatars de repli déterministes lorsqu'aucune n'est définie.
  • Parcours de vérification des ordres : la saisie d'ordres sur mobile a gagné une étape de vérification et une confirmation par glissement pour soumettre.
  • Finitions du thème et de la mise en page : les variables de thème, libellés de graphiques, actions rapides, pastilles de stratégie et états des boutons ont été affinés sur ordinateur et sur mobile.
  • Performances : les pages d'actifs et le classement réduisent les requêtes redondantes et s'affichent avec des données plus utiles dès le premier rendu.
  • Valeur nette du compte unifiée : les lectures de la marge de portefeuille et du flux Hydromancer utilisent l'état du portefeuille pour la valeur nette du compte, ce qui améliore la cohérence entre les affichages de marge.

Corrections​

  • Incohérence d'unité de vente par palier : la gestion des unités de vente et l'annulation des lignes de marge ont été corrigées pour l'admission des ordres par paliers.
  • Configuration du palier au premier ordre : les portefeuilles sans état de palier sont initialisés lors du premier ordre au lieu de déclencher une erreur de palier manquant.
  • Instruments expirés : la réconciliation du catalogue gère désormais les paires put/call manquantes et les instruments actifs expirés lors des ticks d'échéance.
  • Stabilité de la Trollbox : les heartbeats WebSocket, le routage par environnement, le chargement des avatars, la normalisation des médias, la persistance des réactions et la gestion des déconnexions pour inactivité ont été corrigés.

Aucune nouvelle version - 17–27 avril 2026​

Voir aussi : Mise à jour produit de la semaine 6

Ajouts​

RFQ​

  • Système de trading par demande de cotation (RFQ) : nouveau mode de trading pour les marchés sans liquidité profonde dans le carnet d'ordres. Soumettez une RFQ, recevez des cotations en temps réel sur le canal rfq authentifié du WebSocket, puis acceptez-les ou refusez-les. En l'absence de cotation, la demande se replie sur un ordre à cours limité dans le carnet d'ordres. Permet de lister rapidement de nouveaux actifs (US500, USOIL, GOLD, HYPE) sans attendre l'apparition d'une liquidité organique.
  • Mode d'exécution automatique : le nouveau type de signature EIP-712 SubmitAutoExecuteRfq pré-autorise l'exécution jusqu'à un prix limite. La première cotation éligible dans la limite est exécutée immédiatement, en un seul aller-retour. Si aucune cotation n'arrive ou si toutes dépassent la limite, la demande se replie sur un ordre à cours limité dans le carnet d'ordres.
  • Cartes de cotation RFQ : les cotations affichent les prix par jambe, la prime nette totale et un compte à rebours jusqu'à leur expiration. Acceptez ou refusez en un clic.
  • Contrôle du slippage : tolérance de slippage configurable (1 %, 2 %, 3 %, 5 %) par rapport au prix indicatif lors de la soumission d'une RFQ.

Trading multi-jambes​

  • Constructeur d'ordres d'options multi-jambes : cliquer sur une option dans la chaîne l'ajoute comme jambe à un formulaire d'ordre RFQ multi-jambes. Plusieurs jambes peuvent s'accumuler ; le bouton X supprime une jambe individuelle. Les jambes sont conservées dans l'URL (?legs=), de sorte que les ordres multi-jambes survivent à un rafraîchissement et peuvent être partagés.
  • Détection automatique des stratégies : détecte et nomme 28 types de stratégies : Bull/Bear Call/Put Spread, Long/Short Straddle, Long/Short Strangle, Calendar Spread, Diagonal Spread, Iron Condor, Iron Butterfly, Call/Put Butterfly, Call/Put Condor, Risk Reversal, Collar, Synthetic Long/Short, Ratio Spread, Backspread, Box Spread, Jade Lizard, Seagull, Broken Wing Butterfly, Split-Strike Conversion. Les noms de stratégies renvoient à la documentation.
  • Payoff, graphique et grecques combinés : la vue multi-jambes affiche un diagramme de payoff combiné, un graphique combiné du prix théorique (somme des prix théoriques de toutes les jambes) et les grecques agrégées (delta, gamma, thêta, véga), avec ajustement du signe pour les jambes vendeuses.
  • Bascule grecques par contrat / par stratégie : passez des grecques par contrat aux grecques agrégées au niveau de la stratégie dans le panneau inférieur.
  • Nombre maximal de jambes porté à 10 : contre 4 auparavant.

Liquidation​

  • Système de liquidation en deux phases : liquidation partielle via des ordres de clôture IOC gérés par le backend, avec escalade vers une liquidation totale par enchère on-chain lorsque la liquidation partielle est insuffisante.
  • Onglet Liquidations : nouvel onglet dans le panneau inférieur affichant les événements de liquidation du portefeuille connecté.
  • GET /liquidations : historique public, paginé par curseur, des transitions de liquidation, utilisé par les bots de liquidation tiers pour identifier les candidats.
  • Exemple de bot liquidateur : nouvelle crate liquidator illustrant la surveillance des liquidations en marge standard et l'envoi d'ordres de liquidation Hypercall signés.

Interface​

  • Attribution du P&L sur le graphique d'equity : activez l'icône des calques pour afficher des aires empilées par position sur le graphique d'equity. Une décomposition en barres horizontales sous le graphique regroupe les positions par sous-jacent, affiche le P&L réalisé par symbole et permet de filtrer par case à cocher pour isoler ou masquer des positions individuelles. Le survol du réticule met à jour la décomposition. Voir le guide desktop.
  • Panneau des marchés extensible avec fil d'Ariane : le panneau des marchés à gauche se replie pour laisser plus de place à l'interface de trading. Le fil d'Ariane indique le contexte de navigation (par ex. Assets > BTC > Options).
  • Cloche de notifications : remplace le mégaphone des annonces. Menu déroulant à onglets Notifications (exécutions) et Annonces. Le point de non-lu s'affiche dès le premier rendu grâce au SSR. L'horodatage de masquage par portefeuille est stocké dans localStorage.
  • Menu au survol du compte : survoler le bouton de profil affiche un menu déroulant avec l'equity, le P&L, le pouvoir d'achat et le nombre de positions. Les utilisateurs qui n'ont pas défini de nom d'utilisateur voient une invite « Choisir un nom ».
  • Aide dans la navigation : bouton d'aide dans la barre de navigation renvoyant vers la documentation.
  • Indicateur de service indisponible : indicateur rouge dans l'en-tête lorsque le backend est injoignable.
  • Badge de classement : badge de rang en direct dans la barre de navigation (remplace le lien vers le classement), avec des indicateurs de variation montrant l'évolution du rang au fil de vos trades.
  • Pages de détail des positions réglées : vue détaillée par position avec graphique du prix théorique, exécutions individuelles, décomposition du P&L réalisé et noms d'instruments lisibles (par ex. « BTC $55,000 Call Apr 14 »).
  • Images d'aperçu social dynamiques : images OG générées pour toutes les pages partageables : instruments (graphique théorique + grecques), stratégies multi-jambes (diagramme de payoff + nom de la stratégie), profils (statistiques de P&L + rang), classement (top 5 avec médailles) et confirmations de trade.
  • Barre de navigation desktop restructurée : pied de page supprimé, bouton de connexion déplacé dans l'en-tête, indicateurs de raccourcis clavier (Ctrl+K) visibles.
  • Troncature des prix dans l'en-tête des graphiques corrigée : les prix ne débordent plus dans les en-têtes de graphiques sur desktop.

PWA​

  • Bascule vers la route racine : toutes les routes sont regroupées de /mobile/* vers la racine /*. Les anciens chemins /mobile/* sont redirigés automatiquement. Schéma d'URL unifié entre desktop et mobile.
  • Parcours de mise à niveau de la PWA iOS : les utilisateurs ayant installé l'ancienne PWA /mobile voient une fenêtre de mise à niveau de style natif avec des instructions d'installation iOS pas à pas (Partager > Plus > Sur l'écran d'accueil) utilisant l'iconographie officielle d'Apple.
  • Écrans de démarrage iOS et préchargement de la navigation : plus de 12 écrans de démarrage spécifiques à chaque appareil éliminent le flash blanc au démarrage à froid. Le préchargement de la navigation récupère la page pendant le démarrage du service worker.
  • Raccourcis d'application : appui long sur l'icône de l'écran d'accueil pour accéder rapidement au Portefeuille et au Dépôt.
  • Maintien de l'écran allumé : garde l'écran allumé pendant les sessions de trading en mode PWA autonome. Réacquisition automatique à la reprise de l'application.
  • Stockage persistant : appelle navigator.storage.persist() pour empêcher le navigateur d'évincer les ressources mises en cache de l'application.

API​

  • instrument_type sur les événements WebSocket : les événements d'exécution et de mise à jour d'ordre incluent désormais instrument_type ("option" ou "perp"). Ajout rétrocompatible.
  • Filtre ?symbol= sur GET /profile/trades : filtrez l'historique des trades par symbole d'instrument. Réduit la taille des réponses pour les traders à fort volume qui interrogent des instruments spécifiques.
  • Exécutions perp transmises via WebSocket : les exécutions de contrats perpétuels Hydromancer sont désormais publiées sur le flux WebSocket (elles en étaient auparavant absentes).
  • AcceptRfqQuote et PlaceOrder via WebSocket : l'ensemble du cycle de vie d'un ordre (soumettre une RFQ, recevoir les cotations, accepter, placer l'ordre) peut désormais s'effectuer sur une seule connexion WebSocket, sans aucun appel REST.
  • Champ fills sur PerpOrderResult : le SDK Rust renvoie désormais les exécutions directement dans les réponses aux ordres perp. Champs : coin, side, size, price.

Corrections​

  • Ordres fantômes IOC/FOK : les ordres IOC et FOK partiellement exécutés laissaient leur quantité restante dans le carnet d'ordres sous forme d'ordres fantômes. Le reliquat est désormais annulé immédiatement après l'exécution partielle, et le statut passe à Canceled au lieu de PartiallyFilled.
  • Réservation de prime sur les achats de clôture : les ordres d'achat clôturant une position courte réservaient à tort la prime, ce qui réduisait l'equity et déclenchait de fausses liquidations. La réservation de prime est désormais ignorée pour les ordres d'achat qui clôturent une position.
  • Chaînes expirées après un déploiement : des chaînes d'options expirées apparaissaient brièvement comme actives au redémarrage du serveur. Les instruments sont désormais vérifiés par rapport à leur horodatage d'échéance au chargement et immédiatement marqués ExpiredPendingPrice.
  • Repli RFQ sans cotation : une RFQ à exécution automatique qui ne recevait aucune cotation éligible affichait auparavant une erreur. Elle se replie désormais sur le placement d'un ordre à cours limité dans le carnet d'ordres.
  • Précision des plus fortes variations du bandeau : les plus fortes variations affichées dans le bandeau défilant sont désormais calculées à partir du cache de synthèse des options, en comparant le prix théorique au prix théorique d'il y a 24 h, et filtrées sur les seules options cotées. Elles utilisaient auparavant les données BBO brutes, qui produisaient des valeurs bruitées ou obsolètes.
  • price_change de la synthèse des options : la référence BBO pour le calcul de la variation de prix utilise désormais uniquement l'offre du carnet d'ordres, remplaçant le repli mark-vs-théorique qui pouvait produire des chiffres trompeurs.

Pas de nouvelle version - 14–16 avril 2026​

Changements incompatibles​

  • PUT /order et PUT /bulk_order : nouveaux endpoints de remplacement atomique d'ordres. Ils annulent l'ordre existant et en placent un nouveau dans le même tick du moteur. Si l'annulation échoue (ordre déjà exécuté ou introuvable), le nouvel ordre n'est pas placé. Ils utilisent le nouveau type de signature EIP-712 ReplaceOrder. Les clients qui utilisent l'ancien schéma annulation puis placement doivent migrer.

Ajouts​

API​

  • GET /profile/realized-pnl : renvoie le PnL réalisé par symbole, agrégé à partir des exécutions et des règlements. Accepte un paramètre optionnel competition_id pour limiter les résultats à la fenêtre d'une compétition.
  • Champ realized_pnl sur GET /profile/trades : chaque ligne d'exécution inclut désormais le PnL réalisé attribué à cette transaction précise.
  • net_deposits et composantes d'attribution sur GET /profile/historical-pnl : les points historiques de valeur du portefeuille incluent désormais les dépôts nets cumulés et la ventilation de l'attribution du P&L.
  • Champ prev_day_px sur GET /markets : la réponse des marchés inclut désormais le prix de référence de la veille pour chaque instrument.

UI​

  • Mégaphone des annonces : icône de mégaphone dans les en-têtes desktop et mobile, avec un badge indiquant le nombre d'annonces non lues. Un clic ouvre une fenêtre listant les annonces (titre, contenu, date, image ou lien optionnel). État lu/ignoré conservé par portefeuille.
  • Modification et remplacement d'ordres : sur desktop, une icône crayon sur les ordres ouverts permet de modifier le prix et la taille directement dans la ligne ; la coche valide, le X annule, et la ligne passe en ambre pendant la modification. Sur mobile, toucher un ordre affiche les boutons Annuler et Mettre à jour.
  • Positions réglées sur la page membre : nouvelle section « Positions réglées » entre Positions et Historique des transactions. Elle affiche le PnL réalisé par symbole issu des options expirées et des transactions clôturées, en vert ou en rouge. Consultez Règlement pour savoir comment les options sont réglées.
  • Colonne PnL réalisé dans l'historique des transactions : affiche le PnL réalisé par exécution avec un code couleur ; les exécutions d'ouverture de position affichent un tiret.
  • La gestion des clés API ne clignote plus au chargement : la liste des agents s'affiche immédiatement au lieu d'apparaître après le chargement de la page.
  • Tableau des positions vide masqué : lorsque l'utilisateur n'a aucune position ouverte, la section des positions est entièrement masquée au lieu d'afficher des en-têtes de tableau vides.
  • Boutons de connexion sur l'état vide : rétablissement des boutons de connexion de portefeuille manquants sur les écrans vides.

PnL​

  • Le P&L est désormais net de la prime payée : le PnL réalisé tient maintenant compte de la prime payée pour ouvrir la position. Auparavant, seul le gain brut était affiché. Exemple : un portefeuille qui affichait +162 Kdereˊaliseˊaffichedeˊsormaiscorrectement+27K de réalisé affiche désormais correctement +27 K après prise en compte de 135 K$ de prime payée.
  • Options réglées regroupées par sous-jacent : l'attribution ne liste plus chaque symbole expiré individuellement ; les positions réglées sont regroupées par sous-jacent (par ex. « BTC (settled) »).
  • La valeur en temps réel ne tombe plus à zéro pour les positions OTM : la cassure où la valeur des positions hors de la monnaie (OTM) chutait brusquement à zéro sur la partie temps réel du graphique de valeur est corrigée.
  • Attribution visible pour les portefeuilles ne détenant que des positions expirées : les portefeuilles sans position ouverte mais avec des options réglées affichent désormais correctement l'attribution du PnL.

Corrections​

  • GET /profile renvoyant une erreur 500 : corrigé pour les portefeuilles dont les données agrégées sont incomplètes.
  • PnL latent obsolète après un redémarrage du serveur : les portefeuilles sont désormais revalorisés immédiatement au redémarrage au lieu d'attendre la prochaine mise à jour du prix de marque.
  • Décalage d'un jour du DTE dans les diagrammes de payoff : correction du calcul des jours restants avant l'échéance, qui décalait les lignes de seuil de rentabilité et de perte maximale.
  • Vol de focus : correction du vol de focus lors des interactions avec l'interface.
  • Améliorations de l'affichage des graphiques : diverses corrections d'affichage des graphiques.

Pas de nouvelle version - 11–13 avril 2026​

Ajouts​

Notifications push​

  • Notifications push du navigateur : abonnez-vous aux alertes d'exécution, de liquidation et de règlement via Web Push. Nouveaux endpoints : POST /push/subscribe, POST /push/unsubscribe, POST /push/preferences. Tous les endpoints push exigent une signature de portefeuille EIP-712. Des interrupteurs par type (exécutions, liquidations, règlements) sont disponibles dans les Paramètres desktop et les préférences du compte mobile.
  • Notifications toast sur desktop : toasts en temps réel pour les exécutions d'ordres et les erreurs sur l'interface desktop.

Trading​

  • Onglet Grecques (desktop) : nouvel onglet dans le panneau inférieur affichant par position le delta, le gamma, le thêta, le véga, le rho et l'IV. Les en-têtes de colonnes comportent des info-bulles renvoyant à la référence des Grecques. Lignes de sous-total par sous-jacent ; total du portefeuille lorsque les positions portent sur plusieurs sous-jacents.
  • Colonnes du classement triables : les colonnes profit, volume et efficacité du classement sont désormais cliquables pour le tri.
  • Améliorations du formulaire d'ordre : sélecteurs de montant rapides, info-bulles améliorées, dimensionnement adaptatif.
  • Graphique de PnL sur la page membre : les profils des membres affichent désormais un graphique de l'évolution de la valeur du portefeuille.
  • Statistiques HC/HL déplacées dans le panneau latéral : les statistiques HyperCore et HyperLiquid ont été déplacées dans un panneau latéral.
  • Suppression des lignes d'ordres de taille nulle : la liste des ordres n'affiche plus les ordres de taille nulle.

Mode invité​

  • Mode invité : les utilisateurs non authentifiés peuvent consulter les marchés, les carnets d'ordres et les graphiques sans connecter de portefeuille. La page Paramètres est également accessible sans authentification. Consultez le guide desktop pour plus de détails.
  • Favicons dynamiques par actif : l'icône de l'onglet du navigateur affiche un anneau vert avec l'icône de l'actif actif. Des variantes call/put s'affichent lors de la consultation d'options.

Graphiques​

  • Visualisation de la surface de volatilité : visualiseur 3D interactif de la surface de volatilité à l'adresse /risk/vol-surface pour tous les sous-jacents listés. Consultez Oracles pour savoir d'où proviennent les surfaces de volatilité.
  • Le graphique du portefeuille utilise par défaut un intervalle de 5 minutes : rendu plus fluide pour les comptes récents (vue 8H au lieu de 4J).
  • Mise à jour des graphiques lors d'un changement de préférence : changer le mode de graphique dans les préférences prend désormais effet immédiatement, sans rechargement de la page.

API​

  • Filtre d'échéance sur GET /options-summary : passez ?expiry=YYYY-MM-DD pour limiter la réponse à une seule échéance.

Compte​

  • Noms d'affichage : les portefeuilles peuvent définir un nom d'affichage visible dans le classement et sur les pages membres. Les noms prennent effet instantanément (sans validation par un modérateur). Modifiable directement depuis les Paramètres desktop et les paramètres mobiles.

Corrections​

  • Côtés bid/ask inversés pour certains ordres : correction de l'attribution incorrecte du côté selon le sens de l'ordre on-chain.
  • Temps de chargement de la chaîne d'options réduit d'environ 60 % : chargement plus rapide grâce au filtrage par échéance côté API et au préchargement des données de graphique pour les prix d'exercice visibles.
  • Le changement de marché est désormais instantané : plus de rechargement complet de la page lors du changement de sous-jacent sur desktop.
  • Plantage lors du changement de maturité sur desktop : correction du plantage et de la lenteur lors du passage d'une maturité d'option à une autre.
  • Défilement de la page compte sur desktop : un long historique des transactions défile désormais correctement.
  • Erreur 404 sur /preferences en mobile : la page des préférences est désormais accessible sur mobile.
  • Mise à jour du pouvoir d'achat après un dépôt : le solde se met désormais à jour immédiatement après un dépôt via le faucet du testnet, sans nécessiter d'actualisation.
  • Barrière de trading affichée lorsque l'agent n'est pas configuré : affiche les actions de configuration au lieu d'un bouton de signature non fonctionnel.
  • Effacement automatique des bannières d'erreur : les bannières d'erreur persistantes se ferment désormais d'elles-mêmes.
  • Mise en page du classement sur mobile : correction des valeurs tassées sur mobile par rapport au desktop.
  • Suppression du scintillement des redirections : suppression des redirections visibles lors de l'accès à l'application.

Aucune nouvelle version - 7–10 avril 2026​

Voir aussi : Semaine 4 : lancement de la version desktop

Ajouts​

API​

  • GET /historical-theos : prix théoriques des options dans le temps, en remplacement de l'historique brut des prix de dernière transaction. Intervalles de temps et limites configurables. Voir la référence de l'API REST.
  • GET /historical-theos/batch : récupère les séries de prix théoriques de jusqu'à 50 instruments en une seule requête. Paramètres : instrument_names=A,B,C&interval=1h&limit=100.
  • realized_pnl sur GET /profile/trades : les exécutions renvoient désormais le P&L réalisé.

UI​

  • Les grecques utilisent désormais les marks théoriques : tous les calculs des grecques utilisent les prix théoriques au lieu des prix de dernière transaction, ce qui améliore nettement la précision pour les strikes peu liquides.
  • Graphique du prix théorique sur les pages d'instrument : les pages de contrat d'option affichent un graphique historique du prix théorique (en remplacement de l'historique brut des prix de transaction).
  • Position affichée sur la page d'instrument : votre position ouverte sur l'instrument actif est affichée directement sur la page du contrat.
  • Amélioration des états vides : textes et mise en page améliorés pour les graphiques vides et les états vides.

Corrections​

  • Plafond de dépôt du faucet : le faucet du testnet respecte désormais l'allocation restante par portefeuille au lieu d'un maximum fixe.
  • Erreurs 503 intermittentes sur GET /portfolio : correction d'erreurs serveur intermittentes sur l'endpoint du portefeuille.
  • Indicateurs de chargement : suppression des indicateurs de chargement fantômes pendant le chargement des pages.
  • GET /profile/trades renvoyant une erreur 500 : corrigé pour les portefeuilles ayant des exécutions.
  • Décalage de mise en page de la page membre : correction d'un décalage d'alignement sur la page membre.
  • Libellé du graphique par défaut : précision que la préférence de graphique par défaut s'applique aux actifs.

Aucune nouvelle version - 1–6 avril 2026​

Voir aussi : Mise à jour produit de la semaine 3

Changements incompatibles​

  • Modification du modèle de marge de portefeuille : la formule de marge initiale passe de scanning_risk à max(scanning_risk, option_floor) + gamma_overlay. Trois nouveaux champs dans les réponses de portefeuille REST et WebSocket : scanning_risk, option_floor, gamma_overlay. Le solde disponible est désormais equity - total_margin_used (auparavant cash - total_margin_used). L'equity inclut désormais le P&L latent des contrats perpétuels.
  • Modifications de GET /risk/grid : suppression du paramètre include_open_orders. Le modèle de scénarios passe d'un axe unique {scenario_type, value} à des chocs combinés {spot_shock_pct, vol_shock_pct, pnl_weight, is_tail}. Le P&L du pire scénario est désormais pondéré.

Ajouts​

Desktop​

  • Interface de trading desktop : interface desktop complète avec vue de trading multi-panneaux, navigation au clavier, graphique de prix de l'instrument, symboles d'option compacts et navigation par clic depuis les positions/ordres vers les instruments.

API​

  • Les instruments d'option incluent désormais le symbole et le prix du sous-jacent : les réponses des instruments d'option exposent leur actif sous-jacent. Voir la référence de l'API REST.

Compétition et classement​

  • Système de compétition : nouveaux endpoints : GET /competitions, GET /leaderboard, GET /competition-metric-ranks, POST /submitUsernameRequest. Calendrier mensuel (du 1er au 1er à 16 h 00 ET). Compétition testnet avec de vrais prix (500 /300/300 /200 $ en SYN). Les teneurs de marché sont exclus des classements.
  • Interface du classement : badge de rang (« Rang #X » ou CTA « Tradez pour gagner »), carte de répartition des prix, intégration de Hyperliquid Names, symboles d'option formatés (« 04/10 $59,000 Call »), P&L par lot FIFO, horodatages relatifs (5m, 2h, 3d).
  • Markdown dans les descriptions de compétition : les descriptions de compétition prennent en charge la mise en forme markdown.

Portefeuille​

  • Marge de portefeuille : marge croisée entre positions corrélées. Les instruments arrivés à échéance sont exclus de l'overlay gamma.

UI​

  • Symboles d'option compacts : format lisible dans toute l'interface : « 04/10 $59,000 Call ».
  • Bouton Max sur le formulaire d'ordre : taille maximale en un clic selon la marge disponible.
  • Séparateurs de milliers : tous les champs de prix et de taille affichent des séparateurs.
  • Clic sur position/ordre → instrument : appuyer sur une ligne de position ou d'ordre ouvre le contrat correspondant.
  • Page des préférences : infobulles, rotation des badges et état des préférences synchronisé entre les sessions.

Corrections​

  • Centrage UTC des graphiques : les graphiques d'actifs sont centrés sur les bornes UTC ; transitions entre périodes stabilisées.
  • Gestes de balayage (mobile) : correction du comportement erratique du balayage pour annuler et de la navigation par balayage.
  • Suppression du préfixe d'URL sur desktop : suppression du préfixe /mobile des URL sur desktop ; sélection du strike corrigée.

Aucune nouvelle version - 24–31 mars 2026​

Voir aussi : Mise à jour produit de la semaine 2

Ajouts​

Graphiques​

  • Graphique historique du P&L : graphique de l'equity dans le temps sur la page d'accueil avec réticule interactif. Touchez ou cliquez pour inspecter n'importe quel point ; affiche l'horodatage et met à jour l'affichage du solde.
  • Graphique d'actif : graphique du prix spot par actif avec un axe des ordonnées borné à la plage de la période visible.

Gestion des ordres​

  • En-têtes de section : les sections positions, ordres et historique ont des en-têtes distincts pour une lecture plus rapide.
  • Balayer pour supprimer un ordre (mobile) : balayez vers la gauche sur un ordre ouvert pour l'annuler.
  • Confirmation d'annulation d'ordre : boîte de dialogue dédiée à l'annulation d'ordre.
  • Clic sur une ligne d'ordre → page du contrat : appuyer sur un ordre ouvre la vue détaillée de l'instrument.
  • Nouvelle apparence des ordres ouverts : style actualisé pour les ordres ouverts.

Connectivité​

  • Bannières de déconnexion WebSocket : bannières visibles lorsque le flux WS est interrompu ou que le backend est injoignable.

Grecques​

  • Grecques de position sur la page d'actif : delta, gamma, thêta et véga agrégés sur la page de détail de l'actif.
  • Grecques du contrat sur la page du contrat : grecques par position sur la vue du contrat.
  • Seuils de rentabilité pour tous les types d'option : seuils de rentabilité calculés et affichés pour les calls, les puts et les spreads.

Historique des transactions​

  • Heure d'exécution sur GET /profile/trades : les lignes de l'historique des transactions incluent désormais l'horodatage de l'exécution.
  • Persistance de l'échéance dans la chaîne d'options : l'échéance sélectionnée est enregistrée dans les paramètres de requête de l'URL et restaurée lors de la navigation.
  • Les instruments d'option incluent le symbole et le prix du sous-jacent : les instruments d'option exposent leur actif sous-jacent dans les réponses.

Compte​

  • Système de nom d'utilisateur : définissez un nom d'affichage pour l'adresse de votre portefeuille, affiché sur le classement et les pages membres.

Corrections​

  • GET /profile/trades renvoyant une erreur 500 : corrigé pour les portefeuilles ayant des exécutions.
  • Ordre d'affichage par défaut des positions : les positions affichent par défaut la valeur, puis le P&L, puis le prix de revient (auparavant incohérent).
  • Le pied de l'ordre affiche le temps restant avant l'échéance : ajout de l'affichage du TTE ; un délai de signature d'une seconde empêche les doubles soumissions accidentelles.
  • Déconnexion sur mobile : l'état de session est correctement effacé à la déconnexion.
  • Arrière-plan en mode clair : correction de la couleur d'arrière-plan en mode clair.
  • Transitions de page plus fluides : réduction des saccades visuelles pendant la navigation.
  • Arrière-plan lors du balayage : correction du rendu de l'arrière-plan pendant les interactions de balayage.

Aucune nouvelle version - 16–23 mars 2026​

Voir aussi : Mise à jour produit de la semaine 1

Ajouts​

Thème et apparence​

  • Mode sombre Midnight : nouveau thème sombre à contraste élevé, en complément du mode clair existant.
  • Mode de thème automatique : le thème s'adapte automatiquement à la préférence clair/sombre de l'appareil. Les nouveaux utilisateurs sont en mode automatique par défaut.

Tableau de bord et statistiques​

  • Champs de statistiques HL et HC : basculez entre les statistiques propres à Hyperliquid et celles propres à Hypercall sur le tableau de bord.
  • Ratio put/call : ajout du ratio put/call au panneau de statistiques Hypercall.
  • Badges de résultat : badges visuels pour les résultats des transactions (gain, perte, expirée sans valeur, etc.) avec un graphique circulaire dans l'en-tête de position.

Chaîne d'options​

  • Tri des strikes et persistance de la sélection : les prix d'exercice peuvent être triés ; la sélection est conservée d'une session à l'autre.
  • Initialisation de l'objectif de prix : la page d'objectif de prix est préremplie avec le prix actuel du sous-jacent au lieu d'être vide.
  • Normalisation du prix du sous-jacent : affichage cohérent du prix du sous-jacent sur toutes les pages, y compris les données de contrats perpétuels DEX.

Expérience de passage d'ordres​

  • Message d'annulation pour les ordres exécutés ou expirés : les tentatives d'annulation d'ordres déjà exécutés ou expirés affichent « This order has already been completed or cancelled » au lieu d'une erreur brute.

Préférences​

  • Page des préférences : infobulles, rotation des badges et état des préférences synchronisé d'une session à l'autre.

Corrections​

Connectivité​

  • Actualisation des données à la reconnexion WebSocket : les ordres, les exécutions et le portefeuille sont rechargés lors de la reconnexion WS au lieu d'afficher des données obsolètes.
  • Délai de reconnexion WS : le minuteur de backoff est désormais réinitialisé après une connexion saine. Auparavant, il n'était jamais réinitialisé, si bien qu'après quelques déconnexions normales, chaque reconnexion attendait 30 secondes.

Ordres​

  • Ordres fantômes sur les instruments expirés : les ordres sur les instruments réglés sont désormais correctement nettoyés, ce qui évite les erreurs « Orderbook not found » lors de l'annulation.
  • Rejet des soldes de trésorerie négatifs : les ordres d'achat (BUY) qui rendraient le solde de trésorerie négatif sont désormais rejetés à la soumission. Message de rejet : « Insufficient cash (Standard) ». Cette règle peut être contournée pour les ordres d'achat de clôture (buy-to-close) qui réduisent le risque. Voir Marge standard.

Interface​

  • Animation de l'objectif de prix : correction de l'animation saccadée ou bloquée sur la page d'objectif de prix.
  • Troncature du graphique d'actif sur mobile : correction de la troncature des actions rapides sur le graphique d'actif mobile.
  • Blocage du chargement de la PWA mobile : correction d'un problème qui bloquait la PWA mobile sur « Loading... ».

Problèmes connus​

Avant de déboguer le comportement de votre client, consultez d'abord la page de statut Hypercall pour vérifier les incidents et maintenances en cours.

Le comportement et les problèmes connus de l'environnement de staging sont communiqués avec l'accès ; contactez l'équipe pour plus de détails.

Politique de versionnage​

Niveaux de stabilité :

  • Stable : les chemins du routeur et les structures principales de requête/réponse ont peu de chances de changer

Changements incompatibles : ils seront documentés ici, accompagnés de guides de migration.

Références​

Dernière mise à jour le