Создание токена и развертывание для вашей продуктовой команды

Дайте токену задачу до написания его контракта

Представьте разработчика, который пишет документацию, но не посты, наутро после анонса листинга. Им нужно объяснить, какой адрес токена относится к продукту. Мы бы сначала проверили сеть, согласованное поведение и записи, необходимые их команде.

Создание токена и развертывание начинается с этой практической цели. Контракт должен отражать то, что пользователям нужно делать, и то, что ваша команда готова управлять. Мы превращаем эти решения в согласованную спецификацию до написания реализации.

Это означает обсуждение выбранного стандарта, имени и символа токена, поведения эмиссии, разрешений и предполагаемых интеграций. Токен для переводов и токен с дополнительными действиями требуют разных решений. Мы записываем решения, чтобы ваши технические и продуктовые рецензенты могли подтвердить один и тот же план.

Если поведение токена требует большего, чем стандартный контракт токена, мы можем обсудить это вместе с разработкой смарт-контрактов. Для более широкого обзора связанной работы над продуктом см. Web3-разработку. Полезная отправная точка — не список функций. Это четкое описание того, что токен должен позволять человеку делать, и кто в вашей команде утверждает такое поведение.

Какой стандарт токена подходит для вашего плана продукта?

Правильный стандарт — тот, который подходит для вашей выбранной сети и продукта. ERC-20, BEP-20, SPL и Jetton относятся к разным техническим средам, поэтому решение влияет на реализацию и интеграционные работы.

Начните с людей и продукта

Запишите, где пользователи столкнутся с токеном и что им нужно с ним делать. Отметьте, какие кошельки или компоненты продукта должны его распознавать. Если сеть определена, мы можем работать исходя из этого выбора и выявить оставшиеся вопросы. Если она еще открыта, мы можем сравнить потребности в разработке и интеграции с вашим планом продукта.

Сделайте разрешения понятными

Перечислите действия, которые контракт должен поддерживать, затем назовите роль в команде, ответственную за каждое разрешение. Подтвердите любые ожидаемые проектом эмиссию, майнтинг или сжигание. Это решения для людей, отвечающих за продукт, а не детали, которые следует оставлять неявными в ревью кода.

Допустим, ваша команда выбрала сеть, но все еще формирует поток своего приложения. Мы можем сопоставить требования к токену с этим потоком, затем определить, что требует отдельного продуктового решения. Проект разработки dApp можно спланировать параллельно с работой над токеном, когда пользователям нужен интерфейс для взаимодействия с ним.

Четыре контрольные точки делают сборку понятной

Четкая последовательность дает вашей команде возможности решать вопросы до развертывания. Мы держим работу привязанной к согласованной спецификации, с уполномоченным контактным лицом, участвующим в точках утверждения.

1. Сбор требований. Укажите сеть, стандарт, предполагаемое поведение токена, метаданные и связи с продуктом. Назовите лицо, которое может утверждать технические решения.
2. Написание спецификации. Мы превращаем эти заметки в запись ожидаемого поведения и выявляем открытые варианты. Ваша команда подтверждает план до реализации.
3. Проверка реализации. Мы сверяем контракт с согласованной спецификацией. Ваши рецензенты могут задать вопросы до утверждения деталей релиза.
4. Утверждение и развертывание. Уполномоченное контактное лицо подтверждает информацию о релизе. Мы развертываем в выбранной сети и готовим согласованные материалы для верификации.

Целенаправленный контракт может пройти эти контрольные точки без того, чтобы решения по интеграции продукта задерживали работу. Когда приложение или кошелек являются частью плана, мы включаем их потребности на раннем этапе. Это помогает команде отличать решения по токену от решений по интерфейсу. После развертывания мы предоставляем запись передачи с адресом контракта, информацией о сети, деталями метаданных и статусом верификации.

Что ваша команда может проверить при передаче?

Передача должна позволить вашей команде сопоставить развернутый токен с утвержденным планом. Мы держим запись практичной, чтобы продуктовые и технические коллеги могли найти нужные детали, не полагаясь на память.

Например, продуктовый писатель, готовящий страницу токена, может использовать передачу, чтобы проверить сеть и адрес перед публикацией. Разработчик, подключающий поток кошелька, может обратиться к той же записи при подтверждении того, какой контракт должен использовать интерфейс. Если вашему публичному объяснению все еще нужен дом, мы можем скоординироваться с разработкой Web3-сайта и лендинга.

Верификация в эксплорере сравнивает отправленную информацию о контракте с развернутым контрактом, но каждый эксплорер контролирует свой собственный обзор и отображение. Мы можем подготовить и отправить согласованные материалы, затем записать статус; принятие и отображение метаданных решать не нам.

Перенесите адрес в следующий шаг продукта

Развернутый токен — это одна часть вашего продукта, и следующий шаг — сделать его адрес и поведение согласованными везде, где пользователи с ним встречаются. Ваша команда может использовать передачу, чтобы согласовать экраны продукта, проектные материалы и техническую ответственность.

Проверьте, что сеть и адрес совпадают во всех ваших интерфейсах. Подтвердите, что любые действия, показываемые пользователям, соответствуют утвержденному поведению контракта. Держите объяснение токена рядом с потоком продукта и убедитесь, что один человек может отвечать на вопросы о реализации.

Если следующий шаг — это опыт работы с кошельком, мы можем спланировать подключение с разработкой криптокошелька. Если ваша команда готовит информацию о токене для внешних профилей, листинги и верификация охватывают другую задачу, отличную от создания контракта. Для скоординированной сборки мы можем обсудить, какие части должны быть вместе, а какие следует оставить раздельными.

Отправьте Brand Community вашу предпочтительную сеть, требования к токену, метаданные и краткую заметку о связи с продуктом. Мы рассмотрим уже принятые решения, перечислим любые открытые вопросы и предложим последовательность сдачи работ, которую ваша команда сможет утвердить.

Как мы работаем

1. Укажите детали токенаСообщите нам предпочтительную сеть, стандарт токена, ожидаемое поведение и связи с продуктом. Включите любые метаданные и имя вашего утверждающего.
2. Согласуйте спецификациюМы записываем план реализации и отмечаем решения, которые вашей команде еще нужно принять до разработки.
3. Проверьте контрактМы сверяем реализацию с согласованным поведением. Ваши рецензенты могут задать вопросы перед утверждением деталей релиза.
4. Утвердите и развернитеВаше уполномоченное контактное лицо подтверждает информацию о релизе. Мы развертываем в выбранной сети и готовим согласованные материалы для верификации.
5. Получите передачуМы предоставляем адрес контракта, информацию о сети, детали метаданных и статус верификации для ваших записей.