Vue d’ensemble de l’architecture

Le protocole est un petit ensemble de contrats sur HyperEVM qui lisent les prix sur HyperCore, la couche d’Hyperliquid, via des précompilées, et y déplacent des USDC. Cette page présente les contrats et la façon dont ils s’articulent.

Architecture on-chain. Les intentions signées vont du relayer, via le BatchExecutor, à l’Exchange, qui lit les prix d’Hyperliquid dans les précompilés de HyperCore et déplace les USDC avec CoreWriter. Staking, Tokenomics et le jeton se trouvent à côté.

Contrats (HyperEVM)

Exchange : le contrat de trading. Il tient chaque solde, ouvre et clôture les positions, règle les résultats, gère la file des paiements et détient le LP et les comptes de frais. Un point d’entrée minimal délègue à quatre bibliothèques (trading, file, fonds, administration). Les ouvertures et les clôtures n’arrivent que par le BatchExecutor ; les retraits et les appels de maintenance peuvent venir de n’importe qui.
BatchExecutor : le seul point d’entrée du relayer. Il n’accepte de lots que des clés de relayer configurées et transmet chaque appel signé, uniquement vers une liste fixe de fonctions.
SessionKeyManager : enregistre les clés de session, vérifie chaque signature et chaque nonce pour l’Exchange, et gère la révocation. L’enregistrement passe par le relayer ; la révocation peut aussi être un appel direct depuis votre portefeuille.
Token, Staking, Tokenomics : le jeton BACK (transfert désactivé au lancement), le contrat de staking avec son accumulateur de récompenses, et le contrat qui calcule et émet les BACK pour les pertes et tient le LP comptable.
BuilderRegistry : les builders approuvés et le taux unique des frais de builder, plafonné à 15%. Non évolutif : le remplacer, c’est déployer un nouveau contrat vers lequel on fait pointer le SessionKeyManager.
DepositProxyFactory et DepositProxy : dérivent l’adresse de dépôt déterministe de chaque compte et déploient le petit contrat qui se trouve derrière, lequel ne peut envoyer d’USDC sur HyperCore qu’à l’Exchange. Aucun des deux n’est évolutif : une adresse de dépôt ne doit jamais changer.
Lentilles et PriceOracle : des vues en lecture seule sur l’Exchange et HyperCore, et un utilitaire de prix, pour les apps et les services. L’Exchange lit les précompilées directement, pas par leur intermédiaire.

Les adresses figurent sur la page Adresses des contrats.

Précompilées (HyperCore)

BBO 0x000000000000000000000000000000000000080e : le meilleur prix acheteur et le meilleur prix vendeur ; leur point médian est le prix d’exécution.
Mark 0x0000000000000000000000000000000000000806 : le prix de marque d’Hyperliquid, lu par les garde-fous de prix inactifs et utilisé en secours quand un marché est retiré.
Oracle 0x0000000000000000000000000000000000000807 : le prix oracle d’Hyperliquid, avec les mêmes usages que le prix de marque.
CoreWriter 0x3333333333333333333333333333333333333333 : le contrat système qui envoie des actions à HyperCore. Les proxys de dépôt l’utilisent pour envoyer des USDC vers le compte HyperCore de l’Exchange, et l’Exchange s’en sert pour payer les retraits vers votre compte HyperCore.

Les précompilées de solde permettent à l’Exchange de vérifier qu’un dépôt est réellement arrivé avant de le créditer (Dépôts : proxys CREATE2).

Un trade de bout en bout

Vous signez une intention avec votre clé de session et l’app l’envoie au relayer, qui la vérifie et la met en file. Le relayer regroupe les intentions en file dans un lot et l’envoie au BatchExecutor, qui appelle l’Exchange une fois par intention. L’Exchange vérifie la signature via le SessionKeyManager, lit le BBO pour le prix d’exécution, ouvre la position ou règle la clôture avec le LP, met à jour votre solde et, en cas de perte, fait émettre des BACK pour vous par Tokenomics. Les intentions de nombreux comptes partagent une transaction, mais chacune est réglée séparément : le relayer marque chaque appel comme autorisé à échouer, si bien qu’une intention qui échoue n’arrête pas les autres.

Frontends

Chaque ouverture et chaque clôture est soumise par notre relayer. Un autre frontend peut produire les mêmes signatures et les envoyer par l’API du relayer (API des intentions), mais il ne peut pas soumettre d’ouvertures ni de clôtures directement aux contrats.

Services off-chain

Service	Rôle
Intake du relayer	Accepte les intentions signées, les vérifie et réserve les soldes.
Moteur du relayer	Planifie les intentions en file et les soumet par lots.
Indexeur	Suit la chaîne bloc par bloc, vérifie les invariants comptables à chaque bloc et diffuse les mises à jour des comptes.
API de lecture et flux	Servent à l’app l’état des marchés, l’historique et le flux en direct du compte.
Keepers	Liquident, récoltent la file, distribuent les récompenses de staking, ajustent les plafonds d’intérêt ouvert, changent de courbe de paiement selon le calendrier, rejouent les émissions différées.
Sweeper et worker de financement	Balaient les dépôts et acheminent les retraits vers d’autres chaînes.

Aucun de ces services ne peut signer à votre place ni déplacer vos fonds sans votre signature. S’ils s’arrêtent, le trading s’arrête, mais votre solde libre reste retirable depuis votre portefeuille.

Gouvernance

Le propriétaire de chaque contrat évolutif est un timelock : une mise à niveau ou un changement de paramètre est programmé par le multisig de gouvernance et ne peut s’exécuter qu’après 2 jours. Un second timelock, avec un délai de 7 jours, contrôle qui détient les rôles du premier. Un multisig gardien peut agir immédiatement en cas d’urgence, dans les limites étroites listées sur Risques.