Wombex : Explication détaillée du Bribe Market de Wombex
Boostez vos APR et votre compréhension du bribe market
Chers Wombex Warriors !
Les derniers jours ont été d’une grande importance pour Wombex. Une très grosse étape a été accomplie avec le lancement du Bribe Market de Wombex. Des centaines de Wombex Warriors l’ont déjà utilisé pour participer à leur premier tour de table.
Nous avons rédigé cet article afin d’aider la communauté à mieux comprendre le mécanisme du Bribe Market de Wombex.
I. Le système de vote sur Wombat & le mécanisme de bribe
Explication du gauge voting de Wombat
Le gauge voting de Wombat est une fonctionnalité qui permet aux détenteurs de veWOM de décider comment les récompenses $WOM vont être distribuées aux fournisseurs de liquidité sur les 7 prochains jours.
Pendant la durée de l’epoch, la liquidité des pools de Wombex continue d’accumuler des récompenses $WOM avec un ratio proportionnel au montant des votes alloués à chaque pool.
À la fin de l’epoch, les $WOM sont distribués aux fournisseurs de liquidité de chaque pool de façon linéaire durant les 7 jours suivants.
Wombat à une émission mensuelle de 2.000.000 de tokens (environ 0.77 token par seconde). Cette émission est répartie entre “l’allocation de base” (75% ou 1.500.000 token par mois) et “l’allocation par vote” (25%, ou 500.000 token par mois).
- L’allocation de base (définie par l’équipe de Wombat) est distribuée sans condition aux pools de base (BUSD/USDT/USDC/DAI) et ne dépend pas des votes de détenteurs de veWOM. C’est un mécanisme basique pour récompenser les fournisseurs de liquidité.
- Chaque pool a des points qui lui sont alloués. Par exemple, 220 points (sur 1000) pour la main pool BUSD, signifie que 22% de l’allocation de base va être attribué à la pool BUSD (2,000,000 * 75% * 22% = 330,000 WOM par mois).
- L’allocation par vote est faite pour les autres pools (notamment les side pools/innovation pools/ liquid staking derivatives pools) selon les votes du dernier epoch. Un vote veWOM équivaut à un vote pour la pool.
Le mécanisme de vote sur Wombat
Le contrat principal dans le gauge voting de Wombat est le Voter contract. Ce contrat est chargé de récolter les votes des utilisateurs et de distribuer les récompenses en se basant sur les votes. Il contient les variables suivantes :
- La somme de tous les votes des utilisateurs (totalWeight)
- Les informations liées à chaque pool:
- Le vote de chaque utilisateur
- La somme de tous les votes pour une pool (weight)
- L’allocation des points
- supplyBaseIndex // La dernière allocation de $WOM par point
- supplyVoteIndex // Le montant de $WOM distribué par vote
- baseAllocation // (1000 = 100%)
- totalAllocationPoints // La somme de tous les points alloués
- Le montant de $WOM distribué par allocation de base
- Le montant de $WOM distribué par allocation des votes
Pour voter, les utilisateurs appellent la fonction voter.vote(_lpTokens, _deltas) et fournissent l’adresse du lp token de la pool et le delta (montant de veWOM à ajouter ou retirer du vote).
Pour commencer, le voter contract vérifie combien de $WOM ont été distribués dans l’allocation de base et dans l’allocation par vote. Il fait appel à la fonction _distributeWOM() qui elle-même fait appel aux fonctions _getBaseIndex() & _getVoteIndex() pour mettre à jour la distribution de $WOM en suivant les règles suivantes :
baseIndex = baseIndex + secondsElapsed * womPerSec * 75% / totalAllocationPoints
voteIndex = voteIndex + secondsElapsed * womPerSec * 25% / totalWeight
secondsElapsed correspond au temps passé en seconde, depuis la dernière distribution.
- baseIndex définit combien de $WOM sont accumulés par point d’allocation pour la période courante et ne dépend pas des votes.
- voteIndex définit combien de $WOM sont accumulés par vote, pour la période courante.
Ensuite, les informations des pools sont mises à jour grâce à la fonction _updateFor(_lpToken). Cette fonction recalcule les récompenses récoltées pour les pools en fonction du nouveau baseIndex & voteIndex :
baseShare = (baseIndex — previousBaseIndex_p) * allocPoints_p
voteShare = (voteIndex — previousVoteIndex_p) * weight_p
claimable = claimable + baseShare + voteShare
Ici, underscore_p désigne les paramètres du pool.
Le graphique suivant illustre le process :
Le voter contract calcule les changements de poids de chaque pools en ajoutant (if _deltas[lpToken] is > 0) ou en soustrayant (_deltas[lpToken] < 0) depuis les votes de la pool. Il va ensuite suivre le montant total de vote de toutes les pools en ajoutant sum(_deltas). Les informations par pool et par utilisateurs sont ensuite mises à jour (pour suivre combien de votes les utilisateurs ont attribué par pool).
Voici un schéma qui résume comment cela fonctionne :
Le processus de vote sur Wombat est toujours en cours à ce moment.
Cela signifie que pendant que les votes sont actifs, chaque pool dans le gauge continu d’accumuler des récompenses en $WOM. Ces récompenses seront distribuées à la fin de l’epoch. Lorsque des votes sont attribués à une pool, du $WOM est ajouté au futur récompenses de la pool. Cependant si certain votes sont réaffectés à une autre pool, elle gagnera davantage à partir du bloc de vote réaffecté
Donc le poids de la pool dans le gauge n’a pas vraiment d’importance à la fin du vote. Ce qui compte, c’est le poids de la pool pendant la période de vote.
Le mécanisme de bribe sur Wombat
Wombat a conçu son propre mécanisme de bribe market pour simplifier les interactions entre les veWOM des utilisateurs et les yield aggregators.
Cela est fait de façon à ce que les protocoles puissent verser simplement les bribes aux utilisateurs, pour les inciter à voter pour leurs propres pools. En votant pour les pools qui sont “bribées” les utilisateurs reçoivent des récompenses supplémentaires.
Les récompenses $WOM sont acquises bloc par bloc, celles issues des bribes suivent la même logique. Le mécanisme de distribution des récompenses est identique à celui des LPs :
Le contrat Bribes, qui hérite de MultiRewarderPerSec, stocke la quantité de rewardToken attribuée aux pools et le paramètre tokenPerSec, qui définit le nombre de rewardToken distribués par seconde. Chaque utilisateur reçoit des rewardToken en fonction de sa part de votes dans la pool bribée.
Chaque fois que la fonction voter.vote() est appelée, après toutes les mises à jour de poids pour un lpToken donné, Bribe.onVote(_user, _userVote, _originalWeight) est appelée en passant trois arguments :
- L’adresse de l’utilisateur
- Le vote final de l’utilisateur pour une pool donnée
- Le poids de la pool avant la mise à jour (avant de prendre en compte le vote de l’utilisateur)
Ensuite, les fonctions suivantes sont appelées MultiRewarderPerSec _updateReward(_originalWeight) et _onReward(_user, _userVote).
La première calcule les récompenses distribuées par vote au moment de l’exécution de la fonction :
accTokenPerShare = accTokenPerShare + timeElapsed * tokenPerSec / _originalWeight
distributedAmount = distributedAmount + timeElapsed * tokenPerSec
Elle met également à jour le lastRewardTimestep. En d’autres termes, elle calcule pour une pool donnée, combien de bribes devraient être distribués par vote au moment de l’exécution de la fonction.
La seconde fonction calcul combien de bribes devrait être transférés à l’utilisateur en fonction de son vote avant la mise à jour :
reward = user.amount * accTokenPerShare — rewardDebt
user.amount = _userVote
rewardDebt = user.amount * accTokenPerShare
Pour finir, les récompenses sont ensuite distribuées à l’utilisateur.
II. Le mécanisme de bribe sur Wombex
Lorsque vous bloquez du $WMX vous obtenez du vlWMX. Cela vous permet de participer à la gouvernance de Wombat en utilisant les veWOM détenus par Wombex. Chaque détenteur de vlWMX détient une part des veWOM du protocole. Lorsqu’un vote a lieu, les votes vlWMX sont traduits en votes veWOM.
Remarque : Le calcul se fait de la façons suivante um_vlWMX/total_veWOM_owned_by_Wombex
Un contrat intermédiaire du Wombex GaugeVoting est responsable du recalcul vlWMX->veWOM et de l’exécution du vote.
Afin de suivre les votes des utilisateurs, une BribesRewardPool spéciale est créée pour chaque LP Wombat. Les adresses sont listées dans la documentation : https://docs.wombex.finance/deployed-addresses
En utilisant leur vlWMX les utilisateurs appellent la fonction GaugeVoting.vote(_lpTokens, _deltas). Cette fonction prend les adresses lpToken des pools pour lesquels il souhaite voter, et les deltas correspondants.
Pour chaque lpToken pour lequel l’utilisateur vote, un “Staking token” est créé et staké. Si le delta est positif (ou brûlé, si le delta est négatif) dans une pool de récompenses correspondante. Cette conception stocke toutes les informations sur les votes des utilisateurs dans les pools de récompenses sous la forme de token de récompense staké.
Une fois que le nombre total de votes vlWMX dépasse un seuil de 500 000, la traduction des votes vlWMX en votes veWOM commence.
La période de traduction est fixée à 24 heures. Pendant ce temps, les votes vlWMX sont accumulés dans le Gauge Voting contract. Lorsque le vote est prêt, un agent externe (Keeper) appelle la fonction voteExecute pour traduire les votes vlWMX en votes veWOM et les transmettre à Wombat.
Le contrat reçoit le montant total de vlWMX utilisé pour le vote (par la somme de tous les tokens de récompense dans toutes les pools de récompense), et le montant total de veWOM disponible pour le vote.
Nous rappelons ici que le contrat voterProxy détient tous les veWOM de Wombex.
Pour passer des votes de vlWMX aux veWOM, le contrat doit recalculer le rapport entre les veWOM et les vlWMX et obtenir un nouveau pouvoir de vote (c’est-à-dire combien de veWOM sont utilisés dans le vote pour 1 vlWMX).
ratio = [veWOM balance on VoterProxy]/[vlWMX_voted]
Ici vlWMX_voted est le nombre de vlWMX qui ont participé au vote dans l’epoch courant.
delta_p = ratio * vlWMX_votes_for_pool_p — current_veWOM_votes_for_pool_p
vlWMX_votes_for_pool_p est un nombre de votes attribué pour la pool p. Il est égal au solde de tokens stakés dans le BribesRewardPool.
Pour finir, le contrat exécute la fonction booster.voteExecute(_lpTokens, _deltas) pour voter dans Wombat au nom de Wombex.
Le contrat du Bribe Market s’illustre de la façon suivante:
La période de 24 heures de recalcul et d’exécution des votes vlWMX->veWOM peut être modifiée, par exemple pour exécuter une “traduction” mettant à jour tous les votes veWOM chaque fois qu’un utilisateur aléatoire vote avec des tokens vlWMX. La configuration actuelle peut être observée sur bscscan.
La période de 24 heures peut être modifiée ou mise à zéro. Actuellement, il existe une incitation à l’exécution — 0,5% du bribe payé à l’exécuteur de la transaction afin d’encourager les exécuteurs indépendants à participer au processus de distribution des bribes.
Les utilisateurs peuvent participer (si cette fonction est activée, ce n’est pas le cas pour l’instant) à la récoltes des récompenses de bribes en l’exécutant pendant le tx de vote ou le tx de réclamation de récompenses. Cependant, cela obligera les utilisateurs à payer des frais de gas élevés. Ces frais peuvent être conséquents pour les petites positions vlWMX.
Le mécanisme de distribution des récompenses du bribe market
Wombex récupère les récompenses des bribes une fois par jour et les distribue aux détenteurs de vlWMX qui ont participé au vote. Ces récompenses sont allouées à leurs pools correspondantes (https://docs.wombex.finance/deployed-addresses) et distribuées linéairement pendant les 24 heures suivantes.
Chaque vote vlWMX est représenté sous la forme d’un token de Staking dans les pools de récompenses. La distribution des récompenses issues des bribes est similaire à la distribution des récompenses des LP aux fournisseurs de liquidités.
L’image ci-dessus ne montre que le mécanisme actuel. La mécanique de réclamation des récompenses peut être facilement modifiée. Il est possible de changer le re-calcul de vlWMX->veWOM et la période d’exécution du vote ainsi que la période de réclamation et de distribution des récompenses.
Suivez-nous pour rester informé des avancées de Wombex.
Twitter | Discord | Telegram | CMC Community | Medium
