# Collective ###### tags: `DAO` `Collective` `Functional Note` ## Введение в `Collective` Любое приложение - это протокол, его должен кто-то предложить, кто-то создать и кто-то использовать. Очень редко все эти роли представлены одним пользователем. Дополнительную сложность в понимании проблемы создает широкий спектр инмтрументов, формирующих процесс управления человечискими ресурсами, необходимыми для создания приложения: начиная от генерации идеи, разработки/улучшения, тестирования и заканчивая использованием приложения. Для снижения трений и как следствие минимизации требуемых на создание и развитие приложения ресурсов создан **`Collective`** - сервисный протокол, расширяющий функционал любого приложения необходимыми примитивами, обеспечивающих соблюдение интересов всех сторон производственной цепочки создания и развития приложения. > **Токен** = приложение = протокол = набор функций и хранилище данных с которыми эти функции производят трансформацию. > **NFT** - незаменимый токен, репрезентация уникального ресурса(приложений, людей). > **FT** - заменимый токен, репрезентация не-уникального ресурса(денег). > **NFT** приложения(**`app`**) выступает контейнером реестров обладателей ресурсов, сгенерированных приложением в процессе его жизненного цикла и распределенных между пользователями, в роли которых **может выступать как 👨‍💻 так и 🤖**: * **`app/shares/profit`** - держатели обязательств разделения будущих доходов приложения(бенефициары работы приложения) * **`app/shares/fund`** - держатели долга приложения(спонсоры фонда изменения приложения) * **`app/shares/utility`** - держатели утилитарного токена приложения(валюта в которой он принимает оплату за свои услуги) * **`app/shares/equty`** - держатели управляющего токена приложения, ре-презентует права собственности на приложение > app/coins/fair > app/coins/equty > app/coins/utility > app/coins/markets/fair_market(fair_coin/utility_coin) // **buy/sell** > app/coins/markets/utility_market(utility_coin/stable_coin) // **buy/sell** > app/coins/markets/equty_market(equty_coin/utility_coin) // **sell_only** > app/consensus/poa > app/consensus/pos **NFT** коллектива приложения(**`collective.app`**) выступает контейнером реестров обладателей ресурсов, необходимых для создания/изменения/улучшения/расширения функционала **`app`** во всем диапазоне его жизненного цикла: * **`collective.app/users/exec`** - пользователи, обеспечивающие управление коллективом приложения * **`collective.app/users/dev`** - пользователи, обеспечивающие разработку/улучшение/исправление приложения * **`collective.app/users/qa`** - пользователи, обеспечивающие контроль качества разработанных изменений Для создания коллектива любой пользователь создает топик в котором происходит обсуждение условий разделения токенов между заинтересованными пользователями приложения и пользователями коллектива, также в этом состоянии происходит формирование книги заявок на финансирование коллектива через выкуп токенов финансирования затрат(**`app/users/fund`**). При достижении заявленной суммы предложений и экспирации предельного срока сбора заявок на финансирование инициируется фабрика создания ресурса **`collective.app`**: блокирование привлеченных фондов в контракте коллектива, назначение пользователей на роли управляющих менеджеров, инженеров по разработке и тестированию **`collective.app`**. Таким образом пользователи разделены на два домена(пользователи приложения и пользователи коллектива), внутри каждого домена пользователи дополнительно поделены по ролям - это обеспечивает возможность тонкой подстройки протоколов согласованного принятия решения на каждом из этапов жизненного цикла, что положительно влияет на привлекательность такой модели разработки как **`collective.app`**, так и для **`app`**. ## Топик(`topic`) Предложение по *созданию/модификации/улучшению/устранению неисправности* вносят пользователи приложения, если таковое сущевствет, либо инициирует создание топика создания приложения, если функционал таковго не представлен в других приложениях. Предложение создается в виде топика - на подобие ветки форума, в которой происходит обсуждение предложения. Топики могут быть пяти разных видов, определяющих внешний вид топика: ```mermaid graph TD A[Пользователь] -->| Публикует | B[Топик] B -->| улучшение текущего функционала | F[Improve. Предложение по улучшению] B -->| расширение текущего функционала | G[Enhance. Предложение по расширению] B -->| устранение найденной ошибки | K[Bugfix. Предложение по устранению ошибки] B -->| изменение текущего функционала | L[Change. Предложение по изменению] B -->| Не влияет на приложение | E[Info. Информационное предложение] ``` ### Жизненный цикл топика > Домен владения топика переходи то мере его реализации: > (**`user->app->collective->app`** ) ```flow idea=>start: user->init_topic() deploy=>end: app/topic->deploy() idea_chat=>operation: Resource onboarding draft_chat=>operation: Resource onboarding init_collective_chat=>operation: Solution BluePrint dev_chat=>operation: Development qa_chat=>operation: Quality assurance dev=>operation: app/topic->init_collective() idea_cond=>condition: Consensus: PoA app/shares/equty draft_cond=>condition: Consensus: PoS app/shares/fund exec_collective=>condition: Consensus: PoA collective.app/users exec_dev=>condition: collective.app/users/dev exec_qa=>condition: Consensus: PoS collective.app/users/qa exec_dep=>condition: Consensus: PoS app/shares/equty draft=>operation: app/topic->init_collective() init_collective=>operation: collective.app/topic->init() dev_op=>operation: collective.app/topic->init_dev() qa_op=>operation: collective.app/topic->init_qa() dep_op=>operation: collective.app/topic->deploy() pr_op=>operation: collective.app/users->perfomance_review() arch_op=>operation: app/topic->archive() trash_op=>operation: user/topic->trash() refund_op=>operation: collective.app/topic->refund() idea->idea_chat->idea_cond idea_cond(yes)->draft->draft_chat->draft_cond draft_cond(yes)->init_collective->exec_collective(yes)->dev_op->dev_chat->qa_op->exec_qa(yes) exec_qa(yes)->dep_op->pr_op->exec_dep(yes)->deploy idea_cond(no)->trash_op draft_cond(no)->arch_op exec_dep(no)->arch_op exec_collective(no)->refund_op exec_qa(no)->dev_chat ``` ### Привлечение человеческих ресурсов Для предотвращения дефецита человеческих ресурсов имеет смысл продумать систему привлечения участников и уменьшения трения при начале работы в `app/collective`. Интеграция с авторизацией через **Tg** и **Fb** - оптимальное решение, позволяющее использовать эти соц-платформы для маркетинга среди пользователей коллектива. **TBA** ### Ревью комманды коллектива по результатам выполнения топика Для оптимизации использования ресурсов помимо прямой оплаты труда пользователей коллектива приложения могут распределять в бюджет коллектива токены будущего дохода, что должно положительно сказатся на мотивации участников коллектива. Для обеспечения справедливой системы распределения в рамках коллектива и стимулирования конкуренции между коллективами, предлагается использовать модель оценки сотрудников стартапов **[`Perfomace Review`](https://vc.ru/flood/39061-performance-review-v-startape-kak-ocenit-kompetencii-sotrudnika)**, данный процесс имеет смысл реализовать на завершающих этапах релиза **`collective`**. **TBA** ### Привлечение финансовых ресурсов Онбоардинг финансовых ресурсов(инвесторов) - сводится к упрощению процедуры KYC/AML и приему ставки в контракте фандрайзинга. #### Фандрайзинг через контракт с кривой связывания Контракт кривой связывания приложения выпускает токенезированную ценную бумагу FAIR(`FAIR`). Эти токены представляют собой обязательства распределения денежного резерва контратка приложения. Важно отметить, что, в отличие от акций, FAIR не представляет собой претензия на право собственности организации, а только дает финансовое право на денежный резерв, управляемый `Collective.app` . А денежный резерв `Collective.app` зависит от доходов приложения `app`. Таким образом, покупая FAIR, инвестор получает финансовые риски в отношении будущих доходов организации. https://github.com/c-org/whitepaper#dat **TBA** ### Принятие решений через PoS и PoA PoA - Подтверждение полномочий через авторизацию на сторонних ресурсах. Валидаторы назначаются создателем экземпляра контракта, валидаторы должны подтердить свое назначение. Идеальный вариант для онбоардинга фаундеров стартапа до его фандинга и комманды коллектива после привлечения финансирования. nPoS - Подтверждение ставкой. Используется в качестве алгоритма выбора покупателей токена на этапе фандрайзинга. Хороший пример DutchX. https://substrate.dev/docs/en/knowledgebase/advanced/consensus https://docs.ethhub.io/built-on-ethereum/open-finance/prediction-markets/gnosis/ DutchX - это протокол, реализующий голландские действия для совершения сделок с токенами ERC20. Каждые 6 часов для каждого указанного токена запускается новое действие. Цена лота со временем снижается. Трейдеры размещают свои заявки на основе того, что они считают справедливой ценой. Когда цена лота совпадет с заявками, сделка будет рассчитана. Все трейдеры, которые сделали ставку выше или равной цене лота, получат токены в обмен на свой эфир. slow.trade - это пользовательский интерфейс для DutchX. Это удобный способ торговать токенами, не беспокоясь о выборе правильной цены или непосредственном взаимодействии со смарт-контрактом. slow.trade показывает цену последнего закрытого аукциона как оценку текущей рыночной цены. Приложение также отслеживает аукционы, в которых принимает участие пользователь. ### Процесс разработки **TBA** ### Процесс контроля качества **TBA** ## GUI 1. FAQ по модели управления MakerDAO: https://community-development.makerdao.com/makerdao-mcd-faqs/faqs/governance 2. Портал управления MakerDAO: https://vote.makerdao.com/