Пожалуй, и на этот вопрос отвечу дважды. Первый раз – здесь, второй – после того как изучим примеры ДАО. Итак.

Эирдропы: особенно ретроспективные airdrops стали популярны, то есть такие, когда сначала пользуешься функционалом сервиса, а потом, когда он решает модернизироваться в ДАО, получаешь за свои активности токены. Ещё более продвинутый пример – итеративные airdrops.

Баунти: старый добрый пример того, как можно, не имея денег, но имея голову на плечах и трудолюбие внутри, стать участником почти любого ДРС-проекта.

Выкуп на IDO и / или через другие механики тоже возможен, и этот пример, пожалуй, был самым популярным до 2020—2021 гг. Аббревиатур здесь масса: ICO, ITO, TGE, IEO, IDO, INO, IGO, ILAO, DAICO, etc.

Голосующие (передаваемые или нет) токены через некое распределение – тоже подход, хотя и не лучший.

Что ещё? «Вместо этого сосредоточьтесь на создании осведомлённости о том, что отличает сообщество: от того, как был создан и спроектирован продукт, способов участия в сообществе, существующих участников сообщества, людей, стоящих за проектом, его миссии и ценностей, повествований, мемов». В том смысле, что при формировании ДАО важна не форма входа, а содержание. Не вопрос «как?», но вопрос «зачем?»

Роли. И именно в этом подходе роли станут самоочевидны: где соорганизаторы, где – условно-рядовые участники, где – «инвесторы», а где – другие члены комьюнити. Ведь «когда члены сообщества достаточно вовлечены в жизнь сообщества, ваша следующая цель – создать среду, в которой члены сообщества смогут безопасно выразить свой голос… Это может включать в себя: предоставление возможности влиять и участвовать в ключевых обсуждениях, решениях и форумах, имеющих важное значение для сообщества. Главное здесь – убедиться, что члены сообщества чувствуют себя услышанными и имеют возможность оказывать реальное влияние на будущее направление развития сообщества».

Поэтому самый простой подход следующий.

1. Пишем Манифест.

2. Согласен ли участник с ним? Если нет и это первичное формирование, то он вносит правки; если да, сразу идёт далее.

3. Определяем цель и задачи ДАО: тут могут появиться первые смарт-контракты.

4. Далее, исходя из целей и задач, описываем токеномику (иногда говорят о дизайне токена, но это тонкости) продукта, то есть функции / назначение токенов, их количество, распределение и прочие аспекты.

5. После этого пробуем определить механизмы принятия решения: с участием основного токена или без участия такового.

6. Запускаем ДАО.

Это всё неплохо. Но как быть, если задач много? Любой, даже самый простой бизнес требует и постоянного усовершенствования, и усложнения одновременно. Один из способов – разбить всё на подзадачи и создать… Что же?

Эта идея пришла не только мне в голову, когда разрабатывал архитектуру DAO Envelop. Скажем, СубДАО и гильдии отображены у Near Protocol: near.org/guilds, и история подобная сильно пересекается с микроДАО: «