Et non, ce n’est pas un bug, le DU vaut bien 10 sur la GTest 
On dit que les données sont celles de la G1, sauf ça qui repart d’une valeur donnée.
Tu peux le voir en affichant les DU qui tombent dans la vue activité des comptes.
… Mais d’ailleurs, ce ne serait pas un bug ça @HugoTrentesaux @tuxmain @elois ? Car pour la migration il faudra bien reprendre le bon montant du DU.
→ #318
Dans https://git.duniter.org/nodes/rust/duniter-v2s/-/jobs/147769/artifacts/download j’ai bien :
head input/genesis.json
{
"first_ud_value": 1125,
"first_ud_reeval": 1758333600,
Ça doit pas être bien pris en compte par Duniter v2s.
Je constate que pour la ĞDev, l’indexeur a également commencé à 1000.
query MyQuery {
universalDividend {
amount
}
}
{
"data": {
"universalDividend": [
{
"amount": 1000
},
{
"amount": 1000
},
{
"amount": 1000
},
{
"amount": 1000
},
{
"amount": 1000
},
{
"amount": 1000
},
{
"amount": 1432
},
[…]
Je ne trouve pas first_ud_value dans le code source de Duniter v2s.
Pour l’indexeur, il y a une occurrence, cependant, je ne sais pas si c’est correctement utilisé.
L’indexeur ne fait que indexer la blockchain, donc à priori le bug est juste côté Duniter.
Ça vient de là :
Donc, valeur à récupérer de py-g1-migrator.
Oui, effectivement il y a des FIXME là dedans, ça mérite de refaire une passe sur le parsing genesis lors du bootstrap gtest.
La valeur du DU initial est déjà présente dans les données genesis de py-g1-migrator:
"first_ud_value": 1125
Le montant du DU n’a pas été réévalué sur la Ğtest, comme ça a été le cas sur la Ğ1 le 20 septembre 2025 :
query MyQuery {
universalDividend {
amount
timestamp
}
}
[…]
{
"amount": 1000,
"timestamp": "2025-09-20T19:13:06+00:00"
},
{
"amount": 1000,
"timestamp": "2025-09-21T19:13:06+00:00"
}
]
}
}
Je suppose que ça arrivera un semestre après le lancement de la Ğtest (10 juillet) → le 10 janvier.
Ça doit être le rôle de ces variables resources/gtest.yaml · master · nodes / rust / Duniter v2S · GitLab
Je suppose qu’il s’agit de timestamps. À bien gérer pour le lancement de la prochaine ĞTest !
J’ai eu une théorie comme quoi la réévaluation était nulle, c’est-à-dire qu’elle est passée de 10,00 Ğ1 à 10,00 Ğ1. Or, en voulant vérifier cette théorie, je me suis rendu compte qu’elle était fausse.
Avec une réévaluation qui a eu lieu le :
September 20, 2025 4:00 AM
Avec la query sur Squid/Hasura :
query MyQuery {
universalDividend {
amount
blockNumber
membersCount
monetaryMass
timestamp
}
}
[…]
{
"amount": 1000,
"blockNumber": 1031514,
"membersCount": 6522,
"monetaryMass": 14445825859,
"timestamp": "2025-09-19T19:13:00.002+00:00"
},
{
"amount": 1000,
"blockNumber": 1045914,
"membersCount": 6507,
"monetaryMass": 14452332859,
"timestamp": "2025-09-20T19:13:06+00:00"
},
[…]
avec c :
curl https://g1.duniter.org/blockchain/parameters
{
"currency": "g1",
"c": 0.0488,
[…]
UD(t+1) = UD(t) + c² x M(t)/N(t+1)
DU(t+1) = 10 + 0.00488² × 144458258.59 ÷ 6522 ≃ 10.53
Peut-être que je me méprends sur la valeur de M que j’ai pris à t+1. J’ai pris la première valeur de l’indexeur, celle du 10 juillet, ce qui donne 10.49.
Conclusion, il y aurait quand même dû y avoir une réévaluation du DU !
gcli blockchain runtime-info me retourne ces valeurs qui sont correctes :
[…]
--- universal dividend ---
max past reevals: 160
square money growth rate: Perbill(2381440)
UD creation period: 86400000
UD reeval period: 15778800000
86400000/1000/3600/24
1 jour
15778800000/1000/3600/24
182 jours
or, dans le genesis.json il y a la bonne date de réévaluation et le bon montant du DU (au moment de lancer la Ğtest1) :
"first_ud_value": 1125
"first_ud_reeval": 1758333600
ce qui correspond à la bonne date de réévaluation :
date -d @1758333600
Sat 20 Sep 04:00:00 CEST 2025
Donc, ces valeurs sont auto-générées et les écrire un dur (hardcoder) serait inutile ?
Cependant, la réévaluation n’a pas eu lieu. Où est le problème ?
Ces champs du genesis devraient être pris en compte par Duniter-v2s. Le sont-ils ?
Bon, faut continuer de creuser camarade !
En tout cas le fait d’avoir inscrit en dur dans le yaml le UD initial ainsi que le next reeval a bien été pris en compte dans notre reboot gtest:
resources/gtest.yaml
# FIXME: ĞT per UD
ud: 1148
# FIXME: explain `null` meaning
first_ud_reeval: 1766232000
→
Ok, du coup, on pourra vérifier s’il y a bien réévaluation le 20 décembre à 13:00 CET.
20 décembre ?? Ce n’est pas l’équinoxe !
Je crois que c’est ça qui est fait dans la g1 non ? 1 jour avant équinox pour que le prochain DU soit appliqué à cette nouvelle valeur non ? J’ai mis ça de tête.
Non, ça c’est à peu près le solstice. Mais c’est très bien pour tester étant donné que c’est dans environ deux mois.
Alors, faisons le point.
Suite à ce bug que tu relèves, j’ai tiré les fils.
Il y a déjà un premier problème qui n’a rien à voir avec ça: Quand j’ai lancé cette gtest, je me suis basé sur master pour créer la branche network, évidemment, quoi d’autre ?
Mais étant donné que jusqu’a présent, les branches de network ne sont pas mergés sur master, tous les commits qu’avait fait @elois pour lancer gtest #1 ne se retrouve pas dans ce réseau 
Je viens donc de relire tout ces commits, en fait il n’y avait pas grand chose mais quand même quelques ajustements mineurs, dont certain que j’ai dû reproduire du coup sans quoi Duniter crashait avec le runtime gtest, je ne comprenait pas pourquoi (je pense à l’ajout du protocoleId par exemple).
Mais après relecture, rien dans ses commit n’explique ce comportement, le UdReevalPeriod est correctement set dans les paramètres du runtime gtest:
pub const UdReevalPeriod: Moment = 15_778_800_000; // 1/2 year
Non le problème est ailleurs, et je viens de le comprendre. @Moul a bien fait de déplacer le sujet ici, car c’est lié au paramètre first_ud_reeval que j’ai set dans le yaml gtest
En lisant le code qui interprête cette valeur, en fait il s’attend à un timestamp … au format millisecondes !
Hors je l’ai mis au format secondes…
Du coup ce qu’il se passe:
if moment >= next_reeval est toujours vraie, il réévalue le DUUdReevalPeriod (6 mois) à la date de prochaine réévaluation, passant donc au 21 Juillet 1970, puis le lendemain au 21 Janvier 1971, ect …Conclusion:
C’est ma faute MAIS:
(même si ça n’a rien à voir avec la cause du bug en l’occurence).Autres conclusions:
ping @cgeek @HugoTrentesaux @tuxmain @technical-committee, on en profite pour s’entrainer aux runtime upgrade et tant pi pour les réévaluations déjà encaissés ?
A post was split to a new topic: Runtime Upgrade Proposal: gtest v1110
Sauf erreur de ma part, tout a été mergé par un commit de cherry-pick qu’avait justement fait Eloïs. Il manquait juste une petite chose (le paramètre embed), tout a été mentionné dans !345.
Yes
Il faut le mettre à l’équinoxe d’automne 2025, tant pis on aura une autre réévaluation du DU sur la ĞTest, on n’est pas à ça près.
Oui, l’erreur est humaine et nous devons essayer de contrôler systématiquement (modulo la dispo du CT).
Certes. Mais j’ai déjà initié un peu d’outillage de mon côté, il me reste à positionner des règles et à surveiller.
Oui on a besoin de s’entraîner.
Non je ne pense pas qu’il y ait eu de cherry pick, les changes de sa branche ne sont pas sur master. Comme le protocoleId des specs gtest que j’ai dû rajouter.
Mais j’ai testé un merge en local, il n’y a rien à récupérer de sa branche, soit des changes liés à la CI qui sont donc obsolètes, soit des choses déjà refaites, à priori.
Ici.