---
# System prepended metadata

title: Collective
tags: [Collective, Functional Note, DAO]

---

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


