[Dev Competition] - On-chain Realtokens balances

AlexRLT

J'utilise les fonctions balanceOf de chaque contrat, il y a pas de stockages de propriétaires 😉

PhilP

AlexRLT
Est ce ainsi que tu fais cela : https://www.perplexity.ai/search/653074dd-92cd-44b1-9446-da62eb44f7d6

DRKTT

AlexRLT mais avec l'arrivé d'un nouveau système de DEX

Cela fait des années qu'on en parle, je n'ai pas l'impression que cela va arriver rapidement.
C'est important de tout montrer tant que cela existe, y compris par exemple ce qui est déposé sur RMM v2 (je sais pas si tu l'as prévu)

D'ailleurs jai juste cité des "inconvénients", j'ai pas dit que c'était pas possible 😉

Ces inconvénients seront malheureusement rédhibitoires pour son utilisation par Crypt'Alloc

AlexRLT

Après le contrat sera upgradable et totalement accessible. rien empêchera de build des nouveautés 🙂

AlexRLT

PhilP plus ou moins 😉

LoganSulpizio

Great idea! I wish I would have had it 😜

AlexRLT

@DRKTT

je vais voir pour ajouter les pools et le RmmV2 😉 j'ai le temps de me pencher dessus de toute façon. la base de la proposition est présente le reste.. du bonus 😃

DRKTT

AlexRLT

Top 🙂 Il ne manquera plus qu'Ethereum et ça sera complet 🙂

AlexRLT

DRKTT

les contrats seront dispo.. si la DAO veut les déployer sur ETH 😉

Par contre ce que je peux te dire... améliorations en cours:

prise en charge du RMM v2
prise en charge des pool uniswap V2
et bonus... tout les prix des oracles pour les realtokens sur le meme principe 🙂

En +/- 7 requêtes, on peut obtenir une valeur USD de tout nos realtokens sur Gnosis si tout est ok 🥸

AlexRLT

ehpst

Aucuns soucis, et oui c'est très proche des multi-call bien que la structure soit différente.

Mon apprentissage personnel est bien plus important que gagner un concours 😉 et si c'est jugé "déjà existant", je n'aurais pas fait ça pour rien malgré tout 😊

Par ailleurs :

AlexRLT
prise en charge du RMM v2
prise en charge des pool uniswap V2
et bonus... tout les prix des oracles pour les realtokens sur le même principe 🙂

Tout les realtokens n'ont pas encore d'oracle d'après l'API donc pour ces derniers, ce sera évidement en fonction de la disponibilité.

Pour le reste.. il restera des tests a faire mais ça avance dans le bon sens

EzSwim

I like this idea. I sure it will help the developer community greatly, which in turn will benefit the DAO.

AlexRLT Currently, only the owner can add/remove tokens, readers, or wrappers

I am guessing the owner will also be able to update the contract. How do you suggest the DAO defines the owner? Adding/removing tokens will be a weekly task. We can't have a vote every week to add a new RealTokens in an existing/new redear, can we ?

AlexRLT 🔍 Checks if each token is already listed via isListed()
📦 Attempts to add it to an existing reader if space is available
🏗️ If all readers are full ➜ automatically deploys a new Reader
🛡️ Prevents duplicates through internal filtering

I am very curious to see the implementation and gas cost (that the DAO will have to pay each time a new RealToken is sold by RealT if understood correctly) as it could very well be a blocking factor to deploy the solution to Ethereum.

AlexRLT

EzSwim je ne vois pas l'intérêt de mettre au vote le "maintient" à jours de ce contrat... Après, si je suis retenu et qu'il faut absolument faire des votes... Bah écoute 😁😁

Par ailleurs, il y aura toujours la possibilité d'upgrade le contrat avec des rôles, ou bien une liste d'adresses autorisés en plus du owner.

Aucunes utilisations "critiques" avec ces contrats et aucuns risques.

Et oui, sur ETH c'est pas viable du tout, maintenant je suis "amateur". Les optimisations seront sûrement possible ! Sur Gnosis c'est clairement pas problématique.

EzSwim

AlexRLT je ne vois pas l'intérêt de mettre au vote le "maintient" à jours de ce contrat... Après, si je suis retenu et qu'il faut absolument faire des votes... Bah écoute 😁😁

Ok so you will be the owner. Got it, I wanted to make sure I understood properly 🙂

AlexRLT Par ailleurs, il y aura toujours la possibilité d'upgrade le contrat avec des rôles, ou bien une liste d'adresses autorisés en plus du owner.

Cool 👍️

AlexRLT Aucunes utilisations "critiques" avec ces contrats et aucuns risques.

Yup there is no real risk since it's read-only for users 🙂.
The only risk is breaking changes for developers who will use the solution, but people building on the blockchain should be accustomed to this haha

I find your solution to be elegant and the type of infrastructure the DAO needs at the moment. I am truly glad you suggested it! I can't wait to see the code ^^

Benoist-Not-for-sale

Each instance tracks up to 500 RealTokens
🔹 Reader contracts are automatically deployed if needed (max capacity 500 tokens/reader)

Why 500 (and not 42 or 1024), is there a technical limitation ?

Chaque instance peut suivre jusqu’à 500 RealTokens
🔹 Les contrats Reader sont automatiquement déployés si nécessaire (capacité max 500 tokens / readers)

Pourquoi 500 (et pas 42 ou 1024), y a t-il une limite technique ?

AlexRLT

Benoist-Not-for-sale

Lors de mes tests, j'ai pris cette limite arbitraire pour pas que ça casse tout ( en me laissant de la marge ).

ehpst

I'm trying to share the enthusiasm but can't help thinking that it's a complex replacement of a multicall of balanceOf.
I currently use multicall to get balances of a user and it works fine with a single query for all current RealTokens (700) in about 1 second. Would it be quicker maybe with this solution?
So while it looks really neat to have it in a solidity smart contract, it seems a bit too much for an existing function. Maybe I don't see the full potential of the proposal.
Please don't misunderstand me, I appreciate the idea and the effort of the presentation of Alexis.
My 2 cents 🙂

DRKTT

AlexRLT Mon apprentissage personnel est bien plus important que gagner un concours 😉 et si c'est jugé "déjà existant", je n'aurais pas fait ça pour rien malgré tout 😊

T'es aussi là pour la tech ? ^^

Yohann76

I fully support this project.

If I've understood correctly, the results of this project could be used in various applications in the ecosystem to replace TheGraph, which is often out of order.

I think this type of project is very important to make the ecosystem more stable over time.

Stability is important when we want to grow, gain in popularity, communicate etc... This will provide a better user experience for our DAO.

ehpst

Yohann76 As mentioned above, a multicall can easily replace TheGraph without deploying a new smart contract. It's actually already the case in some of the community applications.

EzSwim

ehpst

I tend to disagree. The contracts probably needs a little tweak, but Once the DEX is released, It will be possible to have more data returned (enrich the struct) such as the market price (the contract names might be off however). Or did I misunderstood @AlexRLT ?
When using Wagmi or Viem (or whatever library used to request the blockchain) you always have to loop and call the blockchain multiple times (and therefore manage errors and exceptions). It's a pain having to request for both the balanceOf and the supply just to display the % owned by a wallet for instance. Now the question remains how fast is this solution compared to a multicall. IDK but If done right (with indexes or pagination maybe instead of the full reader) it could be a standard which would improve the qualities of all the Realtoken Dapps (and save development time).