Contrats et pouvoirs

Cette page est la référence des adresses du pilote et de « Contrats immuables ». Chaque adresse a été relue sur la chaîne avant d'être écrite, le 18 septembre 2026, au bloc Robinhood 66231030 (lu on-chain). Chaque commande a été exécutée telle quelle, chaque sortie est réelle ; cast et call sont présentés à la page 3 :

RH_RPC=https://rpc.mainnet.chain.robinhood.com
VAULT=0x4aaEBA7E0Bb05FeE125a491D6Be956027bd147bd
ORACLE=0x6f6Cc580122F7f4358999D6005e6107b00fB7F64
STAKING=0xd1DA0Bb40872525E84909345C059716A1dB66905
ROUTER=0x6Ca5a6a1a890b6077eF47fFED54F7E38e3DCc453
call() { cast call "$@" --rpc-url "$RH_RPC" | sed 's/ \[[^]]*\]//g'; }

1. Les contrats du pilote

Toutes les adresses sont celles du pilote : les quatre contrats NetNat, puis les contrats tiers que le coffre appelle. Le bloc de création des quatre premiers vient de leur reçu de création, relu sur la chaîne (DEPLOY.md §3). Les autres viennent des variables publiques du coffre ou du routeur ; chacune héberge du code (lu on-chain : cast code).

v2 : à venir au déploiement ; cette page sera republiée, avec un cinquième contrat, la réserve de gas (SPEC §12.1 point 6).

2. Ce que « Contrats immuables » veut dire

Pas de proxy, pas de mise à jour, pas de pause, pas de clé maîtresse. Ce qui est déployé est ce qui tourne. Une évolution est un nouveau déploiement, avec migration volontaire des déposants (SPEC §3).

Un proxy renvoie chaque appel vers un autre contrat, remplaçable, dont l'adresse est rangée dans une case de stockage normalisée (EIP-1967). Lisez cette case sur les quatre contrats : zéro veut dire « pas de proxy ».

IMPL=0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc
for a in $VAULT $ORACLE $STAKING $ROUTER; do cast storage $a $IMPL --rpc-url "$RH_RPC"; done

0x0000000000000000000000000000000000000000000000000000000000000000
0x0000000000000000000000000000000000000000000000000000000000000000
0x0000000000000000000000000000000000000000000000000000000000000000
0x0000000000000000000000000000000000000000000000000000000000000000

Pour comparaison, la case de l'USDG, un proxy (SPEC §2) :

cast storage 0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168 $IMPL --rpc-url "$RH_RPC"

0x00000000000000000000000068184c449e1a8f34fa18d289737129fd27b66f8f

La preuve complète est le code source, vérifié « Exact Match » sur RobinScan, Blockscout et Sourcify, identique octet pour octet au contrat déployé (DEPLOY.md §4) : il ne contient ni pause, ni retrait par un opérateur, ni modification de paramètre, à la seule exception du plafond de dépôt, section 3 (SPEC §4.9).

3. Le seul pouvoir privilégié

Une adresse, CAP_ADMIN, peut relever le plafond de dépôt, jamais le baisser, en deux temps, proposition puis exécution après 24 h d'attente (SPEC §4.9 ; lu on-chain : CAP_TIMELOCK = 86 400 s). Ce pouvoir ne touche ni aux dépôts, ni aux pots, ni aux tirages, ni à l'oracle (SPEC §4.9). Qui le détient, et une demande est-elle en attente ?

call "$VAULT" "CAP_ADMIN()(address)"
call "$VAULT" "depositCap()(uint256)"
call "$VAULT" "pendingCap()(uint256)"
call "$VAULT" "pendingCapExecutableAt()(uint256)"

0x443Ef9FEb0DD431103DB932cfc91b825d708DFDd
1000000000
0
0

Ce que vous venez de lire : le détenteur, une adresse simple, sans code (lu on-chain : cast code vide) ; le plafond, 1 sNET (9 décimales) ; aucune demande en attente, plafond proposé et date d'exécution à zéro. Une proposition apparaîtrait ici au moins 24 h avant de s'appliquer, et dans l'événement CapRaiseProposed.

4. L'oracle et ses attestors

L'oracle tient une liste fixe de trois attestors et un seuil de deux votes identiques, fixés à sa création, et personne pour les changer (SPEC §6.1 ; §9).

call "$ORACLE" "attestors()(address[])"
call "$ORACLE" "THRESHOLD()(uint256)"

[0xA1f05930f4998EFb1F4b030a86de33FD36Ca976b, 0xa9e4728892432600d41767De232FE2BbEa6e61bf, 0xDA589c4D83cC3f6f64a669ddD68968dc29eB8C11]
2

Qui les opère : au pilote, le builder, les trois sur une seule machine, avec le keeper (DEPLOY.md §1 ; §5). Le hash rapporté dépend donc d'un seul opérateur, mais n'importe qui le vérifie contre Bitcoin (page 3), et un vote divergent laisse une trace publique, l'événement Mismatch (SPEC §6.2). En v2, deux machines distinctes, le quorum sur la plus fiable, et le premier attestor remplacé par précaution (SPEC §12.1 points 1 et 2). En v3, cinq attestors extérieurs, seuil de trois (SPEC §12.1 point 9).

5. Le keeper

Les trois étapes du cycle, sweep, tranches d'achat et règlement, sont ouvertes à tous : au pilote, aucune n'est réservée à une adresse (SPEC §4.4 ; §4.4 bis ; §4.6 ; lu on-chain : code du coffre). Le keeper, robot du builder, les appelle. La prime de 1 % du pot, plafonnée à 25 millions de NAT, revient à qui règle le tirage, quel qu'il soit (SPEC §4.8 ; lu on-chain : KEEPER_BOUNTY_BPS, KEEPER_BOUNTY_MAX_NAT). Si le robot s'arrête, le protocole attend, rien n'est perdu (SPEC §12.1 point 2).

6. Où va l'argent

La commission se prend sur le pot après la prime du keeper (SPEC §4.6). Au pilote, nulle pendant 30 jours après le déploiement, puis 3 %, répartis 50 % pour NATStaking, 25 % pour le trésor, 25 % pour le builder (SPEC §4.7 ; lu on-chain : FEE_BPS_AFTER, FEE_SPLIT_*) ; la valeur en vigueur se lit avec feeBps(). En v2, 10 % dès le premier tirage : 4 % pour les stakers de NAT, 3 % pour le trésor, 3 % pour le builder (SPEC §12.1 point 4). Les trois destinataires sont figés dans le coffre, trésor et builder conservés en v2 (SPEC §12.1 point 3) :

call "$VAULT" "NAT_STAKING()(address)"
call "$VAULT" "TREASURY()(address)"
call "$VAULT" "BUILDER()(address)"

0xd1DA0Bb40872525E84909345C059716A1dB66905
0x2760f4054aB846776D0a0a1783A5aC592a35F9f7
0xC09A8182003fA64DEbac08eF8151891058376157

Trésor et builder sont des adresses simples, sans code (lu on-chain : cast code vide) ; un multisig pourra les recevoir plus tard par simple transfert (SPEC §12.1 point 3). Détail des frais : page 4.

7. En une ligne

Contrats immuables. Bitcoin choisit. Les attestors rapportent. Tout le monde vérifie.