Le bridge Rozo & ses frais
Le bridge en bref
Rozo transfère de l'EURC entre Base et Stellar via des intents. Chaque sens a un hub (compte à liquidité) sur la chaîne de réception : il avance les fonds et se fait rembourser côté départ. Créer un intent S→B réserve la liquidité du hub ~10 min (elle se libère seule en l'absence de signature) ; un intent B→S fige le frais mais ne réserve pas. Le frais est figé à la création et honoré à la livraison, dans les deux sens. Pas de bridge « atomique » : N tranches = N transactions à signer.
Le modèle de frais Rozo
ⓘModèle non officiel : inféré d'observations (dryrun + créations réelles), pas de la doc Rozo. Le frais % d'un montant livrable monte en continu vers le cap dur 0,50 %, d'autant plus vite que le hub se draine. Au-dessus de la liquidité disponible (montant non livrable en un envoi), l'API renvoie un forfait fixe (cap protocole MAX_PROTOCOL_FEE_BPS) — un artefact d'affichage, pas le vrai barème.
| Sens | base % (plein) | cap | min/tx |
|---|
| Base→Stellar | ~0,09 % | 0,50 % | 0,01 € |
| Stellar→Base | ~0,12 % | 0,50 % | 0,01 € |
- Déterministe (même entrée → même frais), indépendant de l'appId.
- Driver dominant = remplissage du hub (Available), pas le ratio montant/liquidité.
- Sur Stellar→Base, créer un intent réserve l'Available → empiler les tranches fait baisser le L restant → le frais % monte le long d'une surface mesurée
fee%(montant, L) (mesures historiques en drainage réel — distinctes du balayage de la page Doc, qui ne sert qu'au graphe), plafonnée à 0,50 %. En Base→Stellar, créer un intent ne réserve plus l'Available → pas d'escalade (valeur unique par tranche).
- Routes : le niveau base% et la montée diffèrent (B→S ~0,09 < S→B ~0,12 %) → une surface par route, mesurée séparément pour projeter max et coût probable ; max ≤0,04 € / 16 séries — le min est un devis dryrun réel (exact, pas une projection).
- Frais figés à la création et honorés à la livraison — vérifié dans les 2 sens (03/07/2026).
Pourquoi une fourchette min/max
Une fourchette n'apparaît que sur le sens
Stellar→Base.
Là, créer un intent
réserve l'Available du hub : empiler des tranches le draine, donc chaque tranche suivante coûte plus.
Le découpage s'y lit alors en
trois valeurs :
- min — N devis dryrun réels (un par taille de tranche T/n), sommés. C'est le frais exact si chaque tranche partait à hub plein, sans drainage. Meilleur cas, exact.
- max — les tranches créées en série, chaque intent drainant le hub. Pire cas, estimé depuis la surface mesurée (cap 0,50 %), collé au réel ≤0,04 €.
- coût probable — affiché entre les deux, même surface, ancré sur le min exact.
En pratique, les N créations partent en
parallèle.
Le serveur partage le snapshot par
vagues.
Le réalisé est donc une
variable aléatoire entre min et max — proche du min quand il y a peu de tranches.
Sur
Base→Stellar, créer un intent
fige le frais mais ne réserve pas l'Available.
Sans drainage,
chaque tranche a une valeur unique (min = max) : ni fourchette, ni coût probable.
La
génération donne le chiffre engageant.
Courbe des frais (frais % vs montant)
- Points = mesures live (dryrun, identiques pour tous les appId).
- Balayage paresseux : lancé à l'ouverture de la page Doc, seulement pour les montants ≤ plafond de liquidité (+ un point exact au plafond) — sert uniquement à ce graphe, pas au devis.
- Lignes verticales = plafond de liquidité live (= Available de l'API Rozo, ≈ solde on-chain du hub) ; chaque courbe s'arrête à son plafond.
- Au-delà du plafond, un envoi unique est refusé (fractionne).
- Le frais % est le plus élevé près du plafond, et grimpe encore quand le hub se draine.
- Les petits montants montent vers ~0,50 % (plancher 0,01 € + arrondi cent).
- La génération donne le chiffre engageant.
Comment l'outil calcule ce devis
Ce que l'outil affiche
Un montant est saisi (
reçu ou
envoyé) ; l'outil interroge l'API en
dryrun (aucune réservation) et affiche :
- pour un envoi unique, une tuile COÛT — chiffre exact, un devis dryrun réel, au centime ;
- pour un découpage en n tranches, une tuile COÛT PROBABLE (≈) + une FOURCHETTE min – max : le min est exact (n devis dryrun sommés), le max reste une estimation (surface mesurée, cap 0,50 %) ;
- un tableau des découpages qui se remplit tranche par tranche : chaque ligne affiche « … » puis son frais exact dès que son dryrun répond, tranches infaisables grisées.
La
reco = le plus petit découpage qui capte
≥90 % de l'économie possible (au-delà, on gagne des centimes contre des signatures en plus). Le devis n'engage à rien (aucune réservation) ;
« Générer » crée les intents et fige les
mêmes chiffres exacts.
D'où viennent les chiffres
Rien n'est codé en dur — le frais suit la liquidité, qui bouge :
- Devis (min, max, coût probable) : le min vient de n devis dryrun réels (un par taille de tranche T/n), mis en cache par (sens, mode, montant) et invalidés si l'Available bouge de >1 EURC — à liquidité inchangée, un re-devis ne relance aucun dryrun. Le tableau de découpage se remplit tranche par tranche.
- Courbe de frais (page Doc uniquement) : balayage dryrun paresseux, lancé à l'ouverture de la Doc, limité aux montants ≤ plafond de liquidité (+ un point exact au plafond) — sert au graphe, pas au devis.
- Liquidité (Available) : un intent volontairement trop gros → le refus renvoie « Available: X ».
- Vérification on-chain : solde EURC des hubs (Horizon côté Stellar, RPC côté Base), comparé à l'API — alerte si écart.
Pas de rafraîchissement automatique : au chargement de la page, puis via le bouton ↻.
Les formules & la précision
Notations :
c = T/n (montant d'une tranche),
dryrun(c) = devis réel de l'API pour une tranche de taille c (exact, déjà arrondi au cent),
p₁ = dryrun(c)/c (taux exact mesuré sur la 1ʳᵉ tranche),
Lᵢ = L0 − i·c (Available restant avant la tranche i),
fee%(c, L) = surface mesurée (interp bilinéaire, cap 0,50 %), escalade
R(c,i) = fee%(c, Lᵢ) / fee%(c, L0),
⌈·⌉¢ = arrondi au centime supérieur (plancher 0,01 €).
min = n · dryrun(c) — exact, aucune interpolation
max = Σᵢ ⌈ min( 0,5%·c , c · p₁ · R(c,i) ) ⌉¢
coût probable = Σᵢ ⌈ max( c·p₁ , 0,70 · c·p₁·R(c,i) ) ⌉¢
Les formules
max et
coût probable décrivent le sens
Stellar→Base (créer un intent réserve l'Available → l'escalade R(c,i) monte). Sur
Base→Stellar, aucune réservation →
R(c,i)=1 pour tout i → max et coût probable retombent sur le min : la
valeur affichée = n·dryrun(c), unique.
Précision mesurée : le
min est
exact — c'est la somme de n devis dryrun réels, pas une borne. Le
max colle au réel à
≤0,04 € (16 séries réelles en série stricte). Surface
stable (pas de dérive), re-mesurable par dryrun si Rozo change son algo.
Exécution
Pas de batch atomique
Sur Stellar le mémo est par transaction ; sur Base un batch = 1 tx source dont Rozo ne règle qu'un paiement. Donc N tranches = N signatures dans les 2 sens. Mémo TEXT obligatoire (sinon fonds perdus). En cas de batch mal formé, pas de refund automatique → support Rozo (discord.gg/rozoai ou hi@rozo.ai).
Signer & suivre les intents
Références
Bridge officiel Rozo : intents.rozo.ai/bridge ↗
Contact Rozo : discord.gg/rozoai ↗ ou hi@rozo.ai.
Code de cet outil (non officiel) : github.com/actarus314/rozo-bridge ↗
Adresses
Sources : API intentapiv4.rozo.ai (sans clé), Horizon, RPC Base, contrat RozoIntents.sol, repos rozo-intents-skills / rozo-docs. Généré le .
Dispersion de θ (Stellar→Base)
θ = (réalisé − min) / (max − min) — position du coût réel dans la fourchette, mesurée sur les batchs S→B réellement générés. Le point (coût probable) devrait viser le θ médian empirique, pas un poids arbitraire.
Rozo Bridge