Qual formato de token é ideal para o seu projeto?
O formato é escolhido com base na rede onde o produto será executado e na compatibilidade com suas carteiras, aplicativos e infraestrutura. ERC-20 é usado para tokens em Ethereum, BEP-20 na BNB Smart Chain, SPL na Solana, e Jetton na TON. Se o produto já está vinculado a uma rede, geralmente faz sentido começar com o padrão dela, em vez de adicionar outros formatos sem uma necessidade específica.
No início, é útil definir a finalidade do token: acesso a funcionalidades, pagamentos dentro do produto, participação na mecânica do protocolo ou outro cenário. Em seguida, são fixadas as propriedades de emissão e governança. Por exemplo, é importante decidir antecipadamente se a emissão será limitada, se são necessários direitos administrativos adicionais e quais ações são permitidas após o deploy. Essas decisões impactam a arquitetura e como o projeto poderá explicar o funcionamento do token aos usuários.
Nós esclarecemos a rede escolhida, os casos de uso e as integrações necessárias antes de estimar o trabalho. Se os requisitos incluírem lógica personalizada além do token básico, é melhor separá-la em uma especificação própria e avaliá-la como desenvolvimento de smart contract. Uma visão geral das áreas está disponível na seção Desenvolvimento Web3.
O que alinhar antes do deploy do ERC-20, SPL ou Jetton?
Antes do deploy, é necessário aprovar os parâmetros do token e a forma de governança: corrigi-los após a publicação pode ser impossível ou exigir uma migração separada. Nós reunimos os requisitos iniciais em uma especificação resumida, para que o proprietário do projeto confirme as decisões principais antes da preparação do contrato ou programa.
A especificação geralmente inclui:
- nome e ticker, além do número de casas decimais, quando aplicável ao formato;
- volume e modelo de emissão: emissão fixa ou criação adicional prevista em regras;
- endereços do proprietário e direitos administrativos, incluindo sua transferência ou renúncia, se previsto no escopo;
- funções e restrições necessárias, como a possibilidade de pausar operações, se forem necessárias e permitidas;
- rede, endereço alvo do deploy, materiais para verificação e informações para metadados.
Para SPL e Jetton, a composição dos parâmetros e a estrutura de implementação diferem dos padrões compatíveis com EVM, por isso não transferimos mecanicamente uma implementação entre redes. Para interagir com a interface do produto, o token pode exigir uma integração separada, que pode ser alinhada junto com o desenvolvimento de dApp. Antes de confirmar a especificação, o cliente verifica endereços, formulações e direitos de governança — assim, reduz-se o risco de descobrir uma decisão errada após o deploy.
Quais materiais estão incluídos na criação do token?
O escopo do trabalho é fixado antes do início: você sabe antecipadamente quais arquivos, ações e configurações receberá. A composição básica inclui a definição dos parâmetros, a implementação no padrão escolhido, o deploy na rede acordada e a entrega do resultado ao projeto.
Dependendo da necessidade, o escopo pode incluir:
- código-fonte e configuração da implementação do token;
- deploy na rede acordada e endereço do token criado;
- verificação do código no explorador, se a rede e o explorador escolhidos suportarem esse processo para o contrato;
- preparação ou atualização de metadados: nome, símbolo, descrição e material gráfico no formato acordado;
- instrução para transferência de direitos administrativos e verificação dos parâmetros principais.
Antes da publicação, verificamos a conformidade da implementação com a especificação aprovada e conferimos os endereços fornecidos pelo cliente. Metadados e design não substituem o registro do projeto em plataformas externas: elas podem ter seus próprios requisitos de submissão e verificação. Se o token fizer parte de um produto, discutimos antecipadamente os pontos de integração e acessos necessários. Para a interface do usuário, pode ser necessário um site ou landing page de projeto Web3, e para um produto no Telegram, um bot ou Mini App. Esses trabalhos são incluídos somente após alinhamento separado.
Como funciona o trabalho no token e quando planejar o lançamento?
O trabalho vai da especificação acordada ao deploy verificável. O cronograma depende da rede, da quantidade de funções, da disponibilidade dos dados e se a tarefa inclui apenas a implementação do token ou também a integração com o produto. Alinhamos a sequência e os pontos de controle antes do início do desenvolvimento.
A ordem típica é:
- Você descreve a finalidade do token, a rede e as funções esperadas.
- Nós esclarecemos os parâmetros, acessos e composição do resultado, e confirmamos a especificação.
- Preparamos a implementação e a disponibilizamos para verificação dentro do processo acordado.
- Após a confirmação, realizamos o deploy na rede escolhida e verificamos o endereço e as propriedades principais.
- Configuramos os metadados previstos, realizamos a verificação quando possível e entregamos os materiais.
Para não atrasar o lançamento, prepare antecipadamente a escrita do nome e ticker, a descrição do projeto, o arquivo gráfico, a rede e os endereços necessários para o deploy. Defina separadamente quem, pelo lado do projeto, confirma as decisões e gerencia a carteira de deploy. Se for necessário conectar uma interface ou outros componentes, indique-os antes da avaliação final: as tarefas relacionadas de desenvolvimento Web3 são planejadas em conjunto, mas seu escopo e prazos são fixados separadamente.
Quais limitações são importantes ao emitir um token?
Antes da emissão, é preciso considerar não apenas o código, mas também a irreversibilidade de algumas ações na rede, os direitos de governança e as regras dos exploradores de terceiros. Na especificação, separamos claramente o que está incluído em nosso trabalho e o que depende da decisão do proprietário do projeto ou de uma plataforma externa.
O endereço de deploy e os parâmetros registrados na rede não podem ser tratados como rascunho: um erro na rede, no endereço ou nas configurações pode exigir um novo deploy e um plano de migração separado. Por isso, o cliente confirma a especificação final e os dados da carteira antes do envio da transação. Se o token tiver direitos administrativos, o proprietário deve garantir a guarda segura das chaves e entender as consequências de cada ação. A transferência ou renúncia de direitos é realizada apenas conforme o cenário acordado.
Somos responsáveis pelo escopo de implementação acordado e pelas ações realizadas, mas não podemos garantir que um explorador de terceiros aceitará a verificação, que uma carteira exibirá o token sem ações adicionais ou que um diretório aprovará os metadados. A decisão desses serviços depende de seus próprios procedimentos, requisitos e condições técnicas. Para verificar a qualidade do trabalho, confira o endereço do token na rede, compare os parâmetros com a especificação aprovada e verifique a disponibilidade dos materiais acordados. Não compartilhe a seed phrase ou a chave privada da carteira com o executor.
Como conectar a emissão do Jetton ao marketing para projetos na TON?
Para marketing de projetos na TON, primeiro é necessário ter informações alinhadas sobre o Jetton e o produto, que possam ser publicadas de forma segura e consistente. O deploy do token por si só não cria posicionamento, cenário de uso do usuário ou plano de comunicação — são tarefas separadas, mas devem ser preparadas em paralelo com a emissão.
Antes de preparar materiais públicos, defina qual o papel do token no projeto, quais funcionalidades já estão operacionais e quais afirmações são respaldadas pelo produto. Confira o nome, símbolo, endereço do Jetton e links para os canais oficiais em todos os pontos de contato. Se o lançamento estiver vinculado a um aplicativo, prepare um caminho curto da descrição do token até a ação do usuário: para onde ir, o que fazer lá e quais limitações devem ser compreendidas antecipadamente.
Para o planejamento, é útil dividir o trabalho em três fluxos: prontidão técnica do Jetton, conteúdo das páginas públicas e comunicação com a comunidade. Nomeie um responsável para cada fluxo e a ordem de atualização dos materiais, para que mudanças de parâmetros não deixem informações desatualizadas nos canais. A parte técnica pode incluir a integração com bot do Telegram ou Mini App, e a interface do produto pode exigir desenvolvimento de dApp separado. O escopo desses trabalhos é alinhado separadamente da emissão do token.
Preços
| Serviço | Preço | Orçamento |
|---|---|---|
| Criação de token | a partir de $450 / projeto |
Preços iniciais em USD. Pacotes personalizados e descontos por volume sob consulta. Pagamento em USDT, USDC, BTC, ETH, SOL, TON ou token do seu projeto.
Como funciona
- Coletamos os requisitosVocê informa a rede, a finalidade do token, as funções necessárias e os materiais disponíveis. Esclarecemos integrações e responsáveis pela aprovação.
- Fixamos a especificaçãoAlinhamos os parâmetros de emissão, direitos de governança e composição do resultado. O deploy não é iniciado antes da confirmação dos dados principais.
- Preparamos a implementaçãoCriamos o contrato ou programa de acordo com o padrão escolhido e verificamos a conformidade com os requisitos acordados.
- Implantamos o tokenRealizamos o deploy na rede escolhida, conferimos endereço e parâmetros, e executamos as ações combinadas com metadados e verificação.
- Entregamos os materiaisFornecemos o endereço do token e os materiais acordados, explicamos o processo de verificação e gerenciamento das funções previstas.
Perguntas frequentes
Quanto custa a criação de um token?
O custo começa a partir de $450 / projeto. A composição final do trabalho depende da rede, dos requisitos de funcionamento, deploy, verificação e metadados. Após esclarecer a tarefa, fixamos a lista de entregáveis e alinhamos o escopo antes do início.
Quanto tempo leva para emitir um token?
O prazo é alinhado após a escolha da rede e a aprovação dos parâmetros. O cronograma é influenciado pela complexidade das funções, disponibilidade dos dados e necessidade de integrações. Antes do início, indicamos as etapas e o que deve estar pronto pelo lado do projeto.
É possível emitir um mesmo token em várias redes?
É possível planejar implementações separadas para várias redes, mas não se trata de um único contrato: cada rede exige sua própria implementação e alinhamento de parâmetros. Primeiro, vale definir por que o projeto precisa de várias versões e como os usuários diferenciarão endereços e cenários.
O que preciso preparar antes de solicitar o serviço?
Prepare o nome e ticker desejados, a finalidade do token, a rede escolhida, os requisitos de emissão e a lista de funções necessárias. Também serão úteis os endereços para deploy, dados para metadados e o contato de quem confirmará a especificação em nome do projeto.
Vocês garantem a verificação no explorer?
Realizamos as ações de verificação acordadas e entregamos os materiais necessários. A aceitação do código pelo explorador não é controlada pelo desenvolvedor: os requisitos específicos e a verificação técnica dependem do próprio serviço. Antes do início, esclareceremos se esse trabalho está incluído e quais informações serão necessárias.
É seguro compartilhar acesso à carteira para o deploy?
Não compartilhe a seed phrase ou a chave privada com o executor. Alinhe um esquema no qual você mantenha o controle da carteira e confirme as transações pessoalmente, ou use uma carteira separada com as permissões necessárias. O procedimento de acesso é fixado antes do deploy.
Conte sobre seu projeto
Responda quatro perguntas rápidas e um gerente enviará um plano, prazos e uma faixa de preço em até uma hora. Tudo fica confidencial.
Carregando formulário…