# Token $VIVRA et trésorerie

$VIVRA est créé via la factory Pons v2 avec une creator tax de 3 %. Chaque jour, un job réclame les frais dans l'escrow Pons et les répartit entre trois wallets publics. Rien n'impose cette répartition on-chain en V1 : le registre public la rend vérifiable.

## Paramètres de lancement

| Paramètre | Valeur | Note |
| --- | --- | --- |
| Chaîne | Robinhood Chain, chain id 4663 | testnet 46630 pour les tests |
| Factory Pons v2 | `0x7eD598BcEf8bd9Edd8C97A195C6d13f40801EC7e` |  |
| Escrow des frais | `0xd3AFEB2a57f70eF218Aa82451c51B2fb0416Ac9e` |  |
| Meme hook (après graduation) | `0xE5e702641Ea86F4ae6cC3cDaeD2B886f976Be044` |  |
| `creatorTaxBps` | 300 | fixé au lancement, ne peut jamais monter |
| `creatorFeeRecipient` | wallet Collecte | modifiable plus tard via `transferCreatorFeeRecipient` |
| Actif de paire | ETH | choix définitif |
| Rachat natif Pons | désactivé | les jetons rachetés par Pons sont vestés 5 ans, pas brûlés |

À revérifier sur la doc Pons v2 juste avant le lancement : adresses, plafond `maxCreatorTaxBps()`, et répartition de base renvoyée par `getLaunchFeePolicy(token)`.

## Ce qui arrive dans l'escrow

Sur chaque trade, l'escrow reçoit 3,7 % du volume : la part créateur des frais de base (0,7 %) et la creator tax (3 %). Les 0,3 % restants vont à Pons. Le job de répartition applique donc ces ratios au montant réclamé :

| Wallet | Part du volume | Part du montant réclamé | Usage |
| --- | --- | --- | --- |
| Équipe | 1,7 % | 17/37 (45,95 %) | revenu de l'équipe |
| Buyback | 1,5 % | 15/37 (40,54 %) | rachat et burn des tokens CTO (section 7) |
| IA | 0,5 % | 5/37 (13,51 %) | inférence Surplus, réserve de 60 jours |

## Job quotidien de trésorerie

1. Lire les frais non balayés : `pendingFees` et `pendingCreatorTax` sur le hook (ou `quoteFeeBalance` et `creatorTaxBalance` sur la courbe avant graduation).
2. Balayer si besoin : `sweepPoolFees(poolId, minConversionQuoteOut, minBuybackTokensOut)` ou `sweepFees(...)` sur la courbe. Si l'appel renvoie `InternalSwapRequiresOperator`, attendre le balayage de l'opérateur Pons.
3. Lire `balanceOf(collecte)` sur l'escrow, puis `claim()` (ETH) ou `claimToken(token)` (ERC-20). Attention : un retour de PR indique que le `claim` déployé prend un montant (`claim(uint256)`), contrairement à l'ABI publiée. À vérifier sur testnet.
4. Répartir selon les ratios ci-dessus vers les wallets Équipe, Buyback et IA.
5. Wallet IA : swap ETH → USDC, pont vers Base, recharge du solde Surplus Intelligence (qui règle en USDC sur Base).
6. Écrire chaque mouvement dans le registre public, avec le hash de transaction.

## Wallets

| Wallet | Type | Contient |
| --- | --- | --- |
| Collecte | wallet de l'équipe | destinataire des frais $VIVRA, transit seulement |
| Équipe | au choix de l'équipe | 1,7 % |
| Buyback réserve | wallet de l'équipe | l'enveloppe des prochains tokens CTO |
| Buyback opération | hot wallet du Buyback Bot | au plus 24 h de tranches |
| IA | hot wallet opérateur | ETH en transit avant swap et pont |

Toutes les adresses sont publiées sur la dapp et dans la doc.

## Registre public

Une ligne par mouvement, consultable sur la page Revived & ledger : date, type (frais entrants, frais token CTO, tranche buyback, dépense IA, burn $VIVRA), montant en jeton et en USD au moment du mouvement, wallet source, wallet destination, hash de transaction. Une synthèse par semaine est publiée par le bot X.

## Achat de l'équipe au lancement

Les 5 premières secondes d'un lancement Pons v2 portent une taxe d'achat de 99 % qui exempte le wallet créateur. Tout achat de l'équipe à ce moment est annoncé 24 h avant, avec le montant et le wallet.

## Critères d'acceptation

- [ ] Un token de test lancé sur testnet avec `creatorTaxBps` = 300, frais réclamés et répartis au centime près selon 17/15/5.
- [ ] Le registre affiche chaque mouvement avec un hash cliquable.
- [ ] Une recharge Surplus de bout en bout (ETH Robinhood Chain → USDC Base → solde Surplus) documentée.