[PROPOSAL] Election of safety committee members following approval of RIP00015

Sylvain Leroux

Sylvain Leroux They gain access to a private communication channel.

PhilP Pour le comité sur le calcul des pouvoir de vote, il a été créé un Telegram dédié (https://t.me/powervoting_realtoken_dao) pour lequel tout le monde peut lire les échanges, mais seuls les membres du comité peuvent écrire. Ce qui concours à la transparence des échanges, sans les perturber. Ce pourrait être la formule utilisé par ce comité...

JoeD I understand the argument in favor of transparency by using a private communication channel that remains publicly readable. However, when it comes to the security of the ecosystem’s tools, I’m not convinced it’s a good practice to publicly disclose information about the protection of this ecosystem, or its potential vulnerabilities.

I think the two cases are different:

The Powervoting Committee was expected to work on documents or regulations to be submitted for the DAO's vote. The transparency of the debates was of nature to improve the confidence the members will have in these proposals, about the impartiality of the members, and also to keep non-members involved in a loop, eventually raising questions and requests through a public channel while still keeping the Powervoting Committy primary discussion channel focussed.
The Security Committee will have a different usage for that channel. It was mostly designed to coordinate their schedules and discuss internal issues. For now, I see more drawbacks than advantages in making these details publicly known. Or did I overlook some important use cases here?

Sylvain Leroux Security Committee's internal communication channel: Should it be private, or publicly readable?

I explicitly mentioned in the first post that this issue remains open.

Sylvain Leroux

PhilP ajouter l'item suivant : Suivant la performance des membres du comité aux "alerte de formation" et à leur montant déposé, la DAO (sa trésorerie) devra compléter le Safe de dépôt (d'un montant qui serait au maximum 30 % des dépôts, si tous les membres ont 100% de réussite aux alertes de formation)

J'étais en train de faire le changement, et puis ravisé en réalisant qu'on parlait ici des coûts de l'élection à proprement perler, pas des coûts liés à la constitution du Commité de Sécurité.

Cette mention aurait plus eu sa place directement dans la RIP00015, sans oublier que stricto sensu le coût total n'est pas capé par la formule. Cela avait été discuté à l'époque (lien sur le premier post, suivre les réponses pour la discussion complète).

PhilP

Sylvain Leroux

Je proposait de rajouter cet item au chapitre "Conformément au RIP00015 :", ce qui signifie bien que ce sont des rappels de ce qui a été écrit dans cette RIP.
Je pensais pertinent de faire ce rappel, pour qu'on ne pense pas que le comité ne coutait rien à la DAO.. Après on peu en rester là.

Sylvain Leroux

PhilP Un Proposer clôturera la présente proposition en indiquant les candidats retenus et ceux rejetés (pour mémoire, la présente proposition ne donne pas lieu à vote sur Tally, ce sont les candidatures retenues qui seront votés sur Tally).

Done

PhilP Proposition de modification pour ce chapitre, afin permettre un dépôt sur un Safe dédié au dépôt et sur le Vault Incentive :
ajouter après "Ces REG sont déposés dans le coffre-fort du Comité de sécurité" : "(privé et dédié aux dépôts des REG et différent du Safe publique de gestion du Comité)",
remplacer le dernier paragraphe par : Le candidat qui utilisera des REG dans le Vault Incentive devra, à la fin de l'epoch d'incentive en cours, les transférer dans le Safe de dépôt du comité et ainsi atteindre le montant qu'il s'est engagé à déposé (et indiqué dans le formulaire Google form).

Fait, mais es-tu certain de ce passage: "(privé et dédié aux dépôts des REG et différent du Safe publique de gestion du Comité)"

Comme les candidats doivent faire des dépôts dans le Safe, son addresse ne sera pas tellement privée 🤔

Benoist-Not-for-sale

Sylvain Leroux tout à fait:
Le Safe du comité de sécurité sera public, ses signataires seront connus
mais
les membres y participant peuvent déposer leurs REG dans le Safe coffre-fort à partir d'un autre wallet, pas forcément le même que celui avec lequel ils signeront les transactions de participation aux alertes.
Dans ta proposition on parle bien de wallets (possiblement distincts)

Wallet address dedicated to the security committee's activities (will be public)
Wallet address of the candidacy REGs deposit (will be private)
Wallet address holding the required Ledger Quest NFTs (will be private)
Wallet address holding RealTokens for KYC verification (will be private)

PhilP

Sylvain Leroux Comme les candidats doivent faire des dépôts dans le Safe, son addresse ne sera pas tellement privée 🤔

Pour mémoire, j'avais fais la proposition suivante afin d'essayer de préserver au maximum l'anonymat des membres : PhilP .
Dans cette proposition , le Safe de dépôt n'était pas publique, juste connu de RealT (qui le crée) et des membres (qui dépose). Ces dernier ayant intérêt, pour leur anonymat, à ne pas en divulguer son adresse.
Je suis d'accord, qu'avec le temps, cette information finira par être connue. Mais il y a un second niveau de protection avec la correspondance wallet de dépôt (privé) vs wallet de sécurité (publique) connue que de RealT.

PhilP

Sylvain Leroux Done

Il me semble pas que cet ajout soit fait ?

Sylvain Leroux

PhilP Proposition de modifications pour ce chapitre :
remplacer "ouvrir un sujet sur le forum" par "ouvrir une Suggestion sur le forum",
ajouter après "premier message" : "qui pourra être suivi d'une présentation dans sa langue native, dans un second message"

Reformulé pour plus de clarté

être moins strict que "DOIT être conforme au modèle suivant", en mettant plutôt ""devra comprendre au minimum les informations suivantes"

J'ai remplacé MUST par SHOULD (cf RFC 2119)
S'il quelqu'un oublie une info, on pourra toujours lui demander directement.

liste des informations :
Motivation et vision pour postuler au rôle de membre du Comité de sécurité,
Compétence / Expérience dans le domaine de la sécurité du Web3, dans l'usage de Safe Wallet, ..
Depuis quand êtes vous investisseur en Realtoken (vs compétence sur les applications de l'ecosystem : YAM,RMM,Bridge..qui pourront être stoppés par le comité),
Conflits d'intérêts liés à la candidature,
Fuseau horaire de disponibilité,
Adresse du wallet qui sera utilisé pour le Comité.

Noté

Pour "Adresse du wallet qui sera utilisé pour le Comité.", tu es certain que c'est nécessaire (déjà dans le formulaire Googl Form, non?)

PhilP

Sylvain Leroux Pour "Adresse du wallet qui sera utilisé pour le Comité.", tu es certain que c'est nécessaire (déjà dans le formulaire Googl Form, non?)

Les informations dans le Google form , sont un échange privé entre le candidat et RealT.
Pour éviter à RealT d'avoir à publier les informations du google form, qualifiées de publique, autant demander au candidat de les redonner dans sa candidature publique. J'essaie de limiter au maximum la charge pour RealT.

Sylvain Leroux

Benoist-Not-for-sale

Oui tout à fait. Je ne sais pas où j'avais la tête. Merci pour cette clarification. 🙏

PhilP

J'ai complété la proposition :

google form ajouté,
PhilP : traité
Check list mise à jour.

Me semble qu'il ne manque plus que le traitement de ces deux remarques :

PhilP,
PhilP .

Et on va pourra lancer l'appel à candidatures ...le "bout du tunnel approche" !

Sylvain Leroux

PhilP rajouter cet item au chapitre "Conformément au RIP00015 :", ce qui signifie bien que ce sont des rappels de ce qui a été écrit dans cette RIP.
Je pensais pertinent de faire ce rappel, pour qu'on ne pense pas que le comité ne coutait rien à la DAO.. Après on peu en rester là.

On peut couper la poire en deux en formulant pour préciser qu'il s'agit bien des coûts directement entraînés par les processus de vote, et renvoyer à la RIP00015 pour les autres frais.

Si je trouve une formulation adéquate, je fais ça.

[X] Précisions sur les coûts pour la DAO (v4.6-alpha)

Sylvain Leroux

PhilP J'essaie de limiter au maximum la charge pour RealT.

Cela va sans dire. J'essaye d'être dans cet optique également.

PhilP

Sylvain Leroux Remarque : Les candidats DOIVENT choisir de déposer directement leurs REG dans le coffre-fort du Comité de sécurité ou d'utiliser tout ou partie de leur dépôt dans le Coffre-fort d'incitation comme dépôt de garantie.

Afin de simplifier le processus de validation, les candidats NE DOIVENT PAS combiner les deux méthodes de dépôt.

J'avais proposé que cette partie soit remplacée, donc retirée. Le candidat pourra utiliser les deux options en même temps, pour peu qu'il transfert à la fin de l'epoch ce qui manquerait dans le safe de dépôt.

Sylvain Leroux

PhilP J'avais proposé que cette partie soit remplacée, donc retirée. Le candidat pourra utiliser les deux options en même temps, pour peu qu'il transfert à la fin de l'epoch ce qui manquerait dans le safe de dépôt.

Il me semble qu'autoriser à panacher les deux options, c'est ajouter de la complexité pour le traitement ou les vérifications pour pas grand chose: combien de candidats risquent effectivement d'être rebutés par cette contrainte? Surtout considérant les petits sommes et le prix actuel du REG.

Je garde.

Sylvain Leroux

PhilP Il me semble pas que cet ajout soit fait ?

Je cite:

Sylvain Leroux A Proposer will close this proposal by indicating which candidates have been selected and which have been rejected (for the record, this proposal does not give rise to a vote on Tally; it is the Eligible Candidates who will be voted for on Tally).

Autant que je me souvienne, je nétais pas inpiré et j'avais fait une traduction verbatim de ta formulation:

PhilP ajouter la tache suivante : Un Proposer clôturera la présente proposition en indiquant les candidats retenus et ceux rejetés (pour mémoire, la présente proposition ne donne pas lieu à vote sur Tally, ce sont les candidatures retenues qui seront votés sur Tally).

~~Ai-je manqué quelque-chose?~~

Voir https://forum.realtoken.community/d/42-proposal-election-of-safety-committee-members-following-approval-of-rip00015/66 plus loin

Cogatos

Je remets une pièce dans la machine, mais quel est l'intérêt de rendre publique l'adresse de wallet servant aux activités du comité de sécurité ?

Est-ce que cela n'est pas une perche tendue à quiconque souhaiterait faire un lien entre un pseudo et une adresse de wallet ?

PhilP

Cogatos

C'est la solution qui a été utilisée, pour le rôle de Proposer.
Un compromis entre :

la transparence nécessaire pour un rôle opérationnel au sein de la DAO,
et, le respect de la vie privée des membres de la DAO.

Le candidat pourra créer un wallet, dédié son action au sein du comité, préservant ainsi son anonymat (sauf pour le tier de confiance qu'est RealT).

Sylvain Leroux

Cogatos Je remets une pièce dans la machine, mais quel est l'intérêt de rendre publique l'adresse de wallet servant aux activités du comité de sécurité ?

Est-ce que cela n'est pas une perche tendue à quiconque souhaiterait faire un lien entre un pseudo et une adresse de wallet ?

Pas de problème @Cogatos . Merci de ta participation. Personnellement je n'ai pas l'expertise technique pour argumenter dans un sens ou dans l'autre.

Pour paraphraser @Michael-RealT plus haut "c'est un sujet à prendre au sérieux". Mon sentiment, c'est que pour l'instant nous essayons de faire au mieux dans les circonstances actuelles, mais qu'il faudra une policy claire (Définie par qui? Qui est légitime et volontaire sur ces questions?) qui serait adopté dans les futurs cas similaires (Quand?).

N'hésitez pas à proposer des arguments dans un sens ou dans l'autre. Je ne promets rien, mais au moins cela nourrit la réflexion et clarifie les idées de tout le monde—moi le premier.

Sylvain Leroux

PhilP J'ai complété la proposition :

Je regarde les changements (git diff), mais a priori, je te fais confiance pour un travail sérieux.

J'en profite également pour relancer l'idée d'adopter une solution permettant l'édition collaborative des propositions, afin que plusieurs personnes puissent modifier le document de manière concurrente. Évidemment, ma préférence irait vers une solution comme git ou un GitHub avec des pull-requests, mais un simple Google Docs partagé pourrait aussi convenir, non ?

PhilP Me semble qu'il ne manque plus que le traitement de ces deux remarques :
PhilP,
PhilP .

Sur ces deux points, j'ai répondu plus haut.

PhilP le "bout du tunnel approche"

🕳️✨😊 Je suis ravi qu'on y arrive ensemble !

PhilP

Sylvain Leroux
Non c'est pas compliqué et c'est pour cela qu'on demande dans le formulaire : combien de REG seront déposés ?
Si ce chiffre est différent du montant qu'aura déposé le candidat (pendant l'acte de candidature), c'est que le reste viendra du Vault à la fin de l'epoch 2.
Il faudra de toute façon qu'à la fin de l'epoch 2, soit vérifié que tous les dépôts correspondent aux montants qui étaient déclarés, voire relancer ceux qui aurait "oublié" de faire leur transfert (cf engagement que j'ai indiqué dans l'introduction du formulaire).

Sylvain Leroux

Sylvain Leroux Autant que je me souvienne, je nétais pas inpiré et j'avais fait une traduction verbatim de ta formulation:

PhilP ajouter la tache suivante : Un Proposer clôturera la présente proposition en indiquant les candidats retenus et ceux rejetés (pour mémoire, la présente proposition ne donne pas lieu à vote sur Tally, ce sont les candidatures retenues qui seront votés sur Tally).

Ai-je manqué quelque-chose?

Aprés vérif, il semble qu'on se soit mal compris. Pour moi, le sujet étais clos avec la proclamation des résultats. D'après ton changement, le sujet était clos après la sélection des candidats.

La version actuelle(v4.6-alpha) conserve les deux changements. @PhilP Lequel tu veux garder?

« Previous Page Next Page »