Traduction française de l’article de J. Kelsey, publié dans FreeDAO.
*Article source : *Medium

Note terminologique : dans cette traduction, guardian est rendu par gardien : il s’agit d’un membre auquel les règles de la DAO confient certains pouvoirs de gouvernance. Les noms d’écrans, de contrats, de comptes et de boutons sont conservés en anglais lorsqu’ils correspondent à l’interface.

Suivez une communauté fictive, Freeos Grants, alors que ses membres choisissent un gardien, financent une idée et demandent des comptes à leur représentant.

Le tirage au sort fractal aide les communautés de DAO à choisir une direction compétente et responsable.

Imaginez que votre communauté dispose d’un pot de financement commun. Il y a de nombreuses choses utiles qu’il pourrait soutenir : de meilleurs supports pédagogiques, des outils utilisables par tous, ou une aide aux personnes qui débutent. Certaines personnes sont également prêtes à assumer la responsabilité de ces décisions.

Comment les choisissez-vous ? Comment donnez-vous aux membres plus discrets la possibilité de contribuer ? Et que se passe-t-il si une personne choisie pour un rôle cesse de l’exercer ?

Cette visite guidée explore l’implémentation du tirage au sort fractal (Fractal Sortition) dans DAOScape : un processus qui combine constitution aléatoire de groupes, discussion, sélection entre pairs et mandats successifs. Nous suivrons une communauté depuis les premières candidatures jusqu’au versement d’une subvention et au remplacement d’un gardien. Il n’est pas nécessaire de connaître la gouvernance blockchain pour suivre le déroulé.

À propos de cette démonstration : Freeos Grants est une DAO fictive exécutée sur un réseau privé local de développement. Ses douze participants, leurs conversations et leurs choix de vote ont été scénarisés. Les captures d’écran montrent de véritables interactions avec des contrats locaux, à l’aide de jetons FREEOS de test sans valeur monétaire. Aucun fonds Freeos réel n’a été dépensé. Les délais ont été raccourcis afin de pouvoir démontrer l’histoire complète. Les scènes actualisées rejouent la même sélection fictive en utilisant les tirages de test enregistrés.

Qu’est-ce qu’une DAO, et quelle est la place de DAOScape ?

Une DAO est une organisation autonome décentralisée. Pensez-y comme à un groupe doté d’un objectif commun, de règles de prise de décision et, souvent, d’une trésorerie partagée.

Certaines de ses règles sont appliquées par des contrats intelligents (smart contracts) : des programmes qui s’exécutent sur une blockchain. Une blockchain est un registre partagé de transactions. Dans cet exemple, les contrats assurent le suivi des adhésions, comptent les votes et vérifient qu’un paiement a été approuvé avant d’en autoriser l’exécution.

« Autonome » ne signifie pas qu’un logiciel décide quelles idées méritent d’être soutenues. Les personnes portent toujours ces jugements. Le logiciel applique les règles qui encadrent leurs décisions.

DAOScape est l’interface que les personnes utilisent pour participer. Elle propose des pages permettant de lire des informations sur une DAO, de consulter ses fonds, de soumettre des propositions et de voter. Lorsqu’un élément est enregistré on-chain, cela signifie qu’il est conservé dans le registre de la blockchain plutôt que d’exister uniquement sous forme de texte sur une page web.

Un gardien est un membre auquel les règles de la DAO confient des pouvoirs de gouvernance. Ce titre ne signifie pas que cette personne possède la trésorerie ou qu’elle peut agir comme bon lui semble. Les pouvoirs précis, leurs limites et les exigences d’approbation sont déterminants.

Que signifie « tirage au sort fractal » ?

Le tirage au sort désigne une sélection aléatoire. Dans la version démontrée ici, le hasard intervient à deux moments : pour répartir les candidats dans de petits groupes, puis pour ordonner une liste restreinte de personnes sélectionnées par leurs pairs.

Entre ces deux tirages, les personnes échangent et font des choix. Chaque groupe discute de ce que ses membres pourraient apporter au rôle, puis vote pour désigner un candidat.

La partie fractale renvoie à la répétition de ce schéma de petits groupes lorsqu’il y a davantage de candidats : les candidats désignés peuvent entrer dans un nouveau tour de groupes et de sélection entre pairs jusqu’à ce qu’il ne reste qu’une petite liste finale. Notre exemple à neuf candidats ne nécessite qu’un tour. Des groupes plus importants auraient besoin de plusieurs tours pour parvenir à la liste restreinte.

Le flux est le suivant :

Candidater → rejoindre un groupe attribué aléatoirement → discuter → désigner un pair → tirer l’ordre de la liste restreinte → exercer à tour de rôle la fonction de gardien.

L’objectif est de laisser une place au jugement formé par la discussion tout en utilisant le hasard pour varier les personnes qui se rencontrent et l’ordre dans lequel elles exercent leur mandat. La répartition aléatoire ne peut pas garantir de bonnes décisions ; la qualité de la participation reste essentielle.

Présentation de Freeos Grants

Notre DAO fictive commence avec douze membres et 50 000 FREEOS de test. Elle souhaite financer des travaux utiles à la communauté, notamment des ressources pédagogiques accessibles et des outils open source : des logiciels dont le code peut être inspecté et réutilisé par d’autres.

Elle compte déjà deux gardiens, Rowan et Alex. Nous conservons ces sièges et ajoutons un siège de gardien tournant grâce au tirage au sort fractal.

Cette visite présente donc une organisation mixte, plutôt qu’un conseil dont tous les sièges seraient choisis par le nouveau processus — bien que le tirage au sort fractal puisse être utilisé pour l’ensemble des sièges de gouvernance.

La page d’accueil de la DAO s’appelle Group Info. Son nom de compte blockchain est grantsdao ; Freeos Grants est le nom utilisé pour désigner la communauté dans cette histoire.

Le menu de gauche sert de carte de navigation.

Dans ce récit, nous passons l’essentiel de notre temps dans Sortition, Member Governance et Treasury. Vous pouvez laisser de côté les pages de configuration plus techniques pendant que vous apprenez le déroulé.

Le nom du compte affiché en haut à droite indique qui est connecté. Sur un réseau actif, un portefeuille (wallet) confirme les actions au nom de ce compte.

Les captures d’écran affichent LOCAL, car ces comptes appartiennent à notre DAO hébergée localement, utilisée uniquement à des fins de démonstration et de test.

1. Les membres se portent candidats

Un membre ouvre une période de candidature depuis la page Sortition. Les candidats soumettent une courte déclaration expliquant ce qu’ils apporteraient au rôle de gardien.

Maya, dont le compte est mayabuilds, souhaite financer de petits éléments logiciels soigneusement évalués.

Parmi les autres : Leo est sceptique sur les dépenses ; Iza défend l’accessibilité ; Nia organise les activités de la communauté. D’autres candidats apportent une expérience de l’enseignement, de la maintenance, de la communication et de l’évaluation des résultats.

Un candidat présente son dossier par écrit. Le formulaire impose une limite de texte, afin que les candidatures restent faciles à lire.

Neuf personnes candidatent. Les règles exigent au moins six candidats admissibles, mais atteindre ce seuil ne clôture pas les candidatures de manière anticipée. Tout le monde peut se présenter jusqu’à la date limite annoncée. S’il reste trop peu de candidats admissibles à la clôture, ce cycle se termine sans désigner de gardien.

Ces personnes se proposent pour exercer la fonction. Leur présence dans le vivier ne signifie pas qu’elles ont déjà été sélectionnées.

En haut de la page, Your participation explique si le compte connecté est admissible. KYC off signifie que l’exigence de vérification d’identité est désactivée dans cette démonstration afin de faciliter les tests.

KYC signifie « Know Your Customer » (« connaissance du client ») ; ici, cela désigne les contrôles d’identité XPR pris en charge.

L’adhésion reste toutefois importante. Un visiteur n’obtient pas de vote simplement en ouvrant la page. Cet exemple attribue une voix à chaque compte membre admissible, sans poids de vote supplémentaire pour la détention d’un plus grand nombre de jetons.

2. Les candidats se rencontrent dans de plus petits groupes

Après la clôture des candidatures, la liste des candidats est figée et le système demande un tirage aléatoire. Les neuf candidats sont répartis en trois groupes de trois.

Les candidats retrouvent leur compte dans l’une des cartes de groupe. C’est dans ce groupe qu’ils peuvent publier et voter.

Un écran indiquant Awaiting randomness (« en attente d’aléa ») signifie que le tirage n’a pas encore été livré. Dans cette démonstration locale, un service de test le fournit. La conception de production utilise le service d’aléa de XPR. Un délai correspond à un état d’attente ; il ne justifie pas qu’une personne choisisse les groupes manuellement.

La discussion fonctionne comme un forum. Les participants n’ont pas besoin d’assister à une réunion en direct ni d’être connectés en même temps. Ils peuvent lire les messages antérieurs et revenir répondre avant la date limite de discussion.

Seuls les candidats affectés à un groupe peuvent y publier et voter pour désigner leur candidat. Les autres personnes peuvent lire la discussion.

Dans le groupe de Maya, Leo et Iza, des priorités différentes mènent à une question pragmatique : comment la DAO peut-elle financer quelque chose d’utile sans prendre un engagement important avant d’avoir des preuves ?

Maya apporte le point de vue d’une bâtisseuse, Leo remet le budget en question, et Iza se concentre sur le caractère réellement accessible et utile du résultat pour les personnes auxquelles il est destiné.

3. Chaque groupe désigne un candidat

La discussion et le vote sont deux étapes distinctes. Écrire « Je soutiens Maya » dans un message ne compte pas comme un bulletin.

Lorsque la période de vote s’ouvre, chaque candidat peut voter pour une autre personne de son groupe. Le vote pour soi-même n’est pas autorisé. Un candidat désigné doit recueillir le soutien de plus de la moitié du groupe ; dans un groupe de trois, il faut donc deux votes pour la même personne.

Le panneau Public peer ballots permet aux lecteurs d’examiner les choix. Ces votes entre pairs sont publics et ne sont pas des bulletins secrets.

Les trois groupes s’accordent sur un candidat désigné dans cette exécution : Maya, Nia et Eva. Si un groupe ne parvient pas à une majorité, les règles autorisent une période de vote supplémentaire. Un groupe qui demeure sans majorité ne produit aucun candidat désigné. Il faut au moins deux candidats désignés pour constituer une liste restreinte.

Les candidats désignés ont obtenu le soutien de leurs pairs. Le tirage suivant décide de l’ordre dans lequel ils exerceront la fonction.

4. Une liste restreinte donne aux personnes une chance d’exercer

Maya, Nia et Eva forment notre premier vivier d’attente. Il n’y a pas de « prochain sur la liste ». Lorsqu’un siège doit être pourvu, le contrat enregistre les candidats admissibles et demande un nouveau tirage aléatoire. Dans cette démonstration, ce premier tirage sélectionne Maya.

Le panneau ****Elected guardian**** affiche la personne actuellement titulaire du rôle et l’échéance de son mandat. ****Shortlisted candidate pool**** affiche les personnes disponibles pour un futur tirage. Les noms sont présentés par ordre alphabétique pour faciliter la lecture ; leur position à l’écran ne constitue pas un classement.

Nia et Eva restent disponibles. Aucune ne sait si elle sera sélectionnée ensuite. Un candidat en attente ne possède qu’une entrée ; participer à davantage de tours de sélection ne permet donc pas d’acheter des chances supplémentaires. Dès qu’une personne est nommée, son entrée est supprimée ; une nouvelle possibilité exige d’achever un nouveau processus de sélection.

La même règle s’applique après une révocation : retirer Maya de sa fonction n’installera pas automatiquement Nia ou Eva. C’est important lorsque les membres envisagent une pétition de révocation. Ils doivent évaluer la conduite du gardien, plutôt que de considérer la pétition comme un moyen de donner le siège à un successeur connu. La sélection aléatoire rend ce successeur incertain ; elle ne rend pas un jugement honnête inutile.

Le vivier doit être renouvelé au fur et à mesure que les personnes exercent leur mandat. Dans cet exemple, sa capacité est de trois candidats en attente : par défaut, elle représente 10 % du nombre de membres enregistrés, arrondi à l’entier supérieur, avec une capacité minimale de trois pour les petites DAO. Le gardien en fonction n’est pas compté. Pour une DAO de 100 membres, la règle par défaut autoriserait dix candidats en attente.

Après la nomination de Maya, il ne reste que deux personnes. L’interface affiche un rappel :

Vous pouvez ignorer la suggestion en cliquant sur ****Later****. Une notification reste présente sur la page. Le rappel n’ouvre pas un tour de sélection et ne signe pas une transaction à votre place.

Devon ouvre un autre tour de candidatures tandis que Maya poursuit son travail. Six membres qui n’avaient pas été retenus dans le premier tour candidatent à nouveau. Leur participation antérieure ne leur donne pas une admission automatique : ils doivent de nouveau discuter et sélectionner leurs pairs.

Le recrutement et le travail du gardien peuvent se dérouler en parallèle. Le sélecteur ****Cycle**** distingue les candidatures, discussions et enregistrements de vote de chaque tour.

Le module prend également en charge des tours de sélection qui se chevauchent, jusqu’à quatre par défaut. Un compte ne peut candidater que dans un tour actif à la fois. Les candidats déjà en attente et un gardien dont le mandat est toujours actif ne peuvent pas candidater à nouveau. Chaque tour exige toujours au moins six candidats admissibles ; ouvrir plusieurs tours ne supprime pas cette exigence.

Lorsqu’un tour s’achève, ses candidats désignés peuvent remplir les places disponibles du vivier. S’il y a plus de candidats admissibles que de places, un tirage de l’oracle sélectionne les personnes admises. Le contrat vérifie la capacité à l’issue de chaque tour. Achever la sélection entre pairs ne garantit donc pas l’admission immédiate dans un vivier plein, et l’admission ne garantit toujours pas une nomination.

Certaines étapes nécessitent une transaction Advance phase une fois leur échéance atteinte. La nomination d’un gardien utilise le contrôle distinct Request guardian draw. La personne qui soumet l’une ou l’autre de ces transactions ne peut pas en désigner le résultat. Lorsqu’une requête d’oracle est en attente, l’interface l’indique ; elle ne la remplace pas par un résultat choisi localement.

5. Les gardiens décident de ce qui sera financé

Maya occupant le nouveau siège de gardien, la recommandation concernant le kit d’apprentissage devient une demande officielle de 1 500 FREEOS. Sam la soumet. Eva soumet également une campagne de sensibilisation de 12 000 FREEOS.

Ce sont deux propositions distinctes. Les gardiens peuvent soutenir l’une sans soutenir l’autre.

Pour ces paiements, nous passons à Proposals. La distinction est importante : les membres peuvent proposer une idée, mais seuls les gardiens approuvent le paiement. Ici, les trois gardiens sont Rowan, Alex et Maya. Être candidat, candidat désigné en attente ou auteur d’une proposition ne donne pas le droit de vote des gardiens.

Avant cette partie de l’histoire, Rowan et Alex ont approuvé l’activation de member proposal submissions dans Configuration. Ce réglage est initialement désactivé ; les gardiens peuvent l’activer ou le désactiver via leur propre processus de proposition. Le désactiver empêche les nouvelles soumissions de membres sans annuler les propositions déjà soumises.

Les membres ont également approuvé le jeton FREEOS de démonstration comme actif que les gardiens peuvent dépenser. Il s’agit d’une décision de politique constitutionnelle prise dans Member Governance, qui identifie le contrat de jeton exact et son symbole. Elle est distincte de l’approbation d’un paiement particulier. La trésorerie peut déjà recevoir et détenir des jetons ; le fait de les détenir n’autorise pas, à lui seul, leur dépense.

Les membres consignent leurs demandes. Le compteur d’approbations des gardiens commence à zéro pour une soumission de membre.

« Transfert exact » signifie que l’approbation est liée à un paiement déterminé, notamment à son montant et à son destinataire. La proposition du kit d’apprentissage autorise 1 500 FREEOS à destination de learnkit, le compte local qui reçoit la subvention. Elle n’autorise pas une série indéterminée de paiements ultérieurs. Ici, une subvention est un transfert de jetons ordinaire, assorti d’un objet déclaré et d’un processus d’approbation.

Une subvention exige l’approbation d’au moins deux des trois gardiens. Il s’agit d’un décompte d’approbations distinctes, données par des gardiens encore valides. Ce n’est ni une règle de participation en pourcentage ni un vote oui/non de l’ensemble des membres.

Maya approuve le kit d’apprentissage car il finance un petit travail utile doté d’un point de contrôle clair. Rowan ajoute la deuxième approbation. Alex soutient l’exploration de la campagne d’Eva, mais Rowan et Maya souhaitent d’abord des éléments probants issus du projet pilote plus modeste. La campagne ne recueille qu’une approbation ; elle ne peut donc pas être payée.

Deux approbations rendent le kit d’apprentissage exécutable. Une seule approbation est insuffisante pour la campagne. Les membres ordinaires ne disposent d’aucun vote sur l’approbation des subventions.

Un gardien peut retirer son approbation avant l’exécution. Le contrat revérifie les approbations lorsqu’une personne tente d’effectuer le paiement : l’approbation d’un gardien dont le mandat a expiré ou qui a été révoqué ne compte plus. Un gardien remplaçant doit prendre sa propre décision. Aucun paiement n’est exécuté automatiquement à l’arrivée d’une échéance et ce processus de proposition ne comporte pas de décompte séparé des votes « non ».

Eva retire la campagne après qu’elle n’a pas obtenu de deuxième approbation. Son enregistrement apparaît dans Cancelled. Cela diffère du rejet d’un scrutin de membres par une majorité de votes négatifs.

Une dernière distinction est utile : suffisamment d’approbations signifie qu’une proposition peut être exécutée ; Executed signifie que l’action autorisée a effectivement eu lieu. Rowan exécute la proposition relative au kit d’apprentissage avant son expiration. Le contrat effectue le transfert indiqué et archive la proposition, afin qu’elle ne puisse pas payer la même proposition une deuxième fois.

La trésorerie passe de 50 000 à 48 500 FREEOS de test. Le compte learnkit reçoit 1 500. La campagne retirée ne reçoit rien.

Le contrat peut vérifier que le transfert approuvé a eu lieu. Il ne peut pas vérifier qu’un kit d’apprentissage est utile. Les membres peuvent examiner le travail, poser des questions et partager leurs conclusions ; les gardiens utilisent ces éléments lorsqu’ils décident d’approuver ou non une autre subvention.

6. Les membres peuvent retirer le mandat d’un gardien

Notre histoire fictive introduit maintenant un problème. Maya ne respecte pas un engagement de communication de rapports et devient indisponible.

Devon, un membre qui ne s’était pas présenté au siège de gardien, ouvre une pétition de révocation (recall petition). La révocation consiste à mettre fin à l’autorité d’une personne dans son rôle avant la fin normale de son mandat.

Une pétition invite la communauté à envisager la révocation. Elle ne retire pas à elle seule le gardien de sa fonction.

La pétition exige le soutien de 10 % de l’électorat admissible, arrondi à l’entier supérieur. Avec douze comptes admissibles, cela signifie deux soutiens. Devon constitue le premier ; le soutien de Leo atteint le seuil et ouvre un scrutin.

Cette décision appartient aux membres, via Member Governance. Ses règles diffèrent de la règle de paiement à deux gardiens :

• Au moins 30 % de l’électorat admissible doit voter, arrondi à l’entier supérieur. Avec douze comptes membres admissibles, au moins quatre doivent participer.

• Les votes « oui » doivent être plus nombreux que les votes « non ». Une égalité ou une participation insuffisante entraîne l’échec.

L’électorat et les règles applicables sont fixés à l’ouverture du processus. Les membres peuvent modifier leur bulletin oui/non avant son échéance. Sept votent oui et un vote non ; cette révocation satisfait donc les deux exigences. Après l’échéance, n’importe qui peut soumettre la transaction de finalisation, qui demande au contrat de vérifier le résultat.

Une fois la révocation réussie finalisée, Maya perd son autorité de gardien élue. Aucun veto supplémentaire des gardiens n’intervient. Cela n’annule pas le transfert déjà effectué pour le kit d’apprentissage ; cela met fin à son pouvoir d’agir en tant que gardien élu.

Le siège doit alors être pourvu. Une nouvelle requête d’oracle fige les candidats admissibles en attente. Ni Devon ni les personnes qui ont voté pour la révocation ne peuvent désigner un successeur dans cette requête.

Dans cette exécution, le tirage sélectionne Eva, et non Nia. Le résultat authentifié la nomme pour le reste du mandat initialement prévu pour Maya.

Eva achève la durée restante du mandat prévu pour Maya. La remplaçante ne reçoit pas un nouveau mandat complet simplement parce qu’une révocation a eu lieu. Si l’oracle arrive après cette échéance, la requête de remplacement manquée est close et un nouveau tirage est nécessaire pour un mandat complet.

Cet épisode, bien qu’entièrement fictif, montre qu’un membre ordinaire peut initier un mécanisme de responsabilité et que choisir un représentant ne doit pas signifier attendre la fin de son mandat pour agir.

7. Les membres peuvent aussi modifier les règles

Member Governance traite également des décisions constitutionnelles : les modifications de la manière dont la DAO est gouvernée, telles que ses délais, sa politique de vérification d’identité ou les actifs de dépense approuvés. Ces décisions utilisent les règles de participation et de vote oui/non des membres décrites dans l’exemple de révocation, plutôt que le seuil de paiement des gardiens.

Pour la démonstration, les délais se sont écoulés très rapidement. Devon propose d’utiliser le réglage normal de durée pour les processus futurs, tout en laissant KYC désactivé. Sept membres votent oui et un vote non. Après l’échéance, le scrutin réussi est finalisé et son action approuvée est exécutée, sans approbation supplémentaire des gardiens.

Les membres approuvent une modification de règle spécifique. Les processus existants conservent les règles et échéances en vigueur lorsqu’ils ont commencé.

Le réglage normal accorde 48 heures aux candidatures, 48 heures à la discussion de groupe, 24 heures à un vote de groupe ou à un second tour, 72 heures au vote des membres et un mandat de gardien de 30 jours. Il s’agit de paramètres propres à cette implémentation, et non d’une définition universelle du tirage au sort fractal.

Pendant ce temps, le tour de sélection supplémentaire s’achève. Ses deux candidats désignés, Iza et Theo, rejoignent Nia dans le vivier d’attente, le ramenant à trois personnes. Eva demeure gardienne ; le réapprovisionnement du vivier ne la retire ni ne la remplace.

Chaque entrée indique le tour dans lequel elle s’est qualifiée. Il s’agit de candidats disponibles, et non des trois prochains titulaires de la fonction.

Les tours de sélection existants conservent leurs règles de démonstration initiales. Lorsque le mandat hérité d’Eva expire, son autorité prend fin, même si la requête d’oracle suivante n’a pas encore été soumise. Nous l’avons vérifié localement : le contrat a refusé une tentative d’approbation d’une proposition avec ce rôle expiré.

Un autre nouveau tirage est demandé depuis le vivier d’attente.

Cette fois, le résultat sélectionne Nia. Sa nomination découle de ce nouveau tirage ; elle n’était pas garantie lorsqu’elle est entrée pour la première fois dans le vivier.

L’entrée de Nia quitte le vivier d’attente. Les autres candidats restent disponibles pour un tirage ultérieur, et le rappel de faible niveau du vivier peut inciter à ouvrir un autre tour de sélection.

S’il ne reste aucun candidat admissible, le siège demeure vacant jusqu’à ce que la sélection produise de nouveaux candidats et qu’un tirage de l’oracle puisse nommer quelqu’un. Les deux gardiens permanents restent en fonction. Si un seul candidat admissible est disponible, il est le seul résultat possible ; le rappel aide la communauté à éviter de dépendre d’un vivier aussi réduit.

Participer ne nécessite pas d’ordinateur de bureau

Les mêmes enregistrements peuvent être consultés sur téléphone. La vue mobile Proposals montre la demande, son action exacte et les approbations des gardiens. Les membres peuvent suivre l’enregistrement ; les contrôles d’approbation sont réservés aux gardiens.

Les membres peuvent suivre les décisions sans être devant un ordinateur de bureau. La discussion asynchrone signifie également qu’ils n’ont pas tous besoin d’être présents au même moment.

Pour une personne qui rejoint une DAO utilisant cette organisation, les premières étapes sont simples : lire Group Info, vérifier son adhésion et son admissibilité, puis visiter Sortition pour voir l’étape en cours. Vous pouvez suivre les discussions sans vous présenter à une fonction. Proposals est l’endroit où suivre les demandes de financement et, si la DAO l’autorise, en soumettre une. Member Governance est l’endroit où les membres admissibles votent sur les modifications constitutionnelles et les révocations.

Ce que montre cet exemple — et la suite

L’histoire de Freeos Grants démontre un processus cohérent : les membres se portent volontaires, discutent dans de petits groupes, sélectionnent leurs pairs, construisent un vivier d’attente et nomment des gardiens par de nouveaux tirages aléatoires. Ces gardiens demeurent redevables devant l’ensemble des membres. Les membres peuvent soumettre des demandes de financement lorsque cette option est activée. Les gardiens approuvent des paiements précis ; les membres conservent le pouvoir de modifier les règles constitutionnelles et de révoquer le gardien élu.

Il s’agit encore d’un projet pilote. Les règles révisées du vivier présentées ici ont été testées localement ; le déploiement actif doit être testé dans une bêta fermée.

L’exemple conserve deux gardiens permanents, et les dispositions du pilote maintiennent des pouvoirs de récupération et de déploiement. Il ne doit pas être interprété comme l’affirmation que le logiciel ou sa gouvernance ne pourront jamais être modifiés par ces autorités. L’exécution locale fictive ne remplace pas non plus l’essai de cycle de vie restant à mener sur le réseau principal (mainnet) ni l’expérience d’installation guidée prévue pour d’autres DAO.

Ce que cet exemple apporte, c’est un point de départ concret pour la discussion au sein des communautés Freeos et DAOscape, ainsi qu’une vision de la manière dont Freeos peut être géré comme un projet entièrement communautaire, avec une direction qui émerge de la communauté. D’autres discussions et articles de blog sur ce sujet viendront ultérieurement.

Quelles décisions les gardiens doivent-ils prendre ? Lesquelles doivent toujours revenir aux membres ? Quels éléments un bénéficiaire de subvention devrait-il fournir ? De combien de temps les personnes devraient-elles disposer pour délibérer ?

Ces choix méritent autant d’attention que le processus de sélection lui-même.

Le tirage au sort fractal offre une façon d’organiser la participation et la responsabilité ; la communauté apporte la finalité, le discernement et le soin qui leur donnent leur valeur.

Le projet Freeos a toujours envisagé de devenir un projet entièrement géré par la communauté, intégralement organisé sous la forme d’une DAO. DAOScape a été créé pour héberger ce projet ; comme toutes les DAO qu’il lance, il est pleinement capable de contrôler les contrats, y compris de les mettre à jour par un vote de DAO.

L’ajout du tirage au sort fractal permet à la communauté d’assumer des rôles de plus en plus importants dans le projet et à Freeos de devenir une économie et une monnaie auto-souveraines, gérées par les personnes et responsables devant elles.

Nous encourageons la communauté à participer aux discussions, à partager le concept et à contribuer à son développement afin de faire évoluer notre modèle coopératif de monnaie communautaire dans notre canal Telegram.