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

Sylvain Leroux

v4.6
🇫🇷 Disponible en FR dans le deuxième post
🇺🇸

Proposal Summary

Following the approval of RIP00015, we are now entering the election process for the RealToken Security Committee members.
This proposal therefore aims to validate the voting process.

The process will take place in two distinct phases.

Phase 1: Application process and pre-selection (on the governance forum in the "Candidacy" section)
Phase 2: Election and committee formation (which will be submitted to DAO vote)

RealT will be responsible for the technical verifications of applications to ensure candidates meet all criteria established in RIP00015.
As a DAO partner, RealT acts as a trusted party for this proposal to preserve the confidentiality of candidates who are free to disclose or withhold private information.

Note: The English version of this document serves as the only authoritative reference.

Motivation

Establish a transparent and fair process for selecting the RealToken DAO's Security Committee Members in accordance with the criteria established in RIP00015.

Detailed Specifications

1. Announcement

The opening of the application process will be announced on Telegram and Discord.

2. Application Submission (phase 1, duration: 2 weeks)

The application is reserved for individuals holding at least one RealToken (including RWA Holdings) and having completed the KYC with RealT at the time of their submission.

The same individual SHALL NOT submit more than one application.

The Potential Candidates have 2 weeks from the Announcement to make themselves known.
Each Potential Candidate MUST complete the following three tasks during that period.

2.1. Opening of a dedicated topic on the forum

Each Potential Candidate MUST create a new suggestion with their presentation post in the forum suggestion section:
- The initial candidates' presentation message MUST be written in English.
- The candidate MAY post a presentation in their mother tongue in a 2nd post for better understanding.
- The candidates' presentation message SHOULD follow the template given in the annex.
- The candidates present themselves and explain how they meet this position's criteria (notably, their competencies and awareness of the Web3 threats and security issues).
After the initial presentation post(s), this topic becomes a free debate space between the candidate and the community.

2.2. Completing the candidacy Google Forms form

Each Potential Candidate fills out a Google Form form providing the required information (details below) to validate their candidacy : https://forms.gle/DwPagNd8p33CjXc48

The Potential Candidate MUST ensure they satisfy all the requirements for candidacy as specified in the RIP00015 by the end of the Application Submission period.

2.3. REG deposit

As explained in the RIP00015, each Potential Candidate MUST lock between 250 and 1,000 REGs as a security deposit at application time.
These REGs are locked into the Security Committee Safe (private and dedicated to REG deposits and different from the Committee's public management Safe), whose address will be provided by RealT.
If an incentive epoch is ongoing, a Potential Candidate MAY choose, when filling out the Google Form form, to use all or part of their Incentive Vault deposit as that security deposit.
Candidates who chose to use REGs in the Vault Incentive MUST, at the end of the current incentive epoch, transfer them to the committee's Safe Deposit Account and thus reach the amount they have committed to deposit (and indicated in the Google form).

Note: At the end of the incentive epoch, the candidates' depots will be checked to ensure they have fulfilled their engagements.

3. Eligibility check (phase 1, duration: 2 weeks)

At the start of this period, the Google Form form is closed.
No new application submissions will be accepted.

Note: The discussions and community debates may continue on the forum during this period.

3.1. Eligibility Check

RealT has 1 week to verify the technical eligibility criteria (KYC, REGs deposit in the Safe, possession of the required NFT) of the Potential Candidates.

The Potential Candidates that meet the eligibility criteria are accepted and become Eligible Candidates.
The Potential Candidates that don't meet the eligibility criteria are rejected.

RealT posts a short message on each candidate's topic to officially inform them that their candidacy was accepted or rejected.
The rejection reasons (without details) will be specified in that latter case.
The publication of that message informs the proposers they may proceed with the next step.

3.2. Publication of the eligible candidates' list

The Proposers have 1 week to complete the following tasks:

A Proposer moves the dedicated topic of Eligible Candidates into the forum candidacy section.
A Proposer moves the dedicated topec for rejected candidates into the forum cancelled suggestions section.
A Proposer prepares the upcoming vote on Tally.
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).

4. On-chain vote (phase 2, 1 or 3 weeks):

As defined in the RIP00015:

(a) If there are 10 Eligible Candidates or fewer, a single on-chain vote is proposed to approve all candidates at once.
(b) If there are more than 10 Eligible Candidates or if the global approval (a) is rejected, an on-chain vote per candidate is proposed.

4.1. Global vote

If there are 10 Eligible Candidates or fewer, a single on-chain vote is proposed to approve all candidates at once.

All the Eligible Candidates are elected if and only if all of the following conditions are fulfilled:

The total Voting Power participating MUST equal or exceed the Quorum threshold.
The total "For" MUST strictly exceed the total "Against" votes.

If the aforementioned conditions are not met, the vote will not result in any Security Committee members' election, and we will proceed with the 4.2 step.

4.2. Individual votes

If there are more than 10 Eligible Candidates or the global approval (a) is rejected, an on-chain vote per candidate is proposed.
If that step follows a global approval (a) rejection, 1 week is reserved for the Proposers to draft the individual proposals on Tally.

An Eligible Candidate can be elected if and only if all of the following conditions are fulfilled for their dedicated vote:

The total Voting Power participating MUST equal or exceed the Quorum threshold.
The total "For" MUST strictly exceed the total "Against" votes.

If more than 10 candidates satisfy these requirements, the 10 Eligible Candidates with the most "For" votes are elected.
Draw disputes will be resolved by already-elected members.

5. Committee Formation (phase 2, up to 2 weeks):

The list of elected members is also announced on the Discord and Telegram RealToken DAO governance channels.
The elected Security Committee members gain access to a private communication channel.
RealT organizes training sessions within two weeks to ensure the Security Committee is fully operational at the end of that period.

Roadmap

Weeks 1-2: Application submissions
Week 3: Eligibility Check
Week 4: (if ≤10 candidates) Global Election Proposal drafting
Week 5: (if ≤10 candidates) Global Election On-chain Vote
Week 6: (optional) Individual Candidate Proposal drafting
Week 7: (optional) Individual Candidate On-chain Vote

Team

Discord and Telegram Team: Announcements
DAO: Participation in debates and final vote
RealT: Security Committee Safe creation and management
RealT: Google Form form publication and collection
RealT: Technical verification of applications
RealT: Formation
Proposers: Move the candidates' topics to their correct location on the forum.
Proposers: Prepare the vote(s) on Tally.
Forum, Discord, or Telegram Team: Creation of a private communication channel for the Security Committee members

Financial Implications

The election itself does not entail any direct costs for the DAO.
For other costs related to the Safety Committee, please refer to RIP00015.

Cost for candidates: 250 to 1000 REGs locked in the Security Committee Safe.

In accordance with the RIP00015:

For non-elected candidates, the deposit is released after the Committee Formation.
For elected candidates, the deposit remains locked until their term's expiration.

Objectives

Select 10 qualified Security Committee Members
Ensure a transparent and fair process
Enable maximum community participation

Success Metrics

Minimum 10 eligible applications received

Appendix

A. Application Google Form form

Required information:

Governance forum username (will be public)
Wallet address dedicated to the security committee's activities (will be public)
Amount of REGs the candidate wants to deposit (will be private)
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)
Email used on RealT.co for KYC verification (will be private)

The form link: To Be Defined

B. Template for the candidacy

As per 2.1. in this document, each Potential Candidate MUST open a topic on the forum, with their presentation in English in the first post.
This presentation post SHOULD conform to the following template:

Motivation and vision for applying to the Security Committee member role

<candidate statements>

Competencies / Experience in Web3 security, in the use of Safe Wallet, ...

<candidate statements>

How long have you been an investor in Realtoken

<candidate statements detailing competencies in ecosystem applications: YAM, RMM, Bridge... which may be stopped by the committee>

Conflicts of interest related to the application

<candidate statements>

Time zone of availability,

<candidate statements>

Address of the wallet to be used by the committee.

<candidate statements>

Key Terms

Eligible Candidate: Potential Candidates meeting all technical criteria of RIP00015.
KYC: Know Your Customer, a verification process to ensure identity compliance.
On-chain Vote: A governance vote that occurs directly on the blockchain, creating an immutable record of the voting process and results.
Potential Candidate: A member of the DAO who has applied for the role of Security Committee member.
Proposer: A DAO member responsible for submitting proposals and the right to submit on-chain proposals.
Quorum: The minimum amount of For and Abstain votes required for a proposal to be considered valid.
REGs: The governance tokens used within the RealToken DAO ecosystem.
Safe: A multi-signature digital wallet (formerly known as Gnosis Safe) that requires multiple approvals before executing transactions, used by the DAO to securely manage treasury funds and execute approved proposals.
Security Committee Safe: The specific multi-signature wallet used by the Security Committee members to respond to emergencies and manage security-related aspects of the DAO's operations.
Tally: The voting platform used by the RealToken DAO to conduct governance votes and track proposal outcomes.
Voting Power: The influence a participant has in governance decisions, dependent on the amount of governance tokens (REG) they hold.

Discussion Points

~~- Detailed Specifications: Are the outlined processes clear and efficient? Any suggestions for improvement?~~
~~- Team: Is the distribution of responsibilities appropriate? Should any roles be adjusted?~~
~~- Template for Candidacy: Does the proposed template cover all necessary information? Are there additional details candidates should provide?~~
~~- Security Committee's internal communication channel: Should it be private, or publicly readable?~~

Check-list

( 🔲 : under discussion / ✅ : finalized / ❎: not applicable )

✅ Proposal Summary
✅ Motivation
✅ Detailed Specifications
✅ Roadmap
✅ Team
✅ Financial Implications
✅ Objectives
✅ Success Metrics
✅ Google Form
✅ Template for candidacy
✅ Key terms

Sylvain Leroux

Template de candidature

EzSwim Est-ce qu'il y aura un template pour la candidature (un peu comme pour les proposers) pour facilité la comparaison pour les lecteurs ?

C'est une bonne idée.

Est-ce que cela avait été formalisé au lors de la définition des conditions d'élection ou autrement? J'ai fait une recherche (très [trop?]) rapide et e n'ai pas trouvé.

Remarques

Remarques (en me relisant ce matin 💩 ):

Sur la vérification des candidatures

Benoist-Not-for-sale je ne vois pas (pour l'instant) quelle serait la légitimité d'un postulant qui n'aurait pas investi* dans RealT.

Il serait peut-être bon de rappeler en préambule que les candidatures ne sont ouvertes qu'à des personnes physiques et possédant au moins un RealToken (pour la vérification du KYC). Ã moins qu'on accepte un KYC effectué par RealT sans achat de RealToken?

Il serait peut-être souhaitable de préciser une seule candidature par personne physique?

Sur le mécanisme de vote:

Sylvain Leroux (a) S'il y a 10 candidats éligibles ou moins, un seul vote en chaîne est proposé pour approuver tous les candidats en même temps.
(b) S'il y a plus de 10 candidats éligibles ou si l'approbation globale (a) est rejetée, un vote en chaîne par candidat est proposé.
Les 10 candidats éligibles ayant obtenu le plus grand nombre de « oui » sont élus.

Avec ce système, si nous avons 10 candidats ou moins, ils seront forcément tous élus: soit tous d'un coup par le vote (a), soit individuellement par le vote (b) puisqu'ils feront de facto tous parti 10 premiers.

A minima, il faudrait spécifier que pour être élu il faut "plus de oui que de non" (ou similaire basé sur le quorum) pour permettre d’écarter un candidat polémique.

On peut aussi se poser la question de supprimer le cas de vote (a). Mais cela a été voté comme ça dans la RIP00015. Or les présentes modalités d'élection ne seront pas votées on-chain, et je ne veux pas qu'une discussion sur le forum puisse aller contre un choix voté par la DAO.

Sur le forum

Sylvain Leroux The opening of the application process will be announced [...] via a dedicated topic on the DAO forum.

Sylvain Leroux Each Potential Candidate MUST open a presentation post in the forum candidate debate space:

Sylvain Leroux At the end of that period, the list of Potential Candidates is published on the forum, specifying if they were accepted or rejected.

Suite aux différents remaniement du document, il devient ambiguë du comprendre en le lisant s'il y aura (a) Un poste par "Potential Candidate" ouvert par l'intéressé, ou (b) Un poste pour l'élection ouvert par l'équipe forum (?), ou les deux.

Il me semble que l'idée sur laquelle nous étions resté c'était chaque candidate ouvre son poste de candidature personnel mais je veux bien que vous clarifiez ce point:

Options:

Le candidat ouvre son propre poste (grâce au "role Candidate") qui lui est attribué par l'équipe à réception du formulaire de candidature
À réception du formulaire de candidature, l'équipe ouvre un poste pour le candidat qu'il devra ensuite compléter et gérer.
L'ẽquipe ouvre un poste pour l'election pours les discussions générales et pour les différentes annonces.

Question:
Clarifier des options 1), 2) et 3) ci-dessus lesquels sont retenues.

Action

[X] Ajouter en annexe un "template" de candidature (v4.5)
[X] Préciser "personne physique"
[X] Clarifier le principe de vote
~~[ ] Clarifier s'il y a un poste pas candidat + un poste pour l’élection~~

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 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

Sylvain Leroux

v4.6
🇫🇷 Disponible en FR dans le deuxième post
🇺🇸

Résumé de la proposition

Suite à l'approbation de RIP00015, nous entrons maintenant dans le processus d'élection des membres du comité de sécurité RealToken.
Cette proposition vise donc à valider le processus de vote.

Le processus se déroulera en deux phases distinctes.

Phase 1 : Processus de candidature et présélection (sur le forum de gouvernance dans la section « Candidature »)
Phase 2 : Election et formation du comité (qui sera soumis au vote de la DAO)

RealT sera responsable des vérifications techniques des candidatures afin de s'assurer que les candidats répondent à tous les critères établis dans RIP00015.
En tant que partenaire de la DAO, RealT agit en tant que partie de confiance pour cette proposition afin de préserver la confidentialité des candidats qui sont libres de divulguer ou non des informations privées.

Note : La version anglaise de ce document est la seule référence faisant autorité.

Motivation

Établir un processus transparent et équitable pour sélectionner les membres du comité de sécurité de la DAO RealToken conformément aux critères établis dans RIP00015.

Spécifications détaillées

1. Annonce

L'ouverture du processus de candidature sera annoncée sur Telegram et Discord.

2. Soumission de la candidature (phase 1, durée : 2 semaines)

La demande est réservée aux personnes détenant au moins un RealToken (y compris RWA Holdings) et ayant complété le KYC avec RealT au moment de leur soumission.

La même personne NE DOIT PAS soumettre plus d'une candidature.

Les candidats potentiels disposent de deux semaines à compter de l'annonce pour se faire connaître.
Chaque candidat potentiel DOIT accomplir les trois tâches suivantes au cours de cette période.

2.1. Ouverture d'un sujet dédié sur le forum

Chaque candidat potentiel DOIT créer une nouvelle suggestion avec son message de présentation dans la [section suggestion du forum] (https://forum.realtoken.community/t/suggestions) :
- Le message de présentation du candidat initial DOIT être rédigé en anglais.
- Le candidat peut poster une présentation dans sa langue maternelle dans un second message pour une meilleure compréhension.
- Le message de présentation des candidats DEVRAIT suivre le modèle donné en annexe.
- Les candidats se présentent et expliquent comment ils répondent aux critères de ce poste (notamment leurs compétences et leur connaissance des menaces et des problèmes de sécurité du Web3).
Après le(s) message(s) de présentation initial(aux), ce sujet devient un espace de débat libre entre le candidat et la communauté.

2.2. Remplir le formulaire Google Forms de candidature

Chaque candidat potentiel remplit un formulaire Google Form en fournissant les informations requises (détails ci-dessous) pour valider sa candidature : https://forms.gle/DwPagNd8p33CjXc48

Le candidat potentiel DOIT s'assurer qu'il remplit toutes les conditions de candidature spécifiées dans le RIP00015 avant la fin de la période de dépôt des candidatures.

2.3. Dépôt du REG

Comme expliqué dans le document RIP00015, chaque candidat potentiel DOIT bloquer entre 250 et 1 000 REG à titre de dépôt de garantie au moment de la candidature.
Ces REG sont bloqués dans le coffre-fort du Comité de sécurité (privé et dédié aux dépôts de REG et différent du coffre-fort public de gestion du Comité), dont l'adresse sera fournie par RealT.
Si une période d'incitation est en cours, un candidat potentiel PEUT choisir, lorsqu'il remplit le formulaire Google, d'utiliser tout ou partie de son dépôt dans le coffre-fort d'incitation comme dépôt de sécurité.
Les candidats qui ont choisi d'utiliser des REG dans le cadre de l'incentive Vault DOIVENT, à la fin de l'époque d'incentive en cours, les transférer sur le compte de dépôt de garantie du comité et atteindre ainsi le montant qu'ils se sont engagés à déposer (et qu'ils ont indiqué dans le formulaire Google).

**A la fin de l'époque de l'incentive, les dépôts des candidats seront vérifiés pour s'assurer qu'ils ont bien rempli leurs engagements.

3. Contrôle d'éligibilité (phase 1, durée : 2 semaines)

Au début de cette période, le formulaire Google Form est fermé.
Aucune nouvelle candidature ne sera acceptée.

**Les discussions et les débats communautaires peuvent se poursuivre sur le forum pendant cette période.

3.1. Vérification de l'éligibilité

RealT dispose d'une semaine pour vérifier les critères d'éligibilité techniques (KYC, dépôt des REG dans le coffre-fort, possession du NFT requis) des Candidats potentiels.

Les Candidats potentiels qui répondent aux critères d'éligibilité sont acceptés et deviennent des Candidats éligibles.
Les candidats potentiels qui ne répondent pas aux critères d'éligibilité sont rejetés.

RealT publie un court message sur le sujet de chaque candidat pour l'informer officiellement que sa candidature a été acceptée ou rejetée.
Les raisons du rejet (sans détails) seront précisées dans ce dernier cas.
La publication de ce message informe les proposants qu'ils peuvent passer à l'étape suivante.

3.2. Publication de la liste des candidats éligibles

Les auteurs de propositions disposent d'une semaine pour accomplir les tâches suivantes :

Un proposant déplace le sujet dédié aux candidats éligibles dans la [section candidature du forum] (https://forum.realtoken.community/t/candidacy).
Un proposant déplace le sujet dédié aux candidats rejetés dans la section forum cancelled suggestions.
Un proposant prépare le prochain vote sur Tally.
Un proposant clôturera cette proposition en indiquant quels candidats ont été sélectionnés et lesquels ont été rejetés (pour mémoire, cette proposition ne donne pas lieu à un vote sur Tally ; ce sont les candidats éligibles qui feront l'objet d'un vote sur Tally).

4. Vote en chaîne (phase 2, 1 ou 3 semaines) :

Tel que défini dans le RIP00015 :

(a) S'il y a 10 candidats éligibles ou moins, un seul vote en chaîne est proposé pour approuver tous les candidats en même temps.
(b) S'il y a plus de 10 candidats éligibles ou si l'approbation globale (a) est rejetée, un vote en chaîne par candidat est proposé.

4.1. Vote global

S'il y a 10 candidats éligibles ou moins, un seul vote en chaîne est proposé pour approuver tous les candidats en même temps.

Tous les candidats éligibles sont élus si et seulement si toutes les conditions suivantes sont remplies :

Le nombre total de voix participantes DOIT être égal ou supérieur au seuil de quorum.
Le total des votes « pour » DOIT être strictement supérieur au total des votes « contre ».

Si les conditions susmentionnées ne sont pas remplies, le vote n'aboutira à l'élection d'aucun membre du comité de sécurité et nous passerons à l'étape 4.2.

4.2. Votes individuels

S'il y a plus de 10 candidats éligibles ou si l'approbation globale (a) est rejetée, un vote sur chaîne par candidat est proposé.
Si cette étape fait suite à un rejet de l'approbation globale (a), une semaine est réservée aux proposants pour rédiger les propositions individuelles sur Tally.

Un candidat éligible peut être élu si et seulement si toutes les conditions suivantes sont remplies pour son vote dédié :

Le nombre total de voix participantes DOIT être égal ou supérieur au seuil de quorum.
Le total des votes « pour » DOIT être strictement supérieur au total des votes « contre ».

Si plus de 10 candidats remplissent ces conditions, les 10 candidats éligibles ayant obtenu le plus grand nombre de voix « pour » sont élus.
Les litiges relatifs au tirage au sort seront résolus par les membres déjà élus.

5. Formation du comité (phase 2, jusqu'à 2 semaines) :

La liste des membres élus est également annoncée sur les canaux de gouvernance Discord et Telegram RealToken DAO.
Les membres élus du Comité de sécurité ont accès à un canal de communication privé.
RealT organise des sessions de formation dans les deux semaines pour s'assurer que le Comité de sécurité est pleinement opérationnel à la fin de cette période.

Feuille de route

Semaines 1-2 : Soumission des candidatures
Semaine 3 : Vérification de l'éligibilité
Semaine 4 : (si ≤10 candidats) Rédaction de la proposition d'élection globale
Semaine 5 : (si ≤10 candidats) Vote en chaîne pour l'élection mondiale
Semaine 6 : (facultatif) Rédaction de la proposition de candidature individuelle
Semaine 7 : (facultatif) Vote en chaîne des candidats individuels

Équipe ##

Équipe Discord et Telegram** : Annonces
DAO : Participation aux débats et au vote final
RealT : Comité de sécurité Création et gestion du coffre-fort
RéalT : Publication et collecte des formulaires Google Form
RéalT : Vérification technique des applications
RéalT : Formation
Proposants : Déplacer les sujets des candidats à leur emplacement correct sur le forum.
Proposants : Préparer le(s) vote(s) sur Tally.
Équipe du forum, de Discord ou de Telegram** : Création d'un canal de communication privé pour les membres du Comité de sécurité.

Implications financières

L'élection elle-même n'entraîne aucun coût direct pour la DAO.
Pour les autres coûts liés au Comité de Sécurité, veuillez vous référer à RIP00015.

Coût pour les candidats : 250 à 1000 REGs enfermés dans le coffre du comité de sécurité.

Conformément au RIP00015 :

Pour les candidats non élus, la caution est libérée après la formation du comité.
Pour les candidats élus, la caution reste bloquée jusqu'à l'expiration de leur mandat.

Objectifs

Sélectionner 10 membres qualifiés du comité de sécurité
Garantir un processus transparent et équitable
Permettre une participation maximale de la communauté

Indicateurs de réussite

Réception d'au moins 10 candidatures éligibles

Annexe

A. Formulaire Google de demande

Informations requises :

Nom d'utilisateur du forum de gouvernance (sera public)
Adresse du portefeuille dédié aux activités du comité de sécurité (sera publique)
Montant de REGs que le candidat souhaite déposer (sera privé)
Adresse du portefeuille de dépôt des REGs de la candidature (sera privée)
Adresse du portefeuille contenant les NFTs Ledger Quest nécessaires (sera privée)
Adresse du portefeuille contenant les RealTokens pour la vérification KYC (sera privée)
Email utilisé sur RealT.co pour la vérification KYC (sera privé)

Le lien du formulaire : To Be Defined (à définir)

B. Modèle de candidature

Conformément au point 2.1. du présent document, chaque candidat potentiel DOIT ouvrir un sujet sur le forum, avec sa présentation en anglais dans le premier message.
Ce message de présentation DEVRAIT être conforme au modèle suivant :

Motivation et vision de la candidature au rôle de membre du Comité de sécurité

<déclarations du candidat>

Compétences / Expérience en matière de sécurité Web3, d'utilisation de Safe Wallet, ...

<candidate statements>

Depuis combien de temps êtes-vous investisseur dans Realtoken ?

<déclarations des candidats détaillant les compétences dans les applications de l'écosystème : YAM, RMM, Bridge... qui peuvent être arrêtées par le comité.

Conflits d'intérêts liés à la candidature

<Déclarations des candidats>

Fuseau horaire de disponibilité,

<candidate statements>

Adresse du portefeuille à utiliser par la commission.

<Déclarations des candidats>

Termes clés

Candidat éligible : Candidats potentiels répondant à tous les critères techniques de RIP00015.
KYC : Connaissance du client, processus de vérification visant à garantir la conformité de l'identité.
Vote sur la chaîne** : Un vote de gouvernance qui se produit directement sur la blockchain, créant un enregistrement immuable du processus de vote et des résultats.
Candidat potentiel** : Un membre de la DAO qui a postulé pour le rôle de membre du Comité de sécurité.
Candidat potentiel** : Un membre de la DAO qui a postulé pour le rôle de membre du Comité de sécurité : Un membre de la DAO responsable de la soumission des propositions et le droit de soumettre des propositions sur la chaîne.
Quorum** : Le nombre minimum de votes « Pour » et « Abstention » requis pour qu'une proposition soit considérée comme valide.
REGs : Les jetons de gouvernance utilisés dans l'écosystème DAO RealToken.
Safe : Un portefeuille numérique multi-signature (anciennement connu sous le nom de Gnosis Safe) qui nécessite des approbations multiples avant d'exécuter des transactions, utilisé par la DAO pour gérer en toute sécurité les fonds de trésorerie et exécuter les propositions approuvées.
Coffre-fort du Comité de sécurité** : Le portefeuille multi-signature spécifique utilisé par les membres du Comité de Sécurité pour répondre aux urgences et gérer les aspects liés à la sécurité des opérations de la DAO.
Tally : La plateforme de vote utilisée par la DAO RealToken pour conduire les votes de gouvernance et suivre les résultats des propositions.
Pouvoir de vote** : L'influence d'un participant sur les décisions de gouvernance, qui dépend de la quantité de jetons de gouvernance (REG) qu'il détient.

Points de discussion

~~- Spécifications détaillées: Les processus décrits sont-ils clairs et efficaces ? Avez-vous des suggestions d'amélioration ?~~
~~- Équipe: La répartition des responsabilités est-elle appropriée ? Les rôles doivent-ils être modifiés ?~~
~~- Modèle de candidature: Le modèle proposé couvre-t-il toutes les informations nécessaires ? Y a-t-il des détails supplémentaires que les candidats devraient fournir ?~~
- Canal de communication interne du comité de sécurité: Doit-il être privé ou accessible au public ?~~~

Check-list

( 🔲 : en cours de discussion / ✅ : finalisé / ❎ : sans objet )

✅ Résumé de la proposition
✅ Motivation
✅ Spécifications détaillées
✅ Feuille de route
✅ Équipe
✅ Implications financières
✅ Objectifs
✅ Mesures de réussite
✅ Formulaire Google
✅ Modèle de candidature
✅ Termes clés

Automatic translation by DeepL

Cogatos

Sylvain Leroux Adresse du portefeuille dédié aux activités du comité de sécurité (sera publique)

Afin de garantir la "sécurité" des membres ou rendre plus difficile l'identification de leur wallet associé au comité, ne faudrait-il pas que les adresses de wallet devant servir aux travaux du comité soient privées et non publiques (sous réserve d'avoir bien compris l'idée) ? Ou alors cela est "obligatoire" dans un souci de transparence ?

À propos du template, ne serait-il pas possible de s'inspirer du modèle pour les candidatures en tant que proposers ou membres du comité sur le Power Voting ? Il suffirait de changer quelques intitulés et ça pourrait faire gagner du temps plutôt que repartir sur un nouveau ?

PhilP

Sylvain Leroux Modèle de candidature

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"
être moins strict que "DOIT être conforme au modèle suivant", en mettant plutôt ""devra comprendre au minimum les informations suivantes"
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é.

PhilP

Sylvain Leroux Dépôt du REG

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).

PhilP

Merci @Sylvain Leroux pour cette suggestion.
Pour t'aider, j'ai mis la version FR (ce qui m'aide aussi!).
Cette première version me semble devoir être complétée, comme mentionné dans mon message Telegram :
https://t.me/realtokendao_official/3/8472

cette proposition, semblable à https://forum.realtoken.community/d/26, ne sera pas votée,
le dépôt de candidature se fait uniquement en remplissant le formulaire, il n'y a donc pas d'échanges avec la communauté à ce stade et "la réponse aux critères" est très simplifiée sur le formulaire : qu'il faut préparer pour le soumettre à @Michael-RealT
après analyse et publication des candidatures retenues par RealT, chaque candidat devra alors ouvrir une suggestion de candidat dans laquelle il détaillera sa motivation et répondra aux questions.
puis on basculera au vote sur Tally..
..

Je te propose de déjà revoir ces points, avant de passer aux autres..
Merci encore pour ta mobilisation.

Sylvain Leroux

PhilP Merci @Sylvain Leroux pour cette suggestion.
Pour t'aider, j'ai mis la version FR (ce qui m'aide aussi!).

Merci à toi, Phil, pour ton support.

PhilP Cette première version me semble devoir être complétée, comme mentionné dans mon message Telegram :
https://t.me/realtokendao_official/3/8472

[X] Cette Proposal ne sera pas voté en tant que telle sur Tally, mais sera close dès que les candidatures seront validées par RealT et soumises au vote sur Tally. À confirmer: https://t.me/realtokendao_official/3/8535
[X] ~~précision concernant le Vault (qui sera plutôt celui d'incentive qu'un nouveau Vault),~~ Pas de Vault. cf ci-dessous.
[ ] précision ou pas ?...sur une phase 2 du mode d'élection (cf proposal des modes d'élection des Proposer). À discuter: la RIP00015 avait clarifié ce point. Je ne vois pas de raisons de changer ce qui a déjà été voté.
[ ] établir le formulaire propre à cette élection, le proposer à @Skyline_ch pour qu'il le mette en place et nous donne le lien correspondant (OK, j'avais pas percuté: vous voulez le Google Form clé en main—je vais apprendre un nouveau truc 😃)

Pour mémoire:

[X] je dois aussi remplacer Vault par Safe: https://t.me/realtokendao_official/3/8523
[X] Et indiquer la possibilité d'utiliser des REG lockés dans le Vault Intencives en garantie: https://t.me/realtokendao_official/3/8510

cette proposition, semblable à https://forum.realtoken.community/d/26, ne sera pas votée,

le dépôt de candidature se fait uniquement en remplissant le formulaire, il n'y a donc pas d'échanges avec la communauté à ce stade et "la réponse aux critères" est très simplifiée sur le formulaire : qu'il faut préparer pour le soumettre à @Michael-RealT

après analyse et publication des candidatures retenues par RealT, chaque candidat devra alors ouvrir une suggestion de candidat dans laquelle il détaillera sa motivation et répondra aux questions.

puis on basculera au vote sur Tally..

..

OK. Je note. Je vérifie que tout est conforme à la RIP00015—et ça roule.

PhilP

Sylvain Leroux précision ou pas ?...sur une phase 2 du mode d'élection (cf proposal des modes d'élection des Proposer). À discuter: la RIP00015 avait clarifié ce point. Je ne vois pas de raisons de changer ce qui a déjà été voté.

Il y a une confusion dans mon propos.

ce n'est pas la Phase 2 de https://forum.realtoken.community/d/26, qui me semblait devoir être détaillée ou pas,
mais les étapes 3 et 4 (après les 6 mois, puis sans élection) décrite dans le RIP00005 : https://forum.realtoken.community/d/16 .. A voir si cela doit apparaitre dès à présent ou si cela fera l'objet d'autre complément de proposition.
À la réflexion, ce sera une autre proposition puisque la présente n’est pas votée..

PhilP

Sylvain Leroux établir le formulaire propre à cette élection, le proposer à @Skyline_ch pour qu'il le mette en place et nous donne le lien correspondant (OK, j'avais pas percuté: vous voulez le Google Form clé en main—je vais apprendre un nouveau truc 😃)

Non l'idée n'est pas que tu fasses le google form, mais que soient listés ce qui doit y figurer. Ce que tu as fait.

J'ai par contre un doute sur l'aspect privé du wallet avec les REG, surtout si ils sont déposés sur un Safe qui sera publique (puisque dans l'outil de calcul du pouvoir de vote), donc les wallets qui déposeront seront connus.
pour la validation du KYC, je pense qu’il faut ajouter: Wallet contenant les RealTokens (en privé).
(Pour avoir deux info, avec le mail, pour prouver qu’on est bien détenteur du compte RealT.co et du KYC associé)

Sylvain Leroux

PhilP pour la validation du KYC, je pense qu’il faut ajouter: Wallet contenant les RealTokens (en privé).
(Pour avoir deux info, avec le mail, pour prouver qu’on est bien détenteur du compte RealT.co et du KYC associé)

Oui, évidemment. C'est une erreur. Je change demain

[X] ajouter: Wallet contenant les RealTokens (en privé)

PhilP J'ai par contre un doute sur l'aspect privé du wallet avec les REG, surtout si ils sont déposés sur un Safe qui sera publique (puisque dans l'outil de calcul du pouvoir de vote), donc les wallets qui déposeront seront connus.

Je me suis posé la question en rédigeant. Il me semble qu'on pourra connaître les wallets des membres, mais pas immédiatement associer un wallet à un membre en particulier. Après c'est un jeu de déduction pas forcément très compliqué ce qui, j'en conviens, n'est pas génial.

En pratique:

Est-ce qu'on a moyen d’anonymiser les dépôts de REG dans un Safe?
Dans la négative, on se résigne à dire que cette information est publique et demander à chaque candidat de prendre les précautions qui lui semblent nécessaires.
🤔

Sylvain Leroux

PhilP si ils sont déposés sur un Safe qui sera publique

Je me pose aussi la question: dans un Safe 3/10—n'y a-t-il pas un risque de voir 3 membres s'accorder pour "partir avec la caisse"?

Sylvain Leroux

PhilP pour la validation du KYC, je pense qu’il faut ajouter: Wallet contenant les RealTokens (en privé)

Au passage, cela réserve implicitement l'accès au Comité de Sécurité aux seuls clients de RealT. Ou est-ce que je me trompe?

Le cas échéant ce n'est peut-être pas dramatique pour ce premier round, mais il faudrait réfléchir à ça pour de futures élections.

PhilP

Sylvain Leroux Est-ce qu'on a moyen d’anonymiser les dépôts de REG dans un Safe?

Je pense que oui, mais ca va pas être simple :

il faudrait que RealT (tiers de confiance, en V1 de la Gouvernance) soit le seul à connaitre pour chaque membre la correspondance entre son wallet publique dédié au comité et son wallet privé de dépôt des REG dans le Safe (ce qui est le cas avec le formulaire proposé).
ainsi, Realt pourra créer le Safe avec les wallets privés de dépôt, transmettre l'adresse du Safe aux candidats et valider les dépôts (tout ou partie pouvant au début être dans le Vault incentive, puis transféré sur le Safe),
A la fin du mandat, le comité déterminera la performance de chaque wallet publique (80 à 130 %, suivant les résultats aux alertes de formation) . A partir de ces performances, RealT pourra calculer le nombre de REG qui doivent être restitués à chaque wallet privé, collecter auprès de la DAO ce qui manque sur le Safe, puis initialiser la restitution des REG du safe vers chaque wallet privé. Restitution qui nécessitera la signature de x membres sur les 10.

Coté modification de l'outils de calcul du pouvoir de vote, cf échange sur Telegram https://t.me/realtokendao_official/3/8513. :
La liste des quantités déposés par chaque wallet privé, pourra être publique (si elle doit être accédée par le Modifier), on ne pourra pas pour autant avoir la correspondance entre wallet publique et wallet privé.

Ainsi la confidentialité me semble préservée (y compris entre chaque membre) : A voir avec @Michael-RealT , si une telle approche lui parait correct et viable...

Benoist-Not-for-sale

Sylvain Leroux

Est-ce qu'on a moyen d’anonymiser les dépôts de REG dans un Safe?

Les transactions sont publiques les dépôts sont forcément visibles
Une façon de couper le lien est d'avoir au moins 2 wallets, un avec les RealTokens, l'autre réservé pour les REG concernant le dépôt pour le comité de sécurité, sans transaction entre les deux

Je me pose aussi la question: dans un Safe 3/10—n'y a-t-il pas un risque de voir 3 membres s'accorder pour "partir avec la caisse"?

Sylvain Leroux
Les membres étant validés par RealT leur identité est connue

Sylvain Leroux Au passage, cela réserve implicitement l'accès au Comité de Sécurité aux seuls clients de RealT. Ou est-ce que je me trompe?

je ne vois pas (pour l'instant) quelle serait la légitimité d'un postulant qui n'aurait pas investi* dans RealT.
* voir même investi "un minimum" (à définir)
Mais oui à l'avenir il faudra y réfléchir

PhilP

Sylvain Leroux
Rien n'empêche de monter le seuil de 3 à 5 par ex.
Mais à l'inverse, si on arrive pas à avoir 5 signataires, à la fin des mandats, les fonds dans le safe seraient bloqués...
Par sécurité, il serait bien que RealT soit aussi signataire du Safe, en plus des 10 membres.

PhilP

Michael-RealT

Que penses tu de cette solution, en attendant: PhilP ?

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.

Sylvain Leroux

Merci pour vos retours. Je réponds à tout le monde en bloc:

Organisation des élections

PhilP L'enchainement des étapes me parait optimisable, pour raccourcir les délais en regroupant l'étape 2 et 4.

Ça, c'est jouable. C'est un peu ce que j'avais fait dans la version précédente je crois. Je ne sais plus pourquoi j'avais renoncé à effectuer ces deux étapes de manière concurrente. 🤔

[X] Optimiser les délais

Safe Recovery

PhilP Par sécurité, il serait bien que RealT soit aussi signataire du Safe, en plus des 10 membres.

Est-ce que tu parles d'un recoverer au sens indiqué dans la doc sur safe.global?

Confidentialité

Benoist-Not-for-sale Les transactions sont publiques les dépôts sont forcément visibles

Michael-RealT La question des dépôt en REG et la confidentialité des identités, est un sujet a prendre clairement en main.
du moment qu'il y as une liste de nom connu (nom, pseudo...) cela peux poser problème si ils sont les seuls a faire un dépôt sur une adresse, ont peux identifier que les déposants (adresse) sont les adresses des personnes qui ont postulé.

Benoist-Not-for-sale Une façon de couper le lien est d'avoir au moins 2 wallets, un avec les RealTokens, l'autre réservé pour les REG concernant le dépôt pour le comité de sécurité, sans transaction entre les deux

Je suis d'accord. Si je comprends bien l'architecture, de toute manière l'adresse du Safe sera publique (ou en tous cas pas très difficile à trouver). De là, tant qu'il s'agit de transactions on-chain, on peut remonter à l'origine des dépôts de REGs et en déduire à qui appartient quel compte.

@Michael-RealT: Concrètement, d'après ton expertise:

Est-ce que l'approche proposée plus haut par PhilP te semble viable et suffisante?
Est-ce que c'est un probéme qu'il faut résoudre ici et maintenant ou est-ce qu'on peut progresser sur le sujet des élections sans que ce point soit totalement clarifié?

@Benoist-Not-for-sale: tes deux autres remarques me semblent raisonnables.

PhilP

L'enchainement des étapes me parait optimisable, pour raccourcir les délais en regroupant l'étape 2 et 4.
Via par ex., l'enchainement suivant :
Durant les 2 semaines de candidature, le candidat fait trois choses :

il crée une suggestion sur le Forum (en libre accès) pour faire acte de candidature, donner toutes les informations publiques et répondre aux questions des membres de la DAO.
Les informations : "Motivation et vision de la candidature au rôle de proposant" et "Conflits d'intérêts" étant notament complétées dans la suggestion plutôt que dans le formulaire.
il complète le formulaire (privé) à destination de RealT.
il envoie ses REG sur le Safe (dont RealT lui donnera l'adresse). Si ils sont sur le Vault Incentive, il s'engage à faire ce transfert à l'issu de l'epoch 2.

A l'issue des 2 semaines de candidature, la vérification de l'éligibilité sera d'une semaine maximum. Durant laquelle, RealT confirmera sur la suggestion de chaque candidat qu'il satisfait ou pas aux critères d'éligibilité.

Après ces trois semaines, un Proposer :

passe les Suggestions de candidature retenue en Candidature et celle non retenue en Suggestion non retenue,
crée les Proposals de vote pour chaque candidat retenu, sur Tally.
dans un délai maximum d'une semaine.

Ainsi, on devrait pouvoir gagner au moins 2 semaines..

PhilP

Sylvain Leroux Question:
Clarifier des options 1), 2) et 3) ci-dessus lesquels sont retenues.

J'avais proposé l'approche suivante à ce sujet : PhilP ?

Sylvain Leroux

PhilP il crée une suggestion sur le Forum (en libre accès) pour faire acte de candidature, donner toutes les informations publiques et répondre aux questions des membres de la DAO.
Les informations : "Motivation et vision de la candidature au rôle de proposant" et "Conflits d'intérêts" étant notament complétées dans la suggestion plutôt que dans le formulaire.
il complète le formulaire (privé) à destination de RealT.
il envoie ses REG sur le Safe (dont RealT lui donnera l'adresse). Si ils sont sur le Vault Incentive, il s'engage à faire ce transfert à l'issu de l'epoch 2.

A l'issue des 2 semaines de candidature, la vérification de l'éligibilité sera d'une semaine maximum. Durant laquelle, RealT confirmera sur la suggestion de chaque candidat qu'il satisfait ou pas aux critères d'éligibilité.

Après ces trois semaines, un Proposer :
passe les Suggestions de candidature retenue en Candidature et celle non retenue en Suggestion non retenue,
crée les Proposals de vote pour chaque candidat retenu, sur Tally.
dans un délai maximum d'une semaine.

Salut @PhilP , ou j'ai effectivement perdu de vue l’enchaînement que tu proposais.

Si je puis résumer:

sem 1-2: le candidat crée une suggestion sur le Forum + formulaire + dépôt REG
sem 3: RealT verifie et confirme l'éligibilité ~~(à qui? Comment?~~
sem 4: Un Proposer déplace les sujets des candidats vers "Candidature" ou "Suggestion non retenue". Le Proposer crée aussi le vote sur Tally
sem 5: Vote on-chain

Est-ce que c'est bien ça?

[X] Reprendre séquence proposée par Phil

Michael-RealT

La question des dépôt en REG et la confidentialité des identités, est un sujet a prendre clairement en main.
du moment qu'il y as une liste de nom connu (nom, pseudo...) cela peux poser problème si ils sont les seuls a faire un dépôt sur une adresse, ont peux identifier que les déposants (adresse) sont les adresses des personnes qui ont postulé.

avec plusieurs sessions ont peux commencé a croisé les données pour en identifier des propriétaires.

a l'heure actuel il n'y as pas de solution simple pour protégé ses personnes, bine que pour dans quelques mois, voir 1-2ans il y aura des solutions efficace dans l'écosystème avec notamment les NFT mais également des couches de confidentialité directement onChain

Michael-RealT

PhilP
la blockchain est public donc celui qui cherche un peux pourrais trouvé le safe de dépôt, lister les Wallet et donc avoir 10 Wallet et 10 nom, cela ne dis pas quelle Wallet appartient a qui mais tu sais déjà que tu as dis nom possible par Wallet.
Répète cela quelque fois avec un ou plusieurs des participants qui sont les meme et tu arrive a mettre un nom sur chaque Wallet.

PhilP

Michael-RealT
La liste des 10 noms/pseudo et 10 Wallets ne changeant que tous les 6 mois, il va falloir plusieurs années pour faire assez de recoupements...
J’imagine que d’ici là on sera passé en v2 de la gouvernance avec des NFT, et donc plus de Pb..

La démarche que je proposais, ne préservant pas la confidentialité à 100% et vous demandant du travail: dis nous ce que tu préfères…

Il y aura aussi la modification de l’outil de calcul du pouvoir de vote : penses tu pouvoir le faire avant la fin de l’élection (qu’on va essayer de rentrer dans l’epoch2, cad avant le 26 avril ) ?

Michael-RealT

Le calcule n'est pas un problème si il faut modifier c'est l'histoire de 1-2h.

si il es décider que c'est acceptable d'avoir une liste d'un groupe de x pseudo relier a un groupe de x adresse alors le safe c'est la bonne solution.

pour le pouvoir de vote soit ont modifie le calcule avec un modifier pour ne pas faire perdre du pouvoir soit ont se dis que c'est le safe d’urgence qui vote, ça peux être la bonne approche si il y as d'autre période d'incitation, le safe peux déposer les REG dans le vault d'incitation, voter pour avoir du bonus qui au terme est redistribuer équitablement, dans ce cas alors pas besoin de modifier le calculateur, les adresses privé perdent un peux de pouvoir de vote, mais cela peux être soit contrebalancer par un vote pour ou contre ou alors si il y as pas d'accord dans le groupe un vote d’abstention .
avec cette approche pas de pénalité sur les incitations.

PhilP

Michael-RealT

Merci pour ce complément.
Si il existe plusieurs solutions, laissons aux membres du comité le soin de choisir une fois qu'ils seront élus.

@Sylvain Leroux je te laisse faire les maj correspondantes. Je passerai demain (vs délai mini d'une semaine) la Suggestion en Proposal. Si tu pouvais ajouter le sondage "What is your feeling" habituel pour les Proposals. Si tout est OK, on devrait pouvoir déclencher les ouvertures de candidatures en fin de semaine.

Sylvain Leroux

PhilP je te laisse faire les maj correspondantes.

Bien sûr, pas de pbm.
Dsl pour le délai: ici, on fonctionne en mode dégradé (3G/3G+) depuis 8 jours du coup j'ai du retard sur pas mal de dossiers.

Je fais passer ça en priorité cet après-midi.

[X] Sondage