Moteur de recherche, de vérification de faisabilité et d'audit de risque d'opportunités de rendement DeFi. Il ne trade pas : il cherche, il vérifie aux sources, il chiffre le risque et il recommande. L'humain décide et exécute.
Un substrat Python déterministe tourne toutes les 4 heures sans aucun LLM et sans aucun coût, remplit un classeur qui calcule lui-même les scores et l'allocation ; une flotte d'agents Claude n'intervient qu'en couche de jugement, pour auditer aux sources ce qui a bougé.
Le cycle complet — collecte, statistiques, scoring, allocation, alertes, publication — ne fait appel à aucun modèle. Les agents ne coûtent que sur le delta.
Frontière structurelle : les agents ne peuvent écrire que des cellules de saisie. Le helper d'écriture refuse les colonnes calculées.
Tout APY et tout funding est sourcé en direct, recoupé sur au moins deux sources, cité et daté.
Introuvable ⇒ ? et drapeau, jamais une estimation.
Chaque décision est enregistrée avec ses métriques du moment. Une position se ré-évalue par péremption ou par dérive — jamais par oubli.
Un rendement affiché ne vaut rien tant que la position n'est pas constructible. Le cas fondateur du projet : un actif à 7,39 % de base affichait une boucle théorique à « 202 % » — sauf que l'actif n'était pas éligible comme collatéral, donc pas d'emprunt, donc pas de boucle. Rendement réel : 7,39 %. Tout l'ordre des vérifications découle de là, sur les quatre stratégies.
Le mandat, le plancher de rendement, les plafonds durs, et ce qui n'est pas négociable.
Les 30 étapes déterministes, dans l'ordre, et pourquoi cet ordre.
Quelles venues peuvent porter une jambe réelle depuis la France — et pourquoi « MiCA » n'est pas la bonne question.
Ce que le système cherche, ce qu'il refuse de chercher, et les bornes qu'aucune analyse ne peut franchir. C'est la seule page qui énonce des règles ; partout ailleurs on les applique.
Le mandat est celui d'un mercenaire de rendement : trouver le meilleur ROE ajusté du risque, avec un plancher de 15 % net toutes stratégies confondues (cible 15–30 %). Ce plancher n'est pas un objectif indicatif mais un filtre : en dessous, un candidat n'est pas retenu, quelle que soit sa qualité par ailleurs.
Aucun profil personnel de risque n'est injecté dans les analyses, et la cible de rendement ne se débat pas. Les agents exécutent la doctrine ; ils ne la challengent pas. Cette règle existe parce qu'un agent qui « conseille de viser plus prudent » ne fait pas le travail demandé — il le remplace par un autre.
Cet ordre est la source unique. Aucun autre document, script ou agent n'a le droit d'énoncer un mix cible : s'il le fait, c'est un bug de doctrine et il doit renvoyer ici. Le cas s'est produit — le staking avait été annoncé « cœur 70–100 % » dans deux documents et jusque dans l'allocateur.
| Rang | Stratégie | Cible souple | Nature |
|---|---|---|---|
| 1 | Arbitrage de funding fiat — le cœur du projet | ~60 % (arbitrage) | Carry cross-venue sur paires forex perp |
| 2 | Arbitrage de funding crypto | Carry cross-venue sur BTC / ETH / alts | |
| 3 | Staking delta-neutre | ≤ 20 % (satellite) | Staking couvert par un short perp |
| 4 | Loops lending / borrowing | ~30 % | Boucle géométrique de collatéral on-chain |
Les cibles ci-dessus sont souples ; les plafonds ci-dessous ne le sont pas. L'allocateur les applique mécaniquement, sans arbitrage possible.
Conséquence directe : un livre plein exige au moins 5 positions. Une seule idée excellente ne peut pas absorber le capital.
Un défaut de venue ne peut jamais emporter plus de 40 % du capital, quelles que soient les positions qui y vivent.
Net de frais et de coût de couverture. Un rendement incité (émissions de jetons) n'est pas un rendement acquis et ne suffit pas à franchir le plancher.
Un candidat validé avec levier doit citer le levier, sa source (modèle propre à la paire) et le notionnel borné par l'open interest. Un repli sur une valeur de famille interdit la validation.
Tout dimensionnement en dollars part du capital réellement observé (valeur nette du portefeuille), jamais d'un montant théorique. Un chiffre en dollars qui ne cite pas sa source de capital est un chiffre invalide. C'est la raison d'être de la réconciliation portefeuille du cycle : le dimensionnement ne peut pas dériver d'un capital imaginaire.
| Règle | Source unique |
|---|---|
| Ordre de pertinence, cibles, plafonds | CLAUDE.md (doctrine projet) |
| Contrat des agents (8 règles dures) | CLAUDE.md → Le contrat |
| Régime juridictionnel d'une venue | tools/venues_policy.json → Conformité |
| Situation technique d'une venue | docs/VENUES.md → Registre des venues |
| Historique des choix d'architecture | docs/DECISIONS.md → ADR |
Une règle = un endroit. Toute duplication finit par diverger, et c'est toujours la copie qui a tort. Un document qui redit une règle doit se contenter de renvoyer à sa source.
Les termes employés partout ailleurs sans être redéfinis. Destiné en particulier à une lecture externe : le vocabulaire mélange finance, DeFi et vocabulaire propre au projet.
| Terme | Définition |
|---|---|
| Perpetual (perp) | Contrat à terme sans échéance. Son prix est arrimé au comptant par un mécanisme de funding. |
| Funding | Paiement périodique (1 h, 4 h ou 8 h selon la venue) entre longs et shorts. Signe positif ⇒ les longs paient : un short encaisse. Négatif ⇒ l'inverse. |
| APR annualisé | taux_par_période × (8760 / intervalle_en_heures) × 100. C'est la seule forme comparable entre venues d'intervalles différents. |
| Delta-neutre | Position dont l'exposition directionnelle nette au sous-jacent est ~nulle (long comptant + short perp de même taille). On ne gagne alors que le carry. |
| Carry | Le rendement récurrent d'une position tenue, hors variation de prix. |
| Open interest (OI) | Notionnel total ouvert sur un marché. Sert de garde de faisabilité : une jambe ne peut pas dépasser une fraction de l'OI. |
| Basis / spread de funding | Écart d'APR de funding entre deux venues sur la même paire. C'est la matière première de l'arbitrage. |
| MiCA | Règlement européen sur les marchés de crypto-actifs. Couvre le comptant, la conservation, l'échange — pas les dérivés. Voir Conformité. |
| MiFID II | Directive européenne sur les instruments financiers. C'est elle qui régit les perps. |
| Terme | Définition |
|---|---|
| Loop | Boucle déposer → emprunter → redéposer, qui démultiplie l'exposition à un écart de taux. |
| LLTV | Liquidation Loan-To-Value : ratio d'endettement au-delà duquel la position est liquidée. |
| Health factor (HF) | Marge de sécurité vivante d'une position empruntée. Sous 1, liquidation. |
| Marché isolé / mutualisé | Isolated : un échec reste contenu au marché (Euler v2, Morpho Blue). Shared : tout le pool est solidaire (Aave main pool). Critère de premier rang du projet. |
| LST | Liquid Staking Token — jeton représentant une position stakée (stETH…). Risques propres : dépeg et liquidité de sortie. |
| Impermanent loss | Perte propre aux pools de liquidité (AMM). Hors périmètre par doctrine. |
| Dépeg | Décrochage d'un actif censé suivre une référence (stable, LST). |
| DEX non-custodial | Plateforme où l'utilisateur conserve ses fonds ; il n'y a pas d'intermédiaire qui les détient. |
| Terme | Définition |
|---|---|
| Substrat | L'ensemble des scripts déterministes du cycle 4 h. Par opposition à la couche agents. Coût : 0 token. |
| Cycle | Une exécution complète du substrat, toutes les 4 heures. |
| Digest / STATE.md | Compression du classeur (16 onglets) en ~2 000 tokens. C'est la lecture par défaut de toute session. |
| CHANGED / recheck | La worklist déterministe : ce qui a bougé depuis le dernier verdict. Ce qui n'a pas bougé n'est pas retraité — c'est ce qui rend les agents économiques. |
| Verdict | Décision enregistrée au journal : VALIDÉE REJETÉE EN ATTENTE. Une par candidat audité, sinon l'audit reboucle. |
| Ledger | Journal en ajout seul de toutes les décisions, avec les métriques du moment. Ni blacklist ni whitelist. |
| Péremption / dérive | Les deux causes de ré-évaluation automatique : verdict plus vieux que 30 jours, ou métriques déplacées de plus de 25 %. |
| Colonnes de saisie / calculées | La frontière que les agents ne peuvent pas franchir : ils posent des faits (saisie), le classeur calcule (score, grade, allocation). |
| ROE safe | Rendement des fonds propres calculé à un LTV volontairement en retrait du LLTV, pour conserver un tampon de liquidation. Toujours préféré au ROE maximal. |
| Jambe | Un des deux côtés d'une position couverte (le long comptant et le short perp, ou la venue basse et la venue haute d'un arbitrage). |
| Confiance 🟢🟡🔴 | Niveau de fiabilité attaché à chaque donnée citée dans un audit. 🔴 prime toujours sur un APY élevé. |
| Terme | Définition |
|---|---|
| Cockpit | L'interface web locale de pilotage (port 8799). Voir Cockpit & surfaces. |
| Snapshot | Version figée et statique du cockpit, sans backend, publiée sur Cloudflare Pages — lisible PC éteint. |
| operator / viewer | Les deux rôles d'accès. viewer ne voit que les analyses : portefeuille, positions et classeur sont masqués. |
| Flotte | Les agents Claude : Éclaireur, Auditeur, Sentinelle, Stratège, Cartographe. Voir La flotte. |
| ADR | Architecture Decision Record — une décision d'architecture, sa raison et sa date. Voir Décisions. |
Le système se décompose en quatre couches aux responsabilités disjointes. Le découpage n'est pas cosmétique : c'est lui qui garantit qu'un modèle de langage ne peut pas fausser un chiffre.
| # | Pilier | Rôle | Coût |
|---|---|---|---|
| 1 | Recherche | Scripts Python déterministes qui interrogent les API et protocoles, calculent les statistiques et rafraîchissent le classeur. C'est le substrat. | 0 token |
| 2 | Classeur DYOR | Le moteur sous le capot : source de vérité unique, il calcule scores, grades, levier, éligibilité et allocation par formules. | 0 token |
| 3 | Mémoire (PKM) | Le dépôt Git : documentation, notes d'audit, journal des décisions, décisions d'architecture. Traçabilité et sauvegarde. | 0 token |
| 4 | Interfaces | Cockpit web, snapshot Cloudflare, Discord, classeur Excel. Lecture et pilotage. | selon usage |
Le cerveau — l'analyse qualitative — est Claude, branché par-dessus : la flotte d'agents lit le digest produit par le pilier 1, audite aux sources, et n'écrit que dans le pilier 2, sous contrainte. Elle n'est jamais dans le chemin de calcul.
Tout ce pilier tourne sans modèle de langage : ce sont des scripts qui appellent des API publiques et écrivent leurs résultats. Reproductible, gratuit, explicable — trois propriétés qu'un LLM ne peut pas offrir sur un chiffre.
Il se subdivise en deux moteurs :
Les deux alimentent des scans par stratégie, qui remplissent chacun un onglet du classeur. L'orchestration est décrite dans Le cycle 4 h.
bureau/dyor-checklist.xlsx est la source de vérité unique. Les scores, grades, leviers,
prix de liquidation, éligibilité et allocation se calculent dans le classeur, par
formules Excel — pas dans le LLM, pas dans un script d'agent. Les agents ne font que remplir des
cellules de saisie et lire le résultat. Détail : Le classeur DYOR.
Parce que c'est simultanément le moteur de calcul, l'interface humaine et le format d'archive. L'opérateur voit la formule qui produit le score, peut la modifier, et le résultat est le même pour la machine et pour lui. Un service web équivalent aurait exigé une couche d'administration entière pour la même fonction.
Le dépôt Git est la mémoire et la sauvegarde du système :
docs/ — architecture, décisions d'architecture, méthode d'audit, registres de venues ;reports/ — versionnées : les notes d'audit des agents et les
synthèses de posture. Chacune porte ses sources, ses dates et son niveau de confiance ;tools/ledger.csv — le journal en ajout seul des décisions ;CLAUDE.md — la doctrine, lue par Claude Code à chaque session.L'état généré est repoussé sur GitHub à la fin de chaque cycle. Cette publication a une seconde fonction, moins évidente : elle garde l'arbre de travail propre. Sans elle, les fichiers suivis réécrits par le cycle bloqueraient toute mise à jour du code sur les autres postes.
Quatre surfaces, une seule vérité : elles lisent toutes les mêmes fichiers d'état, produits par le pilier 1. Deux surfaces qui se contredisent est traité comme un défaut, pas comme une différence de présentation. Détail : Cockpit & surfaces.
Le battement du système. Une exécution complète, déclenchée toutes les quatre heures,
sans aucun appel à un modèle de langage. Ordre de tools/run_4h.ps1 sous Windows, de
deploy/run_cycle.sh sur la machine cloud.
| Contrainte d'ordre | Raison |
|---|---|
| Sauvegarde de la base avant la collecte | La copie hebdomadaire doit figer l'état sain de la veille, pas celui d'après une collecte fautive. |
| Liquidité de couverture avant le scan staking-DN | Le scan doit écarter les venues trop fines avant de choisir « le meilleur funding » — sinon il recommande une jambe inexécutable. |
| Statistiques de funding avant la veille de ROE | La veille recalcule le carry des jambes réelles : elle a besoin du funding du cycle courant. |
| Registre des positions avant l'assertion | L'assertion vérifie un registre figé, pas un registre en cours d'écriture. |
| Assertion avant le push GitHub | Pour que le verdict de santé du cycle parte avec l'état publié — c'est lui que lit la surveillance à distance. |
| Tableau de bord en dernier | Il met en forme et masque les onglets techniques : toute étape ultérieure défairait la mise en page. |
Un fichier de verrou est posé au démarrage. Un second cycle (déclenchement manuel pendant le cycle planifié) sort immédiatement, et le cockpit refuse ses commandes mutantes tant que le verrou est frais. Le verrou périme au bout de 2 h : un cycle tué ne bloque jamais durablement.
Lancé par le planificateur, le script hérite d'un répertoire courant non inscriptible. Tout chemin relatif y échoue en silence. Le cycle se replace donc explicitement à la racine du dépôt. Ce détail a coûté deux pannes silencieuses : le déploiement Cloudflare échouait à chaque cycle sans que rien ne le signale, puis le scan on-chain n'arrivait plus à ouvrir sa base.
Si l'opérateur a le classeur ouvert, les étapes qui devraient l'écrire sautent leur sauvegarde et le journalisent, au lieu d'échouer. Toutes les écritures passent par une sauvegarde atomique.
Au-delà de 4 Mo, le journal est basculé sur une génération unique et repart à zéro. Un journal qu'on n'ouvre plus parce qu'il est trop gros ne surveille rien : il avait atteint 10 Mo et 132 cycles avant que la rotation soit ajoutée.
La dernière phase produit un verdict de santé 🟢 🟡 🔴 qui compare les étapes attendues aux étapes exécutées, vérifie la fraîcheur de chaque fichier d'état, et contrôle que la publication GitHub et la publication Discord du cycle précédent ont bien eu lieu.
Ce verdict est publié avec l'état. Une surveillance externe (GitHub Actions, toutes les 4 h) le relit et ouvre automatiquement une alerte si aucun verdict frais n'est arrivé depuis 9 heures. C'est le seul dispositif qui survit à un PC éteint : il détecte l'absence de cycle, pas seulement un cycle en erreur.
| Hôte | Script | Rôle |
|---|---|---|
| PC Windows | tools/run_4h.ps1 | Tâche planifiée. Filet tant que la machine cloud n'a pas enchaîné 24 h de cycles verts. |
| Machine cloud (conteneur) | deploy/run_cycle.sh | Toujours allumée : plus d'état périmé, cycle garanti. Le serveur choisit le script selon le système. |
| GitHub Actions | funding-cron.yml | Collecte du funding 24/7 depuis une adresse américaine — couvre les venues sans historique public et les venues géo-sensibles. |
PC et machine cloud écrivant le même état, deux cycles concurrents produisent des conflits de publication et un classeur incohérent. La procédure de migration est explicite : on bascule, on ne double pas.
Le paquet src/defiintel/ lit l'état réel des protocoles de prêt et le
normalise. C'est le seul endroit du système où la faisabilité d'une boucle est établie — pas d'après
une documentation, mais d'après ce que les contrats disent au moment de la lecture.
La configuration qui détermine la faisabilité vit dans les contrats de chaque protocole : un actif éligible comme collatéral ici ne l'est pas là, un LLTV varie par marché, une liquidité empruntable s'épuise. Aucune agrégation externe ne restitue ça de façon fiable. Le moteur écrit donc un adaptateur par protocole, qui lit l'état live par appels de lecture gratuits et le normalise en un état de marché commun.
src/defiintel/
cli.py entrée : scan all --persist
pipeline.py orchestration scan → normalisation → persistance
sources/ ★ adaptateurs — la source de vérité
defillama.py découverte par TVL (apyBase / apyReward)
llama_lend.py lend/borrow détaillé (LLTV, borrow APY, liquidité)
aave.py Aave v3 — pool MUTUALISÉ
euler.py Euler v2 — marchés ISOLÉS (adaptateur de référence)
morpho.py Morpho Blue — marchés ISOLÉS, via API GraphQL
assets.py classification des actifs (stable, tier, corrélation)
portfolio_api.py · positions.py · history.py
engine/ ★ mathématiques PURES — aucune entrée/sortie
loop.py gates de faisabilité + ROE / levier / tampon
risk.py grade de risque déterministe
allocate.py allocation sous plafonds
db/ persistance SQLAlchemy → SQLite (Postgres = une URL)
report/markdown.py génère reports/<protocole>_<date>.mdAucune entrée/sortie, aucun réseau, aucun fichier. Conséquences : il est testable, reproductible à l'identique, et réutilisable tel quel par un service web. Un calcul reproductible est un calcul explicable — c'est la même exigence que celle qui tient le LLM hors du chemin critique.
L'ordre est ce qui produit la valeur : un rendement affiché n'est calculé qu'après avoir survécu aux questions qui le rendraient nul.
r_supply > r_borrow) ? Sinon la boucle
détruit du rendement au lieu d'en créer.Capital propre E, LTV cible t avec t ≤ LLTV :
Levier L = 1 / (1 - t)
ROE net = (r_supply - t · r_borrow) / (1 - t)
Tampon de liquidation = 1 - t / LLTV (baisse relative tolérée avant liquidation)À t collé au LLTV, le rendement net explose mais le tampon tend vers zéro. Le
« 202 % » du cas fondateur supposait un levier de 28,5× sans aucune marge : c'est un
nombre de risque, pas un rendement. On entre toujours au ROE safe,
avec t = LLTV · (1 − tampon), jamais au ROE maximal.
| Profil de l'actif | Tampon exigé |
|---|---|
| Blue chip | 3 % |
| Établi | 5 % |
| Stable algorithmique | 10 % |
| Corrélé (collatéral et dette liés) | 25 % |
| Non corrélé | 50 % |
Si les marchés sont isolés — un échec reste contenu au marché — la perte maximale par position est bornée par construction. La règle « au plus 15 % perdus sur un incident » cesse d'être une intention pour devenir une propriété structurelle. Deux attributs sont donc classifiés sur chaque marché :
| Attribut | Valeurs | Lecture |
|---|---|---|
market_isolation | ISOLATED (Euler v2, Morpho Blue) · SHARED (Aave main pool) | Un incident sur un marché isolé n'atteint pas les autres. |
bridge_dependency | chaîne(s) traversée(s) | Le vrai vecteur inter-chaînes : un incident Solana n'atteint l'EVM que via un pont. |
| Protocole | Chaînes | Isolation | Note |
|---|---|---|---|
| Aave v3 | ethereum, arbitrum, base | SHARED | Oracle Chainlink, historique long. |
| Morpho Blue | ethereum, base | ISOLATED | Un marché = (collatéral, dette, oracle, modèle de taux, LLTV), immuable. |
| Euler v2 (EVK) | ethereum | ISOLATED | Ré-audité après l'incident de 2023 (fonds v1 récupérés). Adaptateur de référence. |
| DeFiLlama | — | — | Couche de découverte (lending, TVL ≥ 50 M$), pas une venue de position. |
SQLAlchemy vers SQLite. Le choix n'est pas une contrainte : passer à PostgreSQL est un changement d'URL, sans réécriture. La base historise les instantanés de marché, ce qui permet de comparer un rendement d'aujourd'hui à sa trajectoire plutôt qu'à lui-même.
bureau/dyor-checklist.xlsx — simultanément le moteur de calcul, la source
de vérité et l'interface humaine. Les scores ne sont pas produits par un script ni par un modèle :
ils sont produits par des formules que l'opérateur peut lire et modifier.
| Onglet | Rôle | Écrit par |
|---|---|---|
| DASHBOARD | Tableau de bord déterministe : indicateurs, exposition, portefeuille, à-faire | substrat |
| DYOR ★ | La checklist : une ligne par position, saisie + colonnes calculées | agents + enrichissement |
| ARBITRAGE | Candidats d'arbitrage de funding | scan arbitrage |
| STAKING-DN | Candidats de staking delta-neutre | scan staking-DN |
| LOOPS | Boucles on-chain classées par ROE | scan loops |
| NOUVEAUTÉS | Radar de candidats frais, sans impermanent loss | scan nouveautés |
| SUIVI / ALERTES | Positions suivies · signaux de sortie déclenchés | monitor |
| JOURNAL | Tranche active du journal des décisions | journal |
| HEDGE | Calculateur delta-neutre (marge, liquidation, capital) | manuel |
| Paramètres | Seuils, plafonds, tampons — éditables | manuel |
| PORTFOLIO | Indicateurs de portefeuille (valeur nette, avoirs, exposition nette) | portefeuille |
| EXPOSITION, _WALLET_RAW | Backends masqués, remontés dans le tableau de bord | allocation / portefeuille |
C'est la garantie structurelle du système. Sur l'onglet DYOR — en-têtes en ligne 3, données à partir de la ligne 4, clé en colonne B :
| Bloc | Champs |
|---|---|
| Marché | type, venue, émetteur, tier, corrélé, même actif, hedge, hedge où, coût du hedge, supply, borrow, LLTV, liquidité, incitations, isolé, montant |
| DYOR protocole | audits, oracle, gouvernance/admin, âge, TVL du protocole, code ouvert, mécanisme de pause, documentation, incidents passés |
| Risque de position | pénalité de liquidation, dépendance à un pont, mécanique du peg, dépeg passé, rôle du stable |
| Arbitrage & delta-neutre | colonnes BK→BR : caractéristiques des deux jambes |
Le contrat des agents avait été recopié dans un skill, et les deux copies ont divergé : la copie interdisait les colonnes BK→BR, c'est-à-dire tout report d'audit d'arbitrage — le cœur du projet. D'où la règle « une règle = un endroit ». La copie a toujours tort.
bureau/funding-lab.xlsx est régénéré à chaque cycle et jamais édité à la
main : un onglet comparateur plus un onglet par venue. Il sert à l'analyse visuelle des
statistiques de funding. Toute modification manuelle serait écrasée au cycle suivant.
Deux mécanismes qui, ensemble, rendent la couche d'analyse économiquement viable : l'un compresse l'état pour qu'il tienne dans une lecture courte, l'autre garantit qu'on ne réanalyse jamais deux fois la même chose sans raison.
Le classeur complet représente 20 à 40 000 tokens. Le lire à chaque session serait à la fois coûteux et inutile. Une étape du cycle le comprime en un résumé de 1 à 2 000 tokens :
Deux formes sont produites : tools/STATE.md pour la lecture humaine et par les agents,
tools/state.json pour les interfaces. Le digest est la lecture par défaut de toute
session. Ouvrir le classeur, la base ou les journaux à sa place est une erreur de méthode.
Rien n'est jamais définitivement écarté. Un candidat rejeté aujourd'hui parce que son funding était négatif doit pouvoir revenir quand il ne l'est plus. Une liste noire fige une décision dans un contexte qui a changé.
À la place, chaque décision est enregistrée avec les métriques du moment dans un
journal en ajout seul (tools/ledger.csv). Une position se ré-évalue automatiquement selon
deux critères :
| Déclencheur | Seuil | Intention |
|---|---|---|
| Péremption | verdict plus vieux que 30 jours | Une conclusion vieille d'un mois n'est plus une conclusion. |
| Dérive | APY, funding ou ROE déplacés de plus de 25 % | Le contexte qui motivait le verdict a changé. |
Le passage léger du cycle produit tools/recheck.json : la liste des positions
CHANGED ou GONE, plus des compteurs. C'est la worklist déterministe
des agents. Ce qui n'y figure pas n'est pas retraité — coût nul sur l'inchangé.
Tout candidat audité doit se terminer par exactement un enregistrement de verdict :
py tools/substrate/journal.py --record "pool|nom|stratégie|verdict|raison"avec verdict ∈ { VALIDÉE, REJETÉE, EN ATTENTE }. L'enregistrement calme le drapeau de
ré-évaluation. Sans lui, le candidat réapparaît au cycle suivant et sera ré-audité indéfiniment : c'est
le mécanisme même de la boucle que le journal existe pour empêcher.
| Champ | Pourquoi |
|---|---|
| Identifiant du pool / de la position | Clé de rapprochement avec le classeur. |
| Stratégie | Un même actif peut être candidat sur deux axes avec des conclusions différentes. |
| Verdict + raison | La raison est ce qui permet de relire une décision six mois plus tard. |
| Métriques du moment | C'est contre elles que la dérive est mesurée au cycle suivant. |
| Date | Base du calcul de péremption. |
Le journal est en ajout seul : on n'y corrige jamais une ligne, on en ajoute une nouvelle. Les trimestres clos sont archivés dans des fichiers séparés à chaque cycle, ce qui garde le fichier actif borné sans rien perdre.
Comment le capital se répartit, et pourquoi l'allocateur ne laisse aucune place à l'arbitrage discrétionnaire. L'ordre lui-même est énoncé une seule fois, dans le mandat ; cette page décrit la mécanique qui l'applique.
L'allocateur produit deux vues, et la distinction est essentielle à la lecture :
| Vue | Question à laquelle elle répond |
|---|---|
| POLICY | Ce que la doctrine voudrait allouer si les candidats existaient. |
| ACHIEVABLE | Ce qui est réellement plaçable avec les candidats validés à cet instant et les plafonds. |
L'écart entre les deux est l'information utile : il dit s'il manque des candidats, si un plafond mord, ou si du capital reste non déployé faute d'opportunité au-dessus du plancher.
Le levier n'est jamais un chiffre rond choisi par confort. Il descend d'un modèle par paire, calculé sur l'historique de prix :
levier_max_sûr = 1 / (marge_maintenance + 1,3 × p99_48h) plafonné à ×20
plafond forex : ×10où p99_48h est le 99ᵉ centile du mouvement adverse sur 48 heures. La hiérarchie des
sources est écrite dans la sortie :
| Rang | Source du levier | Effet sur le verdict |
|---|---|---|
| 1 | Modèle propre à la paire | validation possible |
| 2 | Repli sur une valeur de famille (fiat / btc / eth / crypto) | validation interdite |
Un levier de repli signale qu'on ne connaît pas la volatilité réelle de cette paire. Recommander une taille sur cette base reviendrait à inventer une marge de sécurité.
Un levier qu'on ne peut pas alimenter n'est pas un levier sûr. Une position leviérisée exige donc une réserve mobilisable : la veille de marge surveille en continu l'écart entre le prix et le seuil de liquidation, et alerte sur les transitions de niveau plutôt qu'à chaque relevé — une alerte qui se répète cesse d'être lue.
Un rendement composé d'émissions de jetons dépend de la valeur de ces jetons et de la durée du programme. Il est comptabilisé séparément du rendement de base, et il ne peut pas à lui seul faire franchir le plancher de 15 %. Cette séparation existe parce que l'inverse est le mode d'échec le plus courant des tableaux de rendement DeFi.
La stratégie centrale. On tient la même paire long sur la venue où le funding est bas et short sur la venue où il est haut : l'exposition au prix s'annule, il ne reste que l'écart de funding. Fiat d'abord (rang 1), crypto ensuite (rang 2).
Les paires forex perp (EUR/USD, GBP/USD, USD/JPY…) présentent un funding structurellement moins corrélé aux cycles crypto, sur un sous-jacent dont la volatilité est d'un ordre de grandeur inférieure. Le levier sûr y est donc plus élevé à risque égal, et le carry plus stable. C'est ce qui en fait le cœur du projet plutôt qu'un axe parmi d'autres.
La contrepartie est la rareté : peu de venues listent du forex perp, et celles qui le font sont récentes. D'où l'effort disproportionné de couverture décrit dans Le funding lab.
Le scan d'arbitrage écrit l'onglet ARBITRAGE du classeur. Pour chaque paire couverte par au moins deux venues, il calcule la matrice complète des écarts — toutes les combinaisons, pas seulement le meilleur duo — puis classe.
| Grandeur | Définition |
|---|---|
| Écart brut | APR(venue haute) − APR(venue basse), sur la fenêtre 30 jours d'allocation. |
| Écart net | Écart brut moins les frais taker des deux venues, annualisés sur la durée de détention. |
| ROE | Écart net rapporté au capital immobilisé, compte tenu du levier sûr de la paire. |
| Fiabilité | Écart rapporté à la volatilité combinée des deux séries. Sous 1, l'écart est du bruit. |
| Persistance | Part du temps où le funding garde le signe de sa moyenne, par venue. |
| OI par jambe | Open interest disponible : borne le notionnel plaçable. |
Un écart affiché ne devient un candidat qu'après avoir survécu à quatre filtres. Ils existent parce que chacun correspond à une fausse opportunité réellement rencontrée.
| Garde | Rejette |
|---|---|
| Marché vide | OI nul sur une jambe : la venue affiche un taux sur un marché où personne ne traite. La jambe est exclue du classement. |
| Marché trop fin | OI inférieur au minimum exploitable : l'écart existe mais le notionnel plaçable est dérisoire. |
| Historique trop court | Une venue neuve est écartée jusqu'à ce qu'elle ait fait ses preuves. Un écart mesuré sur dix points n'est pas un écart mesuré. |
| Duo fantôme | Un couple dont l'écart spectaculaire vient d'un artefact (une jambe illiquide, un taux non payé, une unité mal convertie). Le contrôle de parité externe sert à les attraper. |
Chaque venue exprime son funding différemment : par période ou par heure, en fraction ou en pourcentage, avec un intervalle de 1 h, 4 h ou 8 h, un horodatage en secondes, millisecondes ou nanosecondes. Une conversion fausse produit un écart de plusieurs centaines de points de base parfaitement crédible. C'est pourquoi un contrôle croisé avec une source externe tourne à chaque cycle : une divergence signale un bug d'unité ou de connecteur, pas une opportunité.
Le rendement retenu est toujours net :
ROE net = (écart_APR − frais_annualisés) × levier_effectif
frais_annualisés = (taker_venue_haute + taker_venue_basse) × 2 × (365 / jours_de_détention)Le facteur 2 couvre l'aller et le retour. Sur une détention courte, les frais dominent : un écart de 3 % annualisé tenu une semaine peut être négatif net. Les taux de frais par venue sont déclarés à la main dans un fichier de configuration, et doivent être sourcés — pas estimés.
La base contient l'historique, pas l'état d'exécution du moment. Avant toute ouverture réelle, l'Auditeur doit valider les deux jambes réelles sur les interfaces live : marché listé, profondeur du carnet, marge exigée, contraintes de retrait, et accessibilité juridictionnelle de la venue.
Stratégie satellite (rang 3, ≤ 20 % du livre). On perçoit un rendement de staking tout en neutralisant l'exposition au prix du jeton par un short perpétuel — à condition que le funding de ce short ne mange pas le rendement.
Le scan cherche l'intersection de deux ensembles : { actifs à bon rendement de staking } ∩ { actifs dont le funding est positif et persistant }. Ni l'un ni l'autre ne suffit :
Avec un levier L sur la jambe courte, le capital se répartit entre la position stakée et
la marge du short :
APY net = L / (L + 1) × ( staking + funding_120j )La fraction L/(L+1) traduit le fait qu'une part du capital finance la marge et ne
travaille pas. Le funding retenu est la moyenne sur 120 jours — assez long pour lisser
un régime passager, assez court pour rester représentatif. Le rendement est aussi calculé en
pire cas (funding le plus défavorable de la fenêtre) : c'est ce chiffre-là qui doit
rester au-dessus du plancher, pas la moyenne.
| Étape | Ce qu'on vérifie | Pourquoi ça peut tuer la position |
|---|---|---|
| 1. Staking réel | taux d'inflation, risque de slashing, durabilité du programme | Un rendement affiché peut être une émission décroissante déjà annoncée. |
| 2. Forme détenue | LST : risque de dépeg et liquidité de sortie. Natif : durée d'unbonding. | Un unbonding de 21 jours rend la sortie impossible quand la couverture casse. |
| 3. Funding de couverture | moyennes 60 / 120 / 180 j multi-venue, part du temps négatif, σ | Un funding mesuré sur une seule venue n'est pas un funding : l'écart entre venues sur le même actif atteint couramment 20 points d'APR. |
| 4. Liquidité de couverture | OI de la venue de short retenue | Une venue au meilleur funding mais au carnet trop fin n'est pas une venue. |
| 5. Levier sûr | liquidation à environ +1/L du prix d'entrée | Un short liquidé transforme une position neutre en position longue nue. |
Le relevé de liquidité des venues de couverture s'exécute avant le scan staking-DN, précisément pour que les venues trop fines soient écartées avant le choix du « meilleur funding ». Inverser l'ordre produirait des recommandations inexécutables.
Le rendement de staking est établi en mode hybride : live quand la source est fiable
(inflation lue sur la chaîne pour l'écosystème Cosmos, rendements de LST via l'agrégateur), sinon
valeur de référence explicitement marquée comme telle. Le principe reste le même que partout :
un chiffre non sourçable est signalé ?, pas estimé.
La Sentinelle surveille les positions ouvertes et distingue un décrochage transitoire (régime de funding passager) d'un décrochage structurel (programme d'émission terminé, inversion durable) — la première recommandation est de tenir, la seconde de sortir.
Rang 4, cible ~30 %. On dépose un actif qui rend, on emprunte contre lui, on redépose, et on recommence : la boucle démultiplie l'écart entre le taux perçu et le taux payé. C'est la stratégie la plus mécanique du livre — et celle où le rendement affiché est le plus trompeur.
À chaque tour, on redépose ce qu'on a emprunté. La série converge :
Levier L = 1 / (1 - t) t = LTV cible
ROE net = (r_supply - t · r_borrow) / (1 - t)
Tampon liquidation = 1 - t / LLTVLe levier n'a pas de limite mathématique quand t tend vers LLTV — et c'est
exactement le problème.
Le rendement n'est calculé qu'après. C'est le principe « faisabilité avant APY » sous sa forme la plus littérale.
r_supply > r_borrow. Sinon chaque tour de boucle
détruit du rendement.Le scan écrit l'onglet LOOPS, classé par ROE incitatif. Pour chaque paire (collatéral, dette) sur chaque protocole : taux de dépôt et d'emprunt, LLTV, liquidité en dollars, incitations, pénalité de liquidation, grade de risque déterministe, et le ROE safe correspondant.
Le grade de risque est calculé par le moteur (module pur), pas par le scan : il y a une seule implémentation, donc une seule définition du risque dans tout le système.
| Couche | Source | Ce qu'elle établit |
|---|---|---|
| Découverte | Agrégateur (DeFiLlama) — lending, TVL ≥ 50 M$ | Ce qui existe et mérite d'être regardé. Large, rapide, approximatif. |
| Vérification | Adaptateur par protocole, lecture directe des contrats | Ce qui est vrai maintenant : éligibilité, LLTV, liquidité réelle. |
Les deux ne sont jamais confondues. Un chiffre d'agrégateur peut ouvrir une piste ; il ne peut pas justifier une position. C'est aussi pour cela que le sourcing primaire est l'appel de lecture on-chain : c'est gratuit, sans clé, et c'est l'état de vérité.
Sur un pool partagé, un incident sur un actif tiers peut atteindre la position. D'où la préférence pour les marchés isolés — critère de premier rang.
Le taux d'emprunt est variable. Une hausse d'utilisation peut le faire passer au-dessus du taux perçu : la boucle devient coûteuse sans qu'on ait rien fait.
Une boucle sur actifs corrélés supporte un tampon de 25 % ; non corrélés, 50 %. Le tampon est l'hypothèse de corrélation.
C'est l'oracle du protocole, pas le marché, qui décide de la liquidation. Sa nature fait partie de l'audit du protocole.
La partie la plus lourde du substrat : collecter, normaliser et qualifier le funding de 27 venues perpétuelles, sur les familles fiat, BTC, ETH et alts. C'est ce qui rend l'arbitrage possible — sans couverture large, il n'y a pas d'écart à mesurer.
| Étape | Ce qu'elle produit |
|---|---|
| Collecte | Un connecteur par venue → base SQLite au schéma unifié (venue, symbole, horodatage, taux, intervalle). Incrémental : on repart du dernier point connu par série. |
| Garde de schéma | Rapport machine par série (ok / vide / erreur). Une série qui devient muette est détectée, pas silencieusement absente. |
| Audit de qualité | Profondeur, complétude par rapport à l'intervalle attendu, trous supérieurs à deux périodes, valeurs aberrantes. |
| Profils de stabilité | Moyenne, écart-type, changements de signe et persistance sur 1 mois / 3 / 6 / 1 an, groupés par famille. |
| Liquidité | Open interest en dollars par venue et par paire — la garde de faisabilité. |
| Levier sûr | Levier maximal par paire, dérivé du centile 99 du mouvement adverse sur 48 h. |
| Matrice des écarts | Toutes les combinaisons de venues par paire, avec écart net, ROE et score de fiabilité. |
| Parité externe | Contrôle croisé de nos taux contre une source tierce. Une divergence signale un bug d'unité, pas une opportunité. |
| Santé | Verdict 🟢/🟡/🔴 par venue : à jour, en retard, muette, vide. |
La venue expose une série paginable. On peut rattraper une coupure : après un arrêt, la prochaine collecte comble le trou. La majorité des venues.
Pas d'historique public : on enregistre le taux courant, de façon idempotente (la clé est l'échéance de funding, pas l'heure d'appel). L'historique se construit à partir de maintenant — et dépend donc d'une collecte qui ne s'arrête jamais.
C'est précisément pour les venues en mode instantané qu'une collecte cloud tourne 24 h/24 indépendamment du PC : une venue en mode instantané perd définitivement les points d'une période d'arrêt.
Chaque venue exprime son funding autrement. Le connecteur ramène tout au schéma unifié ; les pièges rencontrés sont documentés venue par venue :
| Piège | Exemple réel |
|---|---|
| Unité du taux | Fraction sur certaines venues, pourcentage sur d'autres (division par 100 nécessaire). |
| Échelle entière | Taux encodé en 1e9, ou en 1e30 par seconde sur un subgraph. |
| Base temporelle | Taux journalier échantillonné à l'heure, à stocker divisé par 24. |
| Horodatage | Secondes, millisecondes ou nanosecondes selon la venue. |
| Échantillonnage irrégulier | Série à pas variable, à re-bucketiser sur un intervalle fixe. |
| Fenêtre serveur | Fenêtre glissante bornée (30 jours) : le connecteur avance par tranches. |
| Pagination piégeuse | Une limite trop haute renvoie une erreur ; une autre venue ignore les bornes et renvoie toujours le dernier lot. |
| Composante partielle | Sur un protocole, le taux exposé est le funding pur alors que le coût réel ajoute une composante d'emprunt. La différence est signalée à l'Auditeur, jamais fusionnée en silence. |
| Ordre de tri | API renvoyant en ordre décroissant : sans tri de sortie, l'incrémental repart au mauvais point. |
Une adresse de marché mal recopiée dans un connecteur de subgraph renvoyait zéro ligne sans erreur — la venue paraissait simplement calme. Ce mode d'échec (données absentes plutôt que fausses) est la raison d'être de la garde de schéma et du verdict de santé par venue.
Aucune venue n'est branchée d'après sa documentation. La procédure, invariable :
Cette procédure a un coût humain d'environ deux minutes par venue, une seule fois. Le collecteur reste ensuite à zéro token pour toujours.
| Fichier | Lu par |
|---|---|
funding_profiles.json | Agents et humains — stabilité par famille et par venue. Jamais la base directement. |
funding_stats.json | Matrice des écarts + classement de fiabilité. |
funding_liquidity.json | OI par venue et par paire — garde de faisabilité. |
leverage_by_pair.json | Levier maximal sûr par paire. |
funding_health.json | Verdict de santé de la collecte — cockpit et surveillance. |
funding_parity.json | Contrôle croisé externe. |
bureau/funding-lab.xlsx | Classeur de synthèse, régénéré chaque cycle, jamais édité. |
Où en est-on avec chaque venue, techniquement. Le régime juridique, lui, vit exclusivement dans Conformité & juridiction — les deux registres ne se recopient jamais l'un l'autre.
docs/VENUES.md → par quel endpoint on lit cette venue, et quand a-t-il été
testé ?
tools/venues_policy.json → a-t-on le droit d'y exécuter ?
tools/funding_health.json → est-ce que ça marche en ce moment ?
Faire dire à l'un ce qui appartient à l'autre est le mécanisme exact par lequel deux registres
finissent par diverger.
Familles fiat, BTC, ETH et alts. Une seule est un lieu d'exécution autorisé.
Endpoint observé, un blocage technique à lever.
Aucun endpoint observé à ce jour.
Chacune avec une raison datée et une voie de réintroduction, ou l'absence de voie.
| Statut | Signification |
|---|---|
| 🟢 branchée | Un connecteur existe et la venue est collectée à chaque cycle. |
| 🟡 candidate | Un endpoint a été observé mais un blocage précis reste à lever (calibration d'échelle, authentification exotique…). |
| 🔵 à sonder | Aucun endpoint observé ; la découverte réseau reste à faire. |
| ⚪ écartée | Hors périmètre, avec une raison datée. Écartée ≠ définitive : certaines redeviennent accessibles si leur API rouvre. |
| Motif | Explication | Réintroductible ? |
|---|---|---|
| Modèle sans funding | La plateforme facture des frais d'emprunt bilatéraux, pas un funding encaissable. Payé par les deux côtés, donc nul en delta-neutre. | Non — c'est le modèle économique. |
| Pas de série publique | Seul le taux courant est exposé, sans historique ; ou le flux passe par WebSocket / worker inaccessible. | Parfois, en mode instantané si on capture le flux. |
| Lecture on-chain uniquement | Le funding se lit par appel de contrat, hors du schéma REST commun. | Reporté — faisable mais hors du motif d'intégration actuel. |
| API privatisée | L'accès a été fermé, ou la plateforme a changé de marque et ses documents ne sont pas republiés. | À resonder quand l'API rouvre. |
| Anti-robot | Protection qui bloque tout accès programmatique. | Faible priorité. |
| Aucune paire utile | Notamment : aucune paire forex perpétuelle, alors que c'est le cœur du projet. | Non pour le forex. |
| Juridictionnel | Nouveau depuis le 4 août 2026 — voir Conformité. | Seulement si le statut réglementaire change. |
Certaines plateformes bloquent l'accès depuis la France (résolution de nom détournée, redirection vers une page vitrine). Elles sont marquées comme telles et exemptées des alertes de collecte locale : leur absence sur le PC n'est pas une panne. La collecte cloud, exécutée depuis une autre région, les couvre.
Ce géoblocage est d'ailleurs une information en soi : une plateforme qui se ferme explicitement à un pays a des raisons de le faire, et cela recoupe le registre de conformité.
Sans historique public, l'historique se construit à partir de maintenant. Une période d'arrêt de la collecte est une perte définitive. C'est pour elles que la collecte cloud toutes les 4 h est indispensable, pas seulement confortable.
Elles sont documentées plutôt que corrigées en silence, parce qu'une correction silencieuse fabrique une donnée qui n'existe pas :
Quelles venues peuvent porter une jambe réelle depuis la France — et pourquoi la question « cette venue a-t-elle MiCA ? » ne suffit jamais à y répondre. Cette page a été créée le 4 août 2026 après le retrait de Gate.io.
MiCA ne couvre pas les dérivés. Un contrat perpétuel est un instrument financier : il relève de MiFID II, pas de MiCA. Un agrément CASP MiCA autorise le comptant, la conservation, l'échange et le transfert de crypto-actifs — il n'autorise pas à proposer un perp. Vérifier « MiCA » sur une venue de perps, c'est vérifier le mauvais registre.
Le portefeuille de venues du projet est composé à plus de 90 % de DEX non-custodial. Ces plateformes ne sont pas « non conformes MiCA » : elles sont hors du champ de MiCA, qui exclut explicitement les services fournis de manière pleinement décentralisée, sans intermédiaire. Aucune d'elles ne dispose d'une autorisation MiFID pour proposer des dérivés en France.
Appliquée à la lettre, la règle « seules les venues titulaires d'une autorisation dérivés » ne laisse qu'une venue exécutable sur les 36 branchées — Kraken. Or un arbitrage a deux jambes sur deux venues : sous cette lecture, la stratégie cœur du projet n'est pas plus étroite, elle est structurellement impossible. Ce n'est pas une projection : c'est le résultat du contrôle exécuté le 4 août 2026.
Le registre ne tranche donc pas seul : il expose un curseur unique, la posture,
déclarée dans venues_policy.json et appliquée par le contrôle du cycle.
| Posture | Admet | Venues exécutables |
|---|---|---|
mifid-strict | Uniquement les venues à autorisation MiFID II dérivés. | 1 / 36 — arbitrage cross-venue impossible |
cex-agrees-dex-propre-compte active | CEX : autorisation dérivés exigée. DEX non-custodial : admis au titre du compte propre. | 26 / 36 |
tout | Aucun filtre. | 36 / 36 — analyse hors périmètre d'exécution |
La posture active trace la ligne sur la conservation des fonds, pas sur le pavillon de la plateforme :
La notion de « pleinement décentralisé » n'est pas définie à ce jour : son appréciation revient aux autorités nationales et aux orientations à venir de l'ESMA. La posture active est un choix d'opérateur documenté et daté, pas une certitude juridique. Elle se change en une ligne, et le contrôle du cycle répercute immédiatement le nouveau périmètre sur ce que l'Auditeur a le droit de dimensionner.
Le registre sépare deux rôles qui étaient confondus jusqu'ici :
On lit un taux de funding public. Aucun compte n'est ouvert, aucun service financier n'est reçu, aucun fonds n'est déposé. Lire un prix n'est pas une opération réglementée.
On y ouvrirait une jambe réelle avec du capital. C'est ce rôle qui exige une autorisation, et
c'est le champ execution du registre qui fait foi.
Une venue peut donc rester une source de données parfaitement légitime — et utile, puisque son funding sert de référence de comparaison — sans jamais devenir un lieu d'exécution. C'est cette distinction qui permet de garder un observatoire large tout en restreignant l'exécution.
Tableau généré à la construction depuis tools/venues_policy.json : il ne peut pas
diverger de ce que le contrôle applique.
| Venue | Type | MiCA CASP | MiFID II dérivés | Rôle | Précision |
|---|---|---|---|---|---|
| Kraken Futures | CEX | oui | oui | exécution autorisée | Payward Europe Digital Solutions (CY) Ltd — entreprise d'investissement MiFID, CySEC n° 342/17 (acquise 02/2025), perps multi-collatéral ouverts à l'EEE |
| Aevo (ex-Ribbon) | DEX non-custodial | hors champ | non | données seulement | |
| Antarctic | CEX | non vérifié | non | données seulement | |
| ApeX Omni | DEX non-custodial | hors champ | non | données seulement | DNS géo-sinkholé FR/US — géoblocage explicite côté venue. |
| ApolloX | CEX | non vérifié | non | données seulement | |
| Aster (ex-APX/ApolloX) | DEX non-custodial | hors champ | non | données seulement | |
| Backpack | CEX | non vérifié | non | données seulement | |
| Binance Futures | CEX | non vérifié | non | données seulement | |
| BitMEX | CEX | non vérifié | non | données seulement | |
| Bluefin (Sui) | DEX non-custodial | hors champ | non | données seulement | Application géo-bloquée depuis la France. |
| Bullbit | DEX non-custodial | non vérifié | non | données seulement | |
| Bybit | CEX | oui (Autriche, 2025) | non | données seulement | CASP MiCA = spot/conservation uniquement ; les perps restent hors autorisation FR. |
| Deribit | CEX | non vérifié | non | données seulement | |
| Derive (ex-Lyra v2) | DEX non-custodial | hors champ | non | données seulement | |
| dYdX v4 | DEX non-custodial | hors champ | non | données seulement | |
| edgeX | DEX non-custodial | hors champ | non | données seulement | |
| Ethereal | DEX non-custodial | hors champ | non | données seulement | |
| Evedex (L3 Arbitrum) | DEX non-custodial | non vérifié | non | données seulement | |
| Extended (StarkNet) | DEX non-custodial | hors champ | non | données seulement | |
| GMTrade (GMX v2 Solana) | DEX non-custodial | hors champ | non | données seulement | |
| GMX v2 (Arbitrum) | DEX non-custodial | hors champ | non | données seulement | |
| GRVT | DEX non-custodial | non vérifié | non | données seulement | |
| Hibachi | DEX non-custodial | hors champ | non | données seulement | |
| Hyperliquid (main dex) | DEX non-custodial | hors champ | non | données seulement | |
| Hyperliquid builder-dex xyz (forex) | DEX non-custodial | hors champ | non | données seulement | |
| HTX (ex-Huobi) | CEX | non vérifié | non | données seulement | |
| Hyperliquid (alias funding_history) | DEX non-custodial | hors champ | non | données seulement | |
| Katana Perps | DEX non-custodial | hors champ | non | données seulement | |
| KuCoin Futures | CEX | non vérifié | non | données seulement | |
| Lighter | DEX non-custodial | hors champ | non | données seulement | |
| Nado (fork Vertex, Ink L2) | DEX non-custodial | hors champ | non | données seulement | |
| OKX | CEX | oui (Malte, 2025) | non | données seulement | Idem Bybit : CASP ≠ dérivés. |
| Orderly Network (= citrex) | DEX non-custodial | hors champ | non | données seulement | |
| Pacifica | DEX non-custodial | hors champ | non | données seulement | |
| Paradex | DEX non-custodial | hors champ | non | données seulement | |
| Vest Markets | DEX non-custodial | hors champ | non | données seulement |
| Venue | Retirée le | Motif |
|---|---|---|
| Gate.io / Gate Europe | 2026-08-04 | Décision opérateur : futures interdits depuis la France faute d'autorisation dérivés. Gate détient bien un agrément MiCA CASP (Gate Technology Ltd, MFSA Malte, 29/09/2025) et une licence d'établissement de paiement (juin 2026), mais MiCA ne couvre PAS les dérivés et Gate n'a pas d'autorisation MiFID pour la clientèle de détail française. |
Une étape du cycle, CONFORMITE (tools/funding/venue_compliance.py),
compare la réalité du code au registre :
| Contrôle | Verdict si échec |
|---|---|
| Toute venue branchée figure au registre | 🔴 — on ne branche pas une venue sans déclarer son régime |
| Aucune venue exclue n'a été rebranchée | 🔴 — attrape la réintroduction accidentelle |
| Statut vérifié depuis moins de 180 jours | 🟡 — les agréments bougent |
| Recensement des venues non exécutables | informatif — la liste est publiée à chaque cycle |
Le verdict est écrit dans tools/venues_compliance.json. Le contrôle ne fait aucun appel
réseau : il est instantané et ne peut pas échouer pour une raison étrangère à son objet.
Gate.io a été collectée et proposée pendant des mois. Le défaut n'était pas une erreur de jugement : c'était une absence de champ. Le statut juridictionnel d'une venue n'existait nulle part dans le système — donc il ne pouvait pas être faux, il pouvait seulement être oublié. Créer le champ et le rendre obligatoire est la seule correction qui empêche la récidive ; retirer une venue n'aurait corrigé que le symptôme.
Ce registre est une aide opérationnelle sourcée et datée, pas un avis juridique. Les statuts évoluent. Avant d'ouvrir un compte, vérifier au registre ESMA (agréments CASP) et au registre des entreprises d'investissement (MiFID).
Toutes gratuites, une seule en formule freemium avec clé. Aucune donnée n'est devinée : tout chiffre critique est sourcé, recoupé, cité et daté.
| Donnée | Source | Consommée par |
|---|---|---|
| État on-chain des boucles (collatéral, LLTV, taux, liquidité) | Appels de lecture RPC par protocole — adaptateurs Aave / Euler / Morpho | moteur on-chain |
| Découverte de rendements et de marchés de prêt | DeFiLlama — yields.llama.fi/pools, /lendBorrow, api.llama.fi/protocols | nouveautés, enrichissement, staking-DN, loops |
| Prix et dépeg | coins.llama.fi | portefeuille, monitor |
| Funding perpétuel — 27 venues | Un endpoint par venue (REST ou subgraph), relevé par découverte réseau | funding lab → arbitrage, staking-DN, enrichissement, monitor |
| Open interest par venue et par paire | Endpoints publics de chaque venue | gardes de faisabilité |
| Contrôle croisé des taux | Agrégateur de dérivés externe (CoinGecko) | contrôle de parité |
| Staking et inflation Cosmos | rest.cosmos.directory/{chaîne} (LCD) | staking-DN, portefeuille |
| Portefeuille EVM (valeur nette, jetons, positions DeFi) | Moralis — seule source à clé | portefeuille, positions |
| Portefeuille Solana | Moralis (soldes) + SonarWatch (positions DeFi) | portefeuille |
| Portefeuille Cosmos | rest.cosmos.directory/cosmoshub | portefeuille |
| Positions perpétuelles sur exchange centralisé | ccxt, clés en lecture seule — no-op si aucune clé | portefeuille (exposition nette exacte) |
Elle vaut pour tout chiffre qui entre dans une décision :
? et drapeau. Jamais une estimation présentée comme
une mesure.| Rang | Type | Confiance | Usage |
|---|---|---|---|
| 1 | Lecture on-chain directe (appel de contrat) | 🟢 | Établir un fait : éligibilité, LLTV, liquidité. C'est l'état de vérité. |
| 2 | API officielle de la venue | 🟢 | Funding, OI, listing. Testée en direct, jamais reprise d'une documentation. |
| 3 | Agrégateur (DeFiLlama, CoinGecko) | 🟡 | Découvrir des pistes et recouper. Ne justifie jamais une position à lui seul. |
| 4 | Documentation du protocole | 🟡 | Comprendre un mécanisme. Souvent en retard sur le déployé. |
| 5 | Communication du projet, réseaux sociaux | 🔴 | Signal faible. Ne peut ni établir ni infirmer un chiffre. |
Un agrégateur normalise, et normaliser c'est interpréter. Sur certaines venues, la normalisation d'un taux de funding est incohérente — un écart massif avec notre propre lecture ne signifie donc pas qu'on a tort. Le contrôle de parité sert à lever une alerte, pas à trancher : un écart déclenche une inspection, pas une correction automatique.
Une seule source exige une clé (Moralis, formule gratuite). Elle est stockée dans le fichier de secrets, jamais dans le dépôt en clair. Tout le reste est public et sans authentification — c'est un choix d'architecture : une dépendance payante sur le chemin critique aurait transformé une panne de facturation en panne de système.
Chaque fichier d'état porte sa date de génération, et l'assertion de fin de cycle vérifie la fraîcheur de tous. Une donnée périmée est signalée comme telle dans le digest et sur le cockpit : lire un chiffre vieux de trois jours en croyant qu'il est de ce matin est un mode d'échec plus dangereux que l'absence de chiffre.
Cinq agents Claude, chacun avec un périmètre étroit et des droits d'écriture limités. Ils forment la couche de jugement : ce que le substrat déterministe ne peut pas produire — lire une documentation, recouper une source, qualifier une gouvernance, trancher.
| Agent | Rôle | Modèle | Lit | Écrit |
|---|---|---|---|---|
| Éclaireur | Tri léger des candidats frais → liste courte de 3 à 5 à auditer | Sonnet | digest, worklist | journal — EN ATTENTE uniquement |
| Auditeur ★ | DYOR profond, faisabilité avant APY, aux sources | Opus | worklist, journal, documentations, audits, explorateurs, API | cellules de saisie DYOR + note d'audit + un verdict |
| Sentinelle | Garde des positions détenues : transitoire ou structurel ? | Sonnet | suivi, alertes, positions détenues | verdict si une position doit sortir ou attendre |
| Stratège | Synthèse hebdomadaire de la posture face à la doctrine | Opus | exposition, digest, positions détenues | note de posture |
| Cartographe | Veille hebdomadaire des venues à brancher ou débrancher | Sonnet | recensement déterministe des venues | fiche de veille + qualification des venues fraîches |
Opus pour réfléchir — l'audit profond et la posture, où la qualité du raisonnement décide du résultat. Sonnet pour trier et orchestrer — le tri de candidats, la garde et la coordination, où le volume compte plus que la finesse. C'est une décision de coût assumée, pas un défaut : envoyer un tri de vingt candidats à un modèle de raisonnement serait dépenser sans gagner.
Chaque agent charge d'abord un socle partagé — le contrat et la méthode d'audit — avant d'agir. La doctrine du projet prime sur tout ce que ce socle pourrait dire.
Le contrat avait été dupliqué dans le socle. Les deux copies ont divergé, et c'est la copie qui avait tort : elle interdisait les colonnes d'arbitrage, soit le cœur du projet. Depuis, le socle renvoie à la doctrine au lieu de la redire. Un skill qui redit une règle est traité comme un bug.
| Agent | Ne fait PAS |
|---|---|
| Éclaireur | Pas d'audit profond, pas de verdict VALIDÉE ni REJETÉE. Il ouvre des dossiers, il ne les tranche pas. |
| Auditeur | Ne recalcule ni score ni allocation. Ne décide pas d'exécuter. |
| Sentinelle | Ne cherche pas de candidats. Elle ne regarde que ce qui est détenu. |
| Stratège | Ne recalcule pas l'allocation (déterministe) et ne challenge pas la cible. |
| Cartographe | Ne recense pas de pools, n'écrit aucun connecteur, ne décide rien. |
Ce découpage évite le mode d'échec classique des systèmes multi-agents : deux agents qui se répondent l'un à l'autre. Ici, le seul lien entre deux agents passe par un fichier d'état écrit sur disque — jamais par une conversation.
Les obligations que tout agent accepte avant d'agir. Elles vivent à un seul endroit
(CLAUDE.md) ; cette page les explique, elle ne les redéfinit pas. Chacune existe parce
qu'une erreur réelle l'a rendue nécessaire.
Un rendement affiché ne vaut rien tant que la position n'est pas constructible. On vérifie l'ordre des gates avant de calculer quoi que ce soit. Voir le moteur et les loops.
Ne jamais recalculer un score ni une allocation. Les agents remplissent uniquement les cellules de
saisie du classeur — D→AG, plus BK→BR pour l'arbitrage et le delta-neutre —
et jamais les colonnes calculées, ni la clé, ni le statut (décision humaine).
Le helper d'écriture refuse techniquement une colonne calculée. Un agent qui se tromperait n'obtiendrait pas un mauvais score : il obtiendrait une erreur.
Tout APY et tout funding est sourcé en direct et multi-venue, jamais deviné. Recouper au moins deux
sources, retenir la pire en cas de divergence, citer et dater. Confiance 🟢/🟡/🔴 sur chaque donnée.
Introuvable ⇒ ? plus un drapeau. Un drapeau rouge prime sur un APY élevé.
Détail : Sources de données.
Tout candidat audité se termine par exactement un enregistrement au journal : VALIDÉE REJETÉE EN ATTENTE, avec sa raison. Sans lui, le candidat reviendra au cycle suivant et sera ré-audité indéfiniment. Voir la mémoire anti-boucle.
La worklist déterministe borne le périmètre. Ce qui n'a pas bougé n'est pas relu : c'est ce qui rend la couche d'analyse abordable. Un agent qui « vérifie quand même » dépense sans produire.
Un seul écrivain du classeur à la fois, et toute écriture passe par une sauvegarde atomique. Deux agents écrivant simultanément corrompraient le fichier ; une interruption au mauvais moment aussi.
Les agents recommandent par écrit, dans le classeur et dans le journal. Ils n'exécutent rien et ne publient rien eux-mêmes.
Un agent qui publie lui-même court-circuite la parité entre les surfaces : le cockpit, Discord et le classeur cesseraient de montrer les mêmes chiffres. Il écrirait aussi hors du dépôt, donc hors de toute traçabilité. La diffusion est faite par le substrat, à partir des mêmes fichiers d'état.
Tout dimensionnement part du capital réel observé. Une validation avec levier doit citer le levier, sa source (modèle propre à la paire — un repli sur une valeur de famille interdit la validation) et le notionnel maximal borné par l'open interest.
py tools/substrate/journal.py --record "pool|nom|stratégie|verdict|raison"| Champ | Attendu |
|---|---|
pool | Identifiant stable, qui servira de clé au rapprochement. |
nom | Libellé lisible. |
stratégie | L'axe concerné — un même actif peut avoir deux verdicts distincts sur deux axes. |
verdict | VALIDÉE · REJETÉE · EN ATTENTE |
raison | Une phrase qui doit rester compréhensible six mois plus tard, sans le contexte de l'audit. |
Faisabilité vérifiée aux sources, rendement net ≥ 15 %, dimensionnement chiffré avec sa source de capital et de levier. Ce n'est pas un ordre : l'humain décide.
Gate de faisabilité non franchie, drapeau rouge, ou rendement net sous le plancher. La raison doit dire lequel — « pas intéressant » n'est pas une raison.
Donnée manquante, source indisponible, ou audit à faire. C'est le verdict par défaut de l'Éclaireur : il signale un dossier, il ne le conclut pas.
La séquence que suit l'Auditeur. Elle est ordonnée de sorte que les questions capables d'annuler la position se posent avant celles qui la valorisent — c'est le principe « faisabilité avant APY » traduit en procédure.
(supply − t·borrow)/(1−t) avec
t = LLTV·(1−tampon).+1/L du prix d'entrée.L/(L+1) × (staking + funding_120j), plus le calcul en
pire cas — c'est celui-là qui doit passer le plancher.| Critère | Ce qu'on cherche | Drapeau rouge |
|---|---|---|
| Audits | Cabinets, dates, périmètre, correctifs appliqués | Aucun audit, ou audit portant sur une version antérieure au déployé |
| Oracle | Fournisseur, mécanisme de repli, fréquence | Oracle interne sans repli, ou prix issu d'un pool manipulable |
| Gouvernance | Qui peut modifier les paramètres, délai avant application | Clé d'administration sans délai (timelock) ni multi-signature |
| Âge et TVL | Durée d'exploitation, ordre de grandeur des encours | Très récent avec une TVL très élevée — croissance non éprouvée |
| Code ouvert | Contrats vérifiés et lisibles | Contrat non vérifié |
| Pause | Existence d'un mécanisme d'arrêt et qui le détient | Aucun arrêt possible, ou arrêt détenu par une clé unique |
| Incidents | Historique, montants, indemnisation, correctifs | Incident non résolu, ou aucune communication publique |
| Critère | Question |
|---|---|
| Pénalité de liquidation | Combien perd-on si la liquidation se déclenche ? Elle borne la perte réelle, pas le tampon. |
| Dépendance à un pont | La position traverse-t-elle une chaîne ? Le pont est le vrai vecteur inter-chaînes. |
| Mécanique du peg | Sur-collatéralisé, algorithmique, adossé hors chaîne ? Chaque mécanique a son mode de rupture. |
| Dépeg passé | Ampleur et durée. Un actif ayant décroché une fois peut décrocher à nouveau. |
| Rôle du stable | Collatéral, dette ou marge ? Le même dépeg n'a pas le même effet selon la place. |
| Corrélation | Collatéral et dette bougent-ils ensemble ? C'est l'hypothèse que le tampon encode. |
Chaque audit produit un fichier versionné dans reports/. C'est ce qui permet de relire
une décision plus tard et de comprendre sur quoi elle reposait — pas seulement ce qu'elle
concluait. Elle contient au minimum :
Si un lecteur ne peut pas rouvrir les sources citées et refaire le calcul, la note n'a pas rempli sa fonction. C'est la raison pour laquelle les URL et les dates sont obligatoires, et pas seulement recommandées.
Quatre façons de lire le même état, et une seule vérité derrière. Une surface qui contredirait une autre est traitée comme un défaut, pas comme une variante d'affichage.
| Surface | Où | Pour quoi | Disponible PC éteint |
|---|---|---|---|
| Cockpit local | serveur local, port 8799 | Pilotage complet : lancer des runs, suivre les agents en direct, tout consulter | non |
| Snapshot Cloudflare | Cloudflare Pages | Consultation des analyses, sans backend — et cette documentation | oui |
| Discord | serveur privé | Tableaux vivants + notifications d'alerte | oui |
| Classeur Excel | fichier local | Interface d'édition et de décision de l'opérateur | non |
Une application web légère : serveur Python en façade des fichiers d'état, page unique en thème sombre. Ce qu'elle expose :
| Zone | Contenu |
|---|---|
| Indicateurs | Part déployée, APY net mixé, backlog, positions à ré-auditer. |
| Agents | Une carte par agent : modèle, outils, sources, statut. Lancement d'un run. |
| Flux en direct | Relais temps réel de l'exécution d'un agent — on voit ce qu'il fait pendant qu'il le fait. |
| Verdicts | Les derniers verdicts, un par position (le plus récent gagne). |
| Funding lab | Séries de funding tracées, avec l'APR au survol, et la matrice des écarts. |
| Commandes | Panneau groupé : analyse, données, documents. Les commandes qui écrivent sont mises en file d'attente si le cycle tient le verrou. |
| Santé | Verdicts de collecte, de cycle et de conformité, plus l'historique des exécutions. |
Voit tout, lance les runs, déclenche les commandes qui écrivent.
Portefeuille, positions et classeur DYOR sont retirés du payload — pas masqués par CSS. Un viewer ne peut pas voir ce qui ne lui est jamais envoyé.
Un mode lecture seule global existe également. La protection contre les tentatives répétées est active sur l'authentification.
Le cockpit vivant a besoin d'un serveur Python. Pour rester consultable PC éteint, une étape du cycle pré-calcule tout ce qu'un viewer verrait en fichiers JSON figés, plus une page autonome qui les lit. Plus aucun serveur n'est requis, et le déploiement est repoussé à chaque cycle — ce qui garantit que le contenu publié n'est jamais périmé de plus de quatre heures.
Quiconque a l'URL voit la page, et le cache peut survivre à un retrait. Par défaut, le snapshot applique donc exactement la restriction du rôle viewer : portefeuille, positions et classeur ne sont jamais écrits dedans. Un mode privé existe, mais c'est une décision explicite qui doit s'accompagner d'un contrôle d'accès en amont.
Le site que vous lisez est construit dans le même dossier de publication, sous /docs.
Conséquences :
Le cockpit se lance par un raccourci de bureau. Le lanceur est auto-actualisant : il récupère la dernière version du code, coupe l'instance précédente, attend que le serveur réponde, puis ouvre le navigateur. Un mode hors-ligne existe. En cas d'erreur, la fenêtre reste ouverte — un lanceur qui se referme sur un échec ne dit rien de ce qui s'est passé.
Les chiffres publiés sur Discord proviennent de la même fonction que ceux affichés par le cockpit. Ce n'est pas une convention de développement : c'est ce qui rend la parité vérifiable. Deux implémentations d'un même indicateur finissent toujours par diverger, et la divergence est découverte au pire moment.
La surface qui reste disponible quand le PC est éteint et qu'on n'a que son téléphone. Entièrement produite par le substrat, à zéro token : c'est du Python qui met en forme des fichiers déjà écrits, pas un modèle qui rédige.
Chaque salon contient un seul message, réédité en place à chaque cycle. Pas de flux, pas d'historique à remonter, pas de notification toutes les quatre heures. On ouvre le salon, on voit l'état actuel.
Le salon d'alertes est republié en bas quand son contenu change. Une alerte doit prévenir ; si elle restait ancrée à sa date de première publication, elle disparaîtrait sous les messages plus récents au moment précis où elle devient pertinente.
| Tableau | Contenu |
|---|---|
| État | Indicateurs du portefeuille, part déployée, rendement mixé. |
| Rayon | Les candidats validés en attente de décision — ce qu'il y a « en rayon ». |
| Alertes | Veille de ROE des positions ouvertes : approche du plancher, dérive contre la médiane 7 jours. |
| Portefeuille | Valeur nette, avoirs, exposition nette par sous-jacent. |
| Cycle | Verdict de fin de cycle : étapes exécutées, fraîcheur, publications. |
| Rapports d'agents | Dernières notes de la Sentinelle et du Stratège, plus le digest d'audit. |
Les chiffres proviennent de la même fonction que celle qui alimente le cockpit — c'est ce qui rend la parité entre les deux surfaces vérifiable plutôt que promise.
Le salon d'alertes lit uniquement la veille de ROE des positions choisies et ouvertes. C'est une correction : il lisait auparavant un fichier qui mêlait candidats à l'audit et exposition comptant. Une alerte sur une position qu'on ne détient pas n'est pas une alerte — c'est du bruit, et le bruit finit par faire ignorer le canal entier.
Le digest d'audit sort en code 42 quand il n'y a rien de neuf depuis le précédent. Le cycle interprète ce code et ne publie pas. Republier un contenu identique à chaque cycle apprendrait au lecteur à ne plus regarder.
Au-delà de la publication, un bot permet la consultation et le déclenchement depuis Discord :
Les scripts Python impriment en UTF-8. Sans forçage explicite de l'encodage de la console, PowerShell décodait leur sortie en codage hérité : « VALIDÉE » devenait « VALIDÉE » dans le journal et dans tout ce qui transitait par un tube — donc jusque dans Discord.
Deux règles en découlent, appliquées partout : l'encodage de sortie est forcé en tête du cycle, et le digest d'audit est écrit sur disque puis relu en UTF-8 plutôt que passé par un tube.
Ce que le système détient, ce qu'il ne détiendra jamais, et comment les accès sont protégés. Le principe fondateur tient en une ligne : aucune clé privée, jamais.
Aucune clé privée de portefeuille n'existe nulle part dans le système. Ce n'est pas une politique : c'est une absence de capacité.
Les clés d'exchange sont créées en permission Read uniquement. Le code n'émet que des appels de lecture.
Le droit de retrait n'est jamais accordé à une clé. Quand la plateforme le permet, l'adresse IP de la machine est en liste blanche.
Les agents n'ont aucun canal de diffusion propre. Toute publication passe par le substrat.
| Secret | Nature | Portée du risque |
|---|---|---|
| Adresses de portefeuille | Publiques par nature | Vie privée : elles révèlent des montants. |
| Clé d'API de données (Moralis) | Freemium | Quota consommé par un tiers. Révocable. |
| Clés d'exchange en lecture seule | Lecture | Divulgation de positions et de soldes. Aucun mouvement possible. |
| Webhooks Discord | URL d'écriture | Un tiers pourrait publier dans le salon. Révocable. |
| Clés d'accès au cockpit | Rôle + secret | Lecture de l'état selon le rôle. |
Aucun de ces secrets ne permet de déplacer de la valeur. C'est le résultat direct du choix « lecture seule partout » : la surface de compromission est réduite à de la divulgation, jamais à de la perte.
Un fichier de secrets local, jamais commité. Sur la machine cloud, ce fichier n'existe pas en clair : une version chiffrée est commitée, et la clé privée de déchiffrement vit hors du dépôt, montée à l'exécution.
Le code ne lit jamais le fichier de secrets directement. Tout passe par une fonction unique du module de démarrage, qui choisit la source selon la machine — clair en local, déchiffré sur la machine cloud. Un point d'entrée unique est ce qui permet de changer la méthode de stockage sans toucher trente scripts.
Un outil dédié gère le cycle de vie : initialisation de la clé, chiffrement, vérification que le chiffré correspond bien au clair, ajout d'une machine, rotation. La vérification sort avec un code distinct selon l'échec — un secret non déchiffrable et un secret désynchronisé ne se corrigent pas de la même manière.
| Mécanisme | Usage |
|---|---|
| Mode lecture seule global | Coupe toute commande mutante, quel que soit le visiteur. |
| Clés nommées avec rôle | operator ou viewer, une clé par personne, stockée en cookie. Protection contre les tentatives répétées. |
| Tunnel éphémère | Partage ponctuel en lecture seule, sans ouvrir de port. |
| Contrôle d'accès en amont | Pour refermer un site publié : l'authentification se fait avant d'atteindre la page. |
Un site de pages statiques est public : quiconque a l'URL y accède, et le cache peut survivre au retrait d'un contenu. Le snapshot applique donc par défaut la restriction du rôle viewer — portefeuille, positions et classeur ne sont jamais écrits dedans. Le mode privé existe mais exige un contrôle d'accès en amont ; il ne doit jamais être activé « pour essayer ».
La publication de l'état sur GitHub utilise une liste blanche explicite de chemins. Jamais d'ajout global. La conséquence voulue : un fichier non suivi contenant des données de portefeuille, ou un secret déposé par erreur dans le dossier de travail, ne peut pas partir par inadvertance.
Comment le système détecte qu'il est cassé, et comment il se reconstruit depuis zéro. Le principe : une panne silencieuse est pire qu'une panne bruyante, donc tout est conçu pour prouver qu'il a fonctionné plutôt que pour supposer qu'il fonctionne.
Un cycle qui échoue à moitié laisse un système qui semble sain : des fichiers existent, le cockpit affiche des chiffres, ils sont simplement périmés. Deux pannes réelles ont mis des semaines à être vues — un déploiement qui ratait à chaque cycle, et un scan qui n'ouvrait plus sa base. Les deux échouaient sans rien signaler.
D'où l'assertion de fin de cycle :
| Contrôle | Question posée |
|---|---|
| Étapes | Toutes les étapes attendues ont-elles été exécutées ? |
| Fraîcheur | Chaque fichier d'état a-t-il été réécrit dans ce cycle ? |
| Publication GitHub | L'état a-t-il été publié au cycle précédent ? |
| Publication Discord | Les tableaux ont-ils été réédités au cycle précédent ? |
| Santé de la collecte | Les venues répondent-elles ? |
| Conformité des venues | Toute venue branchée déclare-t-elle son régime ? |
Le verdict est publié avec l'état, et l'assertion sort toujours en succès : elle rapporte, elle ne bloque pas. Un contrôle qui interromprait le cycle empêcherait la publication du diagnostic — exactement l'inverse du but recherché.
Une surveillance externe indépendante s'exécute toutes les 4 h et relit deux verdicts publiés : celui de la collecte et celui du cycle. Si aucun verdict frais n'est arrivé depuis 9 heures, elle ouvre automatiquement un ticket ; elle le referme quand la situation redevient normale.
Toutes les autres surveillances tournent dans le cycle : elles ne peuvent rien signaler si le cycle ne démarre pas. Celle-ci détecte l'absence, pas l'erreur. C'est une différence de nature.
| Exécuteur | Rythme | Couvre |
|---|---|---|
| PC Windows | 4 h (tâche planifiée) | Cycle complet, y compris le classeur et le portefeuille. |
| Machine cloud | 4 h (conteneur toujours allumé) | Idem, sans dépendre de l'allumage du PC. |
| Intégration continue | 4 h | Collecte du funding seule, depuis une autre région : couvre les venues en mode instantané et les venues géo-sensibles. |
Les données collectées par l'intégration continue sont poussées sur une branche dédiée et fusionnées localement de façon idempotente. Une venue à historique se rattrape seule après une coupure ; une venue en mode instantané ne peut pas — c'est pour elle que cette redondance existe.
Une synchronisation automatique tourne toutes les cinq minutes environ. Elle est prudente : elle saute si un cycle est en cours ou si l'arbre de travail est modifié. Elle ne fait qu'un rapatriement en avance rapide, jamais de fusion.
La publication de fin de cycle joue ici un rôle discret mais essentiel : en committant l'état régénéré, elle garde l'arbre propre. Sans elle, les fichiers suivis réécrits à chaque cycle bloqueraient toute mise à jour, et le poste resterait coincé sur une version ancienne du code sans que rien ne l'indique.
| Donnée | Sauvegarde |
|---|---|
| Base de funding | Copie hebdomadaire compressée, rotation sur 6 générations, prise avant la collecte. |
| Classeur | Copie de sécurité à chaque écriture atomique. |
| Journal des décisions | Versionné dans Git ; les trimestres clos sont archivés à part. |
| Notes d'audit et postures | Versionnées dans Git. |
| État machine | Publié à chaque cycle sur GitHub. |
| Secrets | Version chiffrée commitée ; clé privée hors dépôt, à sauvegarder séparément. |
Scénario : PC volé, ou compte compromis. Un document de reprise inventorie tout ce qui est automatisé, tous les secrets et toutes les données, avec la procédure de recréation. Les points d'attention :
Un clone du dépôt avait été créé à l'intérieur du dépôt. Du travail y a été appliqué et perdu de vue pendant six jours. Si un clone est nécessaire, il vit ailleurs. Le local fait foi ; GitHub est une sauvegarde, pas un lieu d'édition.
Tout fichier ou réglage touché en dehors du dépôt — tâche planifiée, dossier de démarrage, base de registre, dossier de données applicatives — doit être inscrit dans le registre des éléments externes. Rien d'externe n'existe sans y être écrit. C'est ce registre qui rend la reprise possible : sans lui, on reconstruit le code mais pas ce qui le déclenche.
Chaque choix structurant est consigné avec sa raison et sa date dans
docs/DECISIONS.md. Cette page en donne la lecture par thème — le registre complet fait
foi, y compris les décisions abandonnées, qu'on ne supprime pas.
Une décision annulée explique pourquoi une piste évidente n'a pas été prise. Sans elle, la même idée revient tous les six mois et coûte le même travail d'exploration. L'exemple typique du projet : une stratégie de rendement fixe, longuement instrumentée, puis abandonnée — le retrait est daté et motivé, ce qui empêche de la reproposer sans nouvel élément.
| Décision | Contenu |
|---|---|
| Dépôt indépendant | Le projet vit dans son propre dépôt, séparé de tout autre système. |
| Outil interne d'abord, cœur réutilisable | On construit l'outil dont on a besoin, mais avec un noyau de calcul pur — réutilisable tel quel par un service ultérieur. |
| Monolithe modulaire | Pas d'architecture multi-agents distribuée. Des modules nets dans un seul processus : moins de modes de panne, plus de lisibilité. |
| Tranche verticale d'abord | Un cas complet de bout en bout avant d'élargir. Une couche horizontale à moitié faite ne prouve rien. |
| Risques lents seulement | Périmètre initial : les risques qui se voient venir. Pas de manœuvre à la seconde. |
| Décision | Contenu |
|---|---|
| Faisabilité avant APY | Le principe central. Vérifier la constructibilité avant de calculer le rendement. |
| Deux couches : découverte / vérification | Un agrégateur ouvre des pistes ; seule la lecture directe établit un fait. |
| Sourcing on-chain primaire | Les appels de lecture RPC sont gratuits et font autorité. Priorité sur toute API tierce. |
| Isolation, critère de premier rang | Un marché isolé borne la perte par construction. |
| LLM hors du chemin critique | La décision structurante du projet. Le modèle ne calcule jamais. |
| Tampon de liquidation calibré | Le ROE safe remplace le ROE maximal partout. |
| Moteur de risque déterministe | Une seule implémentation du grade de risque pour tout le système. |
| Rendement incité ≠ rendement | Les émissions sont comptées à part et ne franchissent pas le plancher seules. |
| Décision | Contenu |
|---|---|
| Aucune clé privée, jamais | Lecture seule intégrale. Le système ne peut pas déplacer de valeur. |
| Un seul capital | Le dimensionnement part de la valeur nette réelle du portefeuille, jamais d'un montant théorique. |
| Hiérarchie du levier | Modèle propre à la paire, sinon repli de famille — et le repli interdit la validation. La source est écrite dans la sortie. |
| Réserve de marge | Un levier qu'on ne peut pas alimenter n'est pas sûr. |
| Plafond de levier forex | Borne dure indépendante du modèle. |
| Registre des positions déclaré | Le déclaré fait foi, l'observé est un témoin. L'écart est signalé, jamais fusionné en silence. |
| Vue de décorrélation | On raisonne par émetteur, pas par nombre de positions : cinq positions sur le même émetteur, c'est une position. |
| Décision | Contenu |
|---|---|
| Persistance SQLAlchemy | SQLite aujourd'hui, PostgreSQL en changeant une URL. |
| Secrets chiffrés, point d'entrée unique | Le code ne lit jamais le fichier de secrets directement. |
| La machine cloud devient le rouage | Le PC devient un client. Fin de l'état périmé quand la machine est éteinte. |
| Le cycle doit prouver qu'il a tourné | Assertion de fin de cycle + surveillance externe à homme mort. |
| La carte du dépôt est générée | L'index est reconstruit depuis les en-têtes de rôle de chaque script, et le cycle casse si un script n'est pas déclaré. |
| Modèle d'un run explicite | Le niveau de dépense d'une exécution agentique est choisi, jamais implicite. |
| Filet de test sur le substrat | Des tests là où une régression serait silencieuse — pas une couverture de principe. |
| Deux surfaces ne peuvent pas se contredire | Une seule implémentation des chiffres publiés. |
| Une règle = un endroit | Le code arbitre. Toute duplication finit par diverger, et la copie a toujours tort. |
| Veille de marge | Prix publics, exécutée hors du PC, alerte sur les transitions de niveau. |
C'est celle dont découle toute l'architecture. Elle impose la frontière saisie / calculé du classeur, la pureté du moteur de calcul, la garde technique du helper d'écriture, et le fait que le substrat tourne entièrement sans modèle. Chaque fois qu'une fonctionnalité aurait été plus simple en laissant le modèle calculer, elle a été implémentée autrement.
Ajoutée après une divergence coûteuse : le contrat des agents existait en deux exemplaires, et la copie interdisait exactement les colonnes du cœur du projet. La règle a une conséquence pratique — un document ou un skill qui redit une règle est traité comme un défaut, pas comme de la redondance utile. Cette documentation la respecte : elle explique les règles, elle ne les redéfinit pas.
Le fichier docs/DECISIONS.md contient chaque décision avec son numéro, sa date, son
contexte et ses conséquences. Il s'ouvre avec l'état des chantiers en cours : une seule tâche en cours
à la fois — la contrainte qui empêche d'accumuler des travaux à moitié faits.
Où se trouve quoi, et selon quelle logique. La carte détaillée vit dans
INDEX.md à la racine — et elle est générée, pas maintenue à la main.
| Dossier | Contenu | Public |
|---|---|---|
bureau/ | La porte d'entrée humaine : le classeur DYOR, le classeur de synthèse funding, le guide d'utilisation, les lanceurs. | opérateur |
tools/ | Le substrat. Scripts en sous-dossiers, données machine à la racine. | machine |
src/defiintel/ | Le moteur on-chain (boucles de prêt) : adaptateurs, calcul pur, persistance. | machine |
cockpit/ | Le serveur web local, la page unique, la génération du snapshot statique et les lanceurs. | opérateur |
deploy/ | Le nécessaire pour la machine cloud toujours allumée : conteneur, ordonnanceur, cycle Linux. | exploitation |
docs/ | La documentation, les décisions, les registres de venues — et la source de ce site (docs/site/). | tous |
reports/ | Les notes d'audit et les synthèses de posture. Versionnées : c'est la traçabilité. | tous |
product/ | Un service de lecture autonome pour les statistiques de funding. | externe |
.claude/ | Les définitions d'agents et les compétences de la flotte. | agents |
Les scripts sont rangés par groupe — funding/, substrate/,
scans/, xlsxbuild/, wallet/, risk/,
notify/. Les données machine (JSON, CSV, bases, digest) restent à la
racine de tools/. Les classeurs humains vivent dans
bureau/.
Chaque script commence par un bloc d'amorçage commun qui replace la racine et les sous-dossiers
dans le chemin d'import et expose les emplacements de données. Conséquence : on invoque toujours
py tools/<groupe>/<script>.py, quel que soit le répertoire courant.
Chaque script porte en en-tête une ligne déclarant son rôle et son coût de lecture.
Une étape du cycle reconstruit la section automatique d'INDEX.md depuis ces en-têtes — et
refuse de passer si un script n'est pas déclaré.
Il devient donc impossible d'ajouter un fichier sans dire ce qu'il fait. La carte ne peut plus décrocher du territoire : c'est le même raisonnement que pour le registre de conformité des venues — rendre l'omission détectable plutôt que compter sur la discipline.
Le dépôt est conçu pour être lu par un agent à budget contraint. Trois règles :
Chaque entrée de l'index porte un indicateur de coût : 🟢 léger · 🟡 moyen · 🔴 gros ou binaire, à ne pas ouvrir entier.
| Fichier | Voie correcte |
|---|---|
Classeurs .xlsx | Écrire via le helper dédié, lire via le digest. |
Bases .sqlite | Interroger par script ; lire les fichiers de profils. |
| Journal d'exécution | Recherche ciblée uniquement. |
| Export CSV complet du funding | Régénérer à la demande ; ne jamais charger. |
| Fichier de secrets | Jamais. |
| Fichier | Répond à |
|---|---|
tools/STATE.md | « Où en est le système ? » — la lecture par défaut. |
tools/recheck.json | « Qu'est-ce qui a changé ? » |
tools/exposure.json | « Comment le capital est-il réparti ? » |
tools/held.json | « Que détient-on réellement, et quelle est l'exposition nette ? » |
tools/funding_profiles.json | « Ce funding est-il stable ? » |
tools/funding_stats.json | « Quels écarts sont exploitables ? » |
tools/venues_policy.json | « A-t-on le droit d'exécuter sur cette venue ? » |
tools/cycle_health.json | « Le dernier cycle s'est-il bien passé ? » |
tools/roe_alerts.json | « Une position ouverte décroche-t-elle ? » |
Ce site est construit depuis docs/site/ :
docs/site/
nav.json arborescence de la barre latérale
pages/<id>.html un fragment par page — le contenu éditorial
build_docs.py assemble le tout en une page autonome
dist/ copie de relecture hors ligneAjouter une page : déposer le fragment dans pages/ et l'ajouter à
nav.json. La construction échoue si une page déclarée n'existe pas.
Certains tableaux — le registre de conformité notamment — sont rendus à la construction depuis les
fichiers du dépôt, et ne peuvent donc pas mentir.
py docs/site/build_docs.pyLa construction est aussi appelée automatiquement à chaque cycle, juste avant le déploiement.