NEP-141 (NEAR)

O que é NEP-141?

NEP-141 é o padrão central de tokens fungíveis para contratos inteligentes na blockchain NEAR.

No universo cripto, um token fungível é aquele em que cada unidade pode ser trocada por outra unidade do mesmo token.

Um token NEP-141 pode representar um ativo estável, token de governança, token de recompensa, token de utilidade, ativo wrapped, moeda de jogo, token de liquidez, ativo cripto semelhante a pontos ou token de staking líquido na NEAR.

O guia oficial do padrão de token fungível da NEAR descreve a NEP-141 como o modelo para contratos de tokens fungíveis na NEAR.

A NEP-141 define a interface comum que um contrato precisa implementar para ser considerado um contrato de token fungível.

Essa interface inclui métodos para consultar a oferta total, consultar saldos de contas, transferir tokens, transferir tokens para um contrato com callback e resolver resultados de chamadas de transferência.

A NEP-141 não é o mesmo que o token nativo NEAR.

O token nativo NEAR faz parte do protocolo básico e é usado para gas, staking, armazenamento e operações da rede.

Os tokens NEP-141 são criados e registrados em contratos inteligentes que mantêm os saldos das contas dos usuários.

Por que a NEP-141 é importante

A NEP-141 é importante porque os tokens fungíveis precisam ter um comportamento previsível em carteiras, aplicativos descentralizados, protocolos DeFi, jogos, ferramentas de análise e contratos inteligentes.

Sem um padrão comum, cada contrato de token poderia usar nomes de métodos, formatos de saldo, regras de transferência e padrões de integração diferentes.

Isso dificultaria a exibição de saldos pelas carteiras e a aceitação de tokens pelos aplicativos.

A NEP-141 oferece a desenvolvedores e usuários uma linguagem comum para saldos e transferências de tokens na NEAR.

Para os usuários, isso significa que aplicativos compatíveis com o padrão podem reconhecer um token NEP-141.

Para os desenvolvedores, significa que um contrato de token pode se integrar a outros contratos usando métodos conhecidos, em vez de depender de uma lógica personalizada para cada token.

Para os projetos, isso facilita o lançamento de tokens, pois eles podem se basear em uma interface já existente.

Para o ecossistema NEAR, o padrão ajuda a melhorar a interoperabilidade entre tokens, carteiras, contratos de staking líquido, produtos DeFi, jogos, sistemas de recompensa e fluxos de pagamento.

O padrão é importante porque a compatibilidade pode ser tão importante quanto a oferta ou a marca do token.

Como a NEP-141 funciona

A NEP-141 funciona por meio de um contrato inteligente que armazena os saldos dos tokens e disponibiliza métodos padronizados.

Quando um usuário possui um token NEP-141, o saldo fica registrado dentro do contrato do token, e não diretamente na conta do usuário.

O contrato funciona como sistema de contabilidade dos saldos, da oferta, das transferências e dos callbacks de receptores.

Uma carteira ou aplicativo pode chamar

para consultar a quantidade de tokens que uma conta possui.

Uma carteira ou aplicativo pode chamar

para consultar a oferta total do token.

Um usuário pode chamar

para enviar tokens a outra conta NEAR.

Um usuário pode chamar

para enviar tokens a um contrato e acionar a lógica desse contrato receptor.

O contrato receptor pode devolver tokens não utilizados pelo fluxo de chamada de transferência.

Esse modelo se adapta ao sistema assíncrono de contratos inteligentes da NEAR, no qual os contratos costumam se comunicar por chamadas entre contratos, em vez de depender de um único fluxo de transação síncrono.

NEP-141 vs. NEAR nativo

Os tokens NEP-141 e o token nativo NEAR são tipos diferentes de ativos.

O token nativo NEAR faz parte do protocolo da rede e é usado para taxas de transação, staking, armazenamento de contas e incentivos econômicos dos validadores.

Um token NEP-141 é emitido por um contrato inteligente e gerenciado pelo registro interno desse contrato.

Os usuários podem manter NEAR nativo e tokens NEP-141 na mesma conta NEAR, mas os sistemas contábeis são diferentes.

Os saldos de NEAR nativo fazem parte do saldo da conta no protocolo.

Os saldos de NEP-141 são registrados pelo contrato do token.

Essa diferença é importante porque o usuário pode precisar de uma pequena quantidade de NEAR nativo para pagar gas ou depósitos de armazenamento, mesmo que queira principalmente movimentar um token NEP-141.

Um usuário que recebe um token NEP-141 também pode precisar registrar o armazenamento no contrato do token antes de mantê-lo.

Entender essa distinção ajuda a evitar transações com falha e confusão sobre saldos ausentes.

NEP-141 vs. NEP-171

A NEP-141 é o padrão de tokens fungíveis, enquanto a NEP-171 é o padrão de tokens não fungíveis na NEAR.

Uma unidade de um token NEP-141 pode ser trocada por outra unidade do mesmo token.

Um NFT NEP-171 é único e geralmente tem seu próprio ID de token, metadados e registro de propriedade.

Por exemplo, um jogo pode usar um token NEP-141 como moeda do jogo e NFTs NEP-171 como itens únicos.

Um aplicativo DeFi pode usar tokens NEP-141 para liquidez ou recompensas.

Um projeto de arte pode usar NFTs NEP-171 para colecionáveis digitais únicos.

A diferença afeta a exibição em carteiras, o comportamento do mercado, os metadados, os preços, o armazenamento e a lógica de transferência.

Os usuários não devem tratar um token NEP-141 como um NFT, pois ele não representa um item único.

Os desenvolvedores devem escolher a NEP-141 quando o ativo precisar de saldos fungíveis e a NEP-171 quando precisar de registros de propriedade exclusivos.

Métodos centrais da NEP-141

A interface central da NEP-141 inclui vários métodos importantes.

O método

retorna a oferta total do token.

O método

retorna o saldo de tokens de uma conta específica.

O método

transfere uma quantidade de tokens de quem fez a chamada para outra conta.

O método

transfere tokens a um contrato receptor e chama a lógica desse contrato.

O método receptor

permite que um contrato receptor aceite tokens e devolva qualquer quantidade não utilizada.

O método

conclui o fluxo da chamada de transferência após a resposta do contrato receptor.

A especificação NEP-141 define esses métodos como a interface central de tokens fungíveis.

Esses métodos são a base para transferências de tokens, pagamentos a contratos, depósitos DeFi, pagamentos em jogos e fluxos de aplicativos baseados em tokens na NEAR.

ft_total_supply

O método

retorna o número total de unidades básicas do token emitidas pelo contrato.

Esse método é somente leitura, o que significa que não altera o estado do contrato.

Os aplicativos podem usá-lo para exibir a oferta total, calcular métricas de mercado, verificar emissões de tokens ou monitorar a criação e a queima de tokens.

O valor retornado geralmente é uma string, pois a quantidade de tokens pode ser muito grande.

Os desenvolvedores devem evitar tratar valores de tokens como números de ponto flutuante comuns, pois erros de precisão podem causar problemas graves de contabilidade.

Os usuários devem entender que a oferta total, por si só, não explica a oferta circulante, os tokens bloqueados, os saldos do tesouro, o vesting ou a demanda real de mercado.

Um token pode ter uma oferta total alta e ainda ser útil se as casas decimais e a demanda fizerem sentido.

Um token pode ter uma oferta total baixa e ainda apresentar riscos se a propriedade estiver concentrada ou a liquidez for fraca.

A oferta total é apenas uma parte da análise de um token.

ft_balance_of

O método

retorna o saldo de tokens de uma determinada conta NEAR.

Esse método é somente leitura e costuma ser usado por carteiras, exploradores, aplicativos DeFi, jogos, dashboards e ferramentas de portfólio.

O saldo é retornado nas unidades básicas menores do token.

A exibição voltada ao usuário depende das casas decimais do token indicadas nos metadados.

Por exemplo, um token com 24 casas decimais pode ser exibido como uma quantidade legível menor do que o valor bruto em unidades básicas sugere.

Os aplicativos devem formatar os saldos usando os metadados do token, em vez de tentar adivinhar as casas decimais.

Os usuários também devem saber que a exibição de uma carteira pode estar atrasada ou em cache.

Se o saldo exibido parecer incorreto, o estado do contrato e o histórico de transações devem ser verificados por meio de ferramentas confiáveis.

A exibição correta do saldo depende tanto do método de saldo da NEP-141 quanto do tratamento preciso dos metadados.

ft_transfer

O método

envia uma quantidade especificada de tokens da conta de quem fez a chamada para uma conta receptora.

Esse é o método básico para transferir tokens NEP-141 entre contas NEAR.

O método pode incluir um campo de memo opcional.

O memo pode explicar a finalidade de uma transferência, como uma referência de pagamento, uma anotação interna ou uma mensagem específica do aplicativo.

A documentação padrão da NEAR informa que

exige que exatamente 1 yoctoNEAR seja anexado à chamada.

Esse pequeno depósito anexado ajuda a confirmar que a transação foi assinada com uma chave de acesso total para ações confidenciais.

Os usuários devem sempre verificar a conta receptora antes de enviar uma transferência.

Em geral, transferências de tokens são difíceis ou impossíveis de reverter quando enviadas à conta errada.

Os projetos devem deixar as telas de transferência claras para que os usuários possam conferir o token, a quantidade, o destinatário, o gas e o memo antes de assinar.

ft_transfer_call

O método

envia tokens a um contrato receptor e chama um método desse contrato no mesmo fluxo de alto nível.

Esse método é uma das partes mais importantes da NEP-141 porque oferece suporte ao uso de tokens entre contratos.

Um usuário pode usar

para depositar tokens em um contrato DeFi, pagar um contrato de serviço, entrar em um contrato de jogo, fazer staking de tokens, transferir tokens por uma bridge ou acionar a lógica de um aplicativo.

O método inclui os campos

, , um opcional e o campo .

O campo

permite que o remetente envie instruções específicas do aplicativo ao contrato receptor.

O contrato receptor deve implementar

para processar os tokens recebidos.

Se o receptor não usar todos os tokens, poderá devolver a quantidade não utilizada para que o remetente receba o reembolso.

Esse modelo reduz a necessidade de transações separadas de aprovação e pagamento em muitos fluxos de aplicativos.

Os usuários só devem usar fluxos de chamada de transferência com contratos em que confiem, pois o contrato receptor determina como os tokens transferidos serão tratados.

ft_on_transfer

O método

é implementado por contratos que desejam receber tokens NEP-141 por meio de .

Esse método recebe a conta do remetente, a quantidade de tokens e a mensagem enviada na chamada de transferência.

Em seguida, o contrato receptor pode decidir o que fazer com os tokens.

Por exemplo, pode creditar um depósito do usuário, comprar um item, registrar um pagamento, emitir um token de recibo, abrir uma posição de staking ou rejeitar a transferência.

O método retorna a quantidade de tokens que não foi utilizada pelo contrato receptor.

Essa quantidade não utilizada pode ser reembolsada pelo fluxo de resolução.

Esse padrão é importante porque permite que contratos recebam tokens fungíveis com segurança e respondam com uma lógica de aplicativo.

Os desenvolvedores devem tratar esse método com cuidado, pois valores de retorno incorretos podem gerar reembolsos errados ou saldos confusos.

Os usuários devem entender que enviar tokens a um contrato é diferente de enviá-los a uma conta comum.

ft_resolve_transfer

O método

conclui o fluxo da chamada de transferência após a resposta do contrato receptor.

Ele é usado como callback para determinar se alguma quantidade não utilizada de tokens deve voltar ao remetente.

Isso é importante porque as chamadas de contratos da NEAR são assíncronas.

O contrato do token não pode presumir que o contrato receptor usou todos os tokens antes de conhecer o resultado do callback.

Se o contrato receptor rejeitar a transferência ou informar que há tokens não utilizados, o contrato do token poderá reembolsar a quantidade correta de acordo com a lógica do padrão.

Esse método ajuda a tornar os fluxos entre tokens e contratos mais seguros e composáveis.

Os desenvolvedores devem testar chamadas de receptores com falha, reembolsos parciais e casos extremos antes de lançar contratos em produção.

Os usuários devem entender que uma chamada de transferência pode ter resultados mais complexos do que uma simples transferência entre carteiras.

Boas interfaces de aplicativos devem mostrar se a chamada de transferência foi bem-sucedida, falhou ou reembolsou tokens não utilizados.

NEP-141 e metadados NEP-148

A NEP-148 é o padrão de metadados usado com tokens fungíveis NEP-141.

O padrão de metadados NEP-148 define o método

e os campos de metadados para tokens fungíveis.

Entre os campos importantes estão

, , , , , e .

O campo

geralmente identifica a versão dos metadados compatível com o contrato.

O campo

fornece o nome legível do token.

O campo

fornece o símbolo curto de exibição do token.

O campo

informa às carteiras e aos aplicativos como formatar para os usuários os saldos brutos em unidades básicas.

Os campos

e podem apontar para metadados externos adicionais e ajudar a evitar adulterações silenciosas.

A NEP-141 fornece a lógica do token, enquanto a NEP-148 ajuda carteiras e aplicativos a exibi-lo corretamente.

Exemplo de metadados NEP-148

Um objeto simples de metadados NEP-148 para um token NEP-141 pode ser assim:

Este exemplo mostra como os metadados do token ajudam os aplicativos a exibir seu nome, símbolo, ícone, arquivo de referência e precisão decimal.

O valor de

é especialmente importante, pois os usuários normalmente esperam ver um saldo legível, e não unidades básicas brutas.

O campo

pode ajudar as carteiras a exibir uma identidade visual para o token.

O campo

pode apontar para informações adicionais sobre o token.

O campo

pode ajudar a confirmar que o arquivo de metadados referenciado não foi alterado inesperadamente.

Os projetos devem manter os metadados precisos, pois dados incorretos podem induzir os usuários ao erro sobre a identidade do token, a exibição da oferta ou a marca.

NEP-141 e gerenciamento de armazenamento NEP-145

A NEP-145 é o padrão de gerenciamento de armazenamento usado normalmente com tokens NEP-141.

O padrão de gerenciamento de armazenamento NEP-145 define métodos para registrar contas e gerenciar depósitos de armazenamento.

O armazenamento é importante porque os contratos da NEAR precisam pagar pelos dados persistentes armazenados on-chain.

Quando um contrato de token armazena o saldo de uma nova conta, ele usa espaço de armazenamento.

Muitos contratos de tokens NEP-141 exigem um depósito de armazenamento antes que uma conta possa manter o token.

O método

pode registrar uma conta e reservar espaço de armazenamento.

O método

pode mostrar se uma conta tem armazenamento registrado.

O método

pode remover o registro de armazenamento de uma conta quando as condições forem atendidas.

Esse modelo ajuda a impedir que os contratos de tokens tenham de pagar custos de armazenamento ilimitados para todos os usuários.

Depósitos de armazenamento para tokens NEP-141

Um depósito de armazenamento é uma pequena quantidade de NEAR nativo anexada para cobrir o armazenamento persistente do contrato.

Para tokens NEP-141, depósitos de armazenamento costumam ser necessários antes que um usuário possa receber ou usar um token.

Isso pode surpreender usuários acostumados a redes em que saldos de tokens aparecem sem uma etapa separada de registro de armazenamento.

O depósito não é o preço de compra do token.

Em geral, ele fica reservado para cobrir o espaço de dados da conta no contrato do token.

Alguns contratos permitem que os usuários recuperem depósitos de armazenamento não utilizados cancelando o registro quando o saldo é zero.

Antes de tentar uma transferência, um depósito ou uma operação DeFi, os usuários devem verificar se estão registrados.

Os aplicativos devem informar os requisitos de armazenamento antes de os usuários assinarem transações.

Informações claras sobre armazenamento podem evitar transferências com falha e confusão entre os usuários.

NEP-141 e eventos NEP-297

A NEP-297 define um formato padronizado para eventos emitidos por contratos da NEAR.

O padrão de eventos NEP-297 oferece suporte a logs estruturados que indexadores e aplicativos podem ler.

A documentação da NEAR informa que os eventos padronizados de tokens fungíveis incluem

, e .

Os eventos ajudam carteiras, exploradores, ferramentas de análise e indexadores a acompanhar a atividade dos tokens.

Por exemplo, um indexador pode ler eventos de transferência de tokens para atualizar saldos e históricos de transações.

Um dashboard DeFi pode ler eventos para acompanhar depósitos, saques ou fluxos de recompensas.

Um projeto pode usar dados de eventos para criar notificações aos usuários ou sistemas contábeis.

Nomes de eventos padronizados facilitam as integrações, pois as ferramentas não precisam analisar dados personalizados para cada contrato de token.

Os eventos melhoram a observabilidade, mas os usuários ainda devem verificar o estado do contrato quando os saldos exatos forem importantes.

Quantidades e casas decimais da NEP-141

As quantidades de tokens NEP-141 costumam ser manipuladas como strings de números inteiros grandes.

Esse modelo evita problemas de precisão de ponto flutuante em contratos inteligentes e aplicativos.

Os metadados

do token informam às interfaces como converter unidades básicas brutas em valores legíveis.

Por exemplo, um token com 24 casas decimais pode exibir um token inteiro como um valor bruto muito grande.

Os desenvolvedores devem armazenar e calcular saldos em unidades básicas.

As carteiras devem exibir saldos usando as casas decimais indicadas nos metadados do token.

Os usuários devem ter cuidado ao ler dados brutos de transações, pois a quantidade bruta pode parecer muito maior do que o saldo exibido.

O tratamento incorreto de casas decimais pode causar transferências e exibições de preço erradas, além de erros contábeis.

A precisão é um dos detalhes técnicos mais importantes para aplicativos de tokens fungíveis.

NEP-141 e DeFi

Os tokens NEP-141 são amplamente usados em aplicativos DeFi na NEAR.

Um contrato DeFi pode aceitar tokens NEP-141 para depósitos, swaps, empréstimos, tomada de empréstimos, recompensas, posições de liquidez, garantias ou atividades de governança.

O método

é especialmente útil para DeFi porque pode transferir tokens e acionar a lógica do contrato em um único fluxo.

Por exemplo, um usuário pode enviar tokens a um contrato de pool e incluir uma mensagem que explique a ação pretendida.

Em seguida, o contrato receptor pode processar o depósito e devolver tokens não utilizados, se necessário.

O uso em DeFi acrescenta riscos além do padrão do token.

Os usuários podem enfrentar riscos de contratos inteligentes, liquidez, volatilidade de preços, liquidação, oráculos e tokenomics.

A compatibilidade com a NEP-141 facilita a integração, mas não garante que uma estratégia DeFi seja segura.

Os usuários devem entender o token e o protocolo antes de depositar fundos.

NEP-141 e staking líquido

Contratos de staking líquido na NEAR podem emitir tokens compatíveis com a NEP-141.

A documentação da NEAR explica que um contrato de staking líquido pode emitir um token NEP-141 que se comporta como outros tokens fungíveis da rede.

Nesse modelo, o usuário deposita NEAR nativo em um contrato de staking e recebe um token líquido que representa sua posição de staking.

Esse token líquido muitas vezes pode ser transferido ou usado em aplicativos DeFi compatíveis.

A taxa de câmbio entre o token líquido e o NEAR em staking subjacente pode mudar ao longo do tempo à medida que as recompensas de staking se acumulam.

Os usuários não devem presumir que um token de staking líquido é igual ao NEAR nativo.

Ele envolve riscos de contrato inteligente, liquidez, preço de mercado e regras de resgate.

Também podem ser exigidos depósitos de armazenamento na primeira interação com o contrato do token de staking líquido.

A NEP-141 torna o token líquido interoperável, mas não elimina os riscos de staking ou de contratos.

NEP-141 e jogos

Jogos na NEAR podem usar tokens NEP-141 como moedas de jogo, recompensas, pontos de energia, materiais de criação, ativos de governança ou tokens de pagamento.

Um jogo pode usar tokens NEP-141 junto com NFTs, em que o token fungível serve para pagamentos e os NFTs representam itens únicos.

Por exemplo, um jogo poderia usar um token NEP-141 para pagamentos em marketplaces e NFTs NEP-171 para personagens ou equipamentos.

Esse modelo com dois tipos de token pode dar suporte a economias de jogo flexíveis.

No entanto, tokens de jogos podem sofrer inflação se muitas recompensas forem emitidas sem demanda suficiente.

Os desenvolvedores devem projetar cuidadosamente mecanismos de consumo de tokens, controles de oferta, regras de recompensa e utilidade.

Os jogadores devem entender se o token é usado em um jogo já disponível ou se está apenas prometido para recursos futuros.

Um token de jogo NEP-141 pode seguir tecnicamente o padrão e ainda perder valor se a economia do jogo for mal projetada.

Os padrões de token facilitam a integração, mas a qualidade do jogo sustenta a demanda no longo prazo.

NEP-141 e DAOs

DAOs e projetos comunitários podem usar tokens NEP-141 para governança, poder de voto, recompensas, operações de tesouraria ou utilidade semelhante à de uma associação.

Um token de governança pode permitir que os titulares votem em propostas ou expressem as preferências da comunidade.

O próprio contrato do token pode apenas registrar saldos e transferências.

A lógica de governança geralmente fica em contratos ou aplicativos separados que consultam os saldos do token.

Os usuários devem entender se possuir o token concede poder de governança real ou apenas influência simbólica.

Se a governança usar votação ponderada pelo saldo, grandes titulares podem ter mais poder de voto do que os menores.

Os projetos devem divulgar claramente a distribuição do token, os saldos da tesouraria, o vesting e as regras de votação.

Um token de governança não deve ser avaliado apenas pelo símbolo ou pela atividade da comunidade.

Os direitos reais de governança dependem de todo o projeto de governança, e não apenas do padrão NEP-141.

NEP-141 e ativos wrapped

Ativos wrapped podem usar a NEP-141 para representar ativos de outras redes ou sistemas em aplicativos da NEAR.

Um token wrapped geralmente depende de uma bridge, custodiante, sistema de emissão e queima ou mecanismo de prova que vincule o token wrapped ao ativo original.

A NEP-141 pode fazer o token wrapped se comportar como um token fungível comum dentro da NEAR.

No entanto, o padrão do token não comprova que o ativo wrapped tenha cobertura integral.

Os usuários devem entender o projeto da bridge ou da custódia por trás de qualquer ativo wrapped.

Devem verificar regras de resgate, sistemas de prova, taxas, limites, liquidez e segurança do contrato.

Um token NEP-141 wrapped pode ser útil para obter liquidez entre ecossistemas, mas acrescenta pressupostos de confiança e técnicos.

Os aplicativos devem identificar claramente os ativos wrapped para que os usuários não os confundam com ativos nativos.

A cobertura e o resgate são tão importantes quanto a compatibilidade do token.

NEP-141 e carteiras

As carteiras usam métodos e metadados NEP-141 para exibir saldos de tokens e ferramentas de transferência.

Uma carteira pode chamar

para exibir um saldo e para mostrar o nome, o símbolo, o ícone e as casas decimais do token.

Uma carteira também pode ajudar os usuários a registrar o armazenamento antes de receber um token.

Se um token não for exibido, talvez a carteira ainda não o tenha indexado, a conta não esteja registrada, os metadados estejam ausentes ou o contrato do token não seja compatível.

Os usuários devem verificar os nomes das contas de contrato dos tokens antes de confiar nos ativos exibidos.

Tokens fraudulentos podem copiar nomes, símbolos e ícones de ativos legítimos.

A exibição em uma carteira não deve ser tratada como prova de que um token é oficial.

Para verificar tokens, os usuários devem consultar fontes oficiais do projeto, nomes de contas de contrato e histórico de transações.

Um bom projeto de carteira ajuda os usuários a ver tanto a identidade do token quanto o contrato por trás dele.

NEP-141 e listagens de tokens

As listagens de tokens em aplicativos costumam depender dos metadados, da verificação da conta do contrato, da liquidez e do reconhecimento da comunidade.

Um token NEP-141 pode existir on-chain mesmo que não esteja listado em uma carteira, rastreador de portfólio, interface DeFi ou página de análise.

Uma listagem não significa automaticamente que o token seja seguro ou valioso.

A ausência de listagem também não significa automaticamente que o token seja inválido.

Os aplicativos podem usar filtros próprios para reduzir spam, símbolos copiados, contratos maliciosos e ativos de baixa qualidade.

Os projetos devem publicar os nomes oficiais das contas de contrato e os metadados para que os usuários possam verificar o token verdadeiro.

Os usuários devem ter cuidado quando um token tem um símbolo familiar, mas uma conta de contrato desconhecida.

A identidade do token vem da conta do contrato e das fontes oficiais do projeto, e não apenas do símbolo.

Verificações claras da identidade do token reduzem o risco de tokens falsos.

NEP-141 e segurança

A segurança da NEP-141 depende da implementação do contrato, das permissões de conta, das integrações com aplicativos e do comportamento dos usuários.

Um token pode seguir a NEP-141 e ainda ter controles de emissão arriscados, permissões administrativas fracas, lógica insegura para receptores, gerenciamento de armazenamento inadequado ou metadados enganosos.

Os usuários devem verificar os nomes das contas de contrato antes de transferir, depositar ou trocar tokens.

Devem ter cuidado com símbolos falsos de tokens, páginas de phishing, aplicativos maliciosos e links de resgate enviados por mensagens diretas.

O guia da FTC sobre golpes com criptomoedas recomenda atenção a falsas oportunidades cripto, personificação e promessas de grandes retornos.

Nenhum contrato de token ou canal de suporte legítimo deve pedir uma seed phrase, frase de recuperação ou chave privada.

Os desenvolvedores devem testar transferências, chamadas de transferência, registro de armazenamento, emissão, queima e casos extremos antes do lançamento.

Quando relevante, os projetos devem divulgar chaves administrativas, regras de atualização, autoridade de emissão, controles de pausa e saldos da tesouraria.

A segurança é uma questão que envolve todo o sistema, não apenas a conformidade com um padrão.

NEP-141 e perda de tokens

A perda de tokens pode ocorrer quando os usuários os enviam à conta errada, usam o contrato incorreto, não registram o armazenamento ou interagem com aplicativos inseguros.

Diferentemente de um saldo em uma conta centralizada, uma transferência de tokens em blockchain pode não ser reversível.

Os usuários devem confirmar a conta receptora antes de enviar tokens NEP-141.

Também devem confirmar se um contrato pode realmente receber tokens antes de usar

.

Enviar tokens a um contrato que não foi projetado para recebê-los pode gerar resultados confusos ou irreversíveis.

Os aplicativos devem esclarecer os requisitos do destinatário antes de o usuário assinar.

Na primeira interação com um contrato novo, os usuários devem testar com quantidades pequenas.

Devem manter NEAR nativo suficiente para gas e operações relacionadas a armazenamento.

Revisar cuidadosamente as transações é a forma mais simples de reduzir a perda de tokens.

NEP-141 e impostos

As atividades com tokens NEP-141 podem gerar dúvidas sobre declaração de impostos, dependendo do país e da situação pessoal do usuário.

A página oficial do IRS sobre ativos digitais informa que transações com ativos digitais podem precisar ser declaradas e que a renda proveniente de ativos digitais pode estar sujeita a impostos.

Comprar, vender, trocar, receber, ganhar, fazer staking, transferir por uma bridge ou usar tokens NEP-141 pode ter consequências fiscais em algumas jurisdições.

O recebimento de recompensas em tokens pode gerar questões tributárias sobre renda.

A troca de um token por outro pode exigir cálculos de ganhos ou perdas.

Em alguns lugares, o uso de um token para comprar um NFT ou pagar por um serviço também pode ser considerado uma alienação.

Os usuários devem manter registros de hashes de transação, datas, nomes de contas, quantidades de tokens, valores justos de mercado, taxas de gas, depósitos de armazenamento e valores recebidos.

Os projetos devem registrar emissões, atividade da tesouraria, recompensas, incentivos de liquidez e distribuições de tokens.

Usuários com atividade significativa com tokens devem consultar um profissional tributário qualificado.

NEP-141 e propriedade intelectual

Os tokens NEP-141 normalmente representam saldos fungíveis, mas alguns podem estar vinculados a uma marca, jogo, comunidade, obra de arte ou ecossistema de mídia.

Possuir um token não concede automaticamente direitos autorais, de marca registrada ou comerciais sobre a marca ou o conteúdo do projeto.

O estudo sobre NFTs do U.S. Copyright Office e da USPTO explica que a propriedade de tokens e os direitos de propriedade intelectual podem ser questões distintas em aplicativos de NFT; a mesma cautela também é útil para alegações relacionadas a mídias vinculadas a tokens.

Um projeto pode conceder aos titulares de tokens acesso, governança, recompensas, descontos ou direitos de participação.

Esses direitos devem ser explicados nos termos ou na documentação do projeto.

Os usuários não devem presumir que possuir um token NEP-141 significa ser proprietário de uma marca, protocolo, obra de arte, personagem de jogo ou empresa.

Os direitos legais dependem do projeto do token, dos documentos do projeto e da legislação aplicável.

Uma descrição clara dos direitos ajuda a evitar confusão entre os usuários.

A propriedade do token deve ser diferenciada da propriedade intelectual, a menos que os termos as vinculem claramente.

NEP-141 e tokenomics

Tokenomics descreve o projeto econômico de um token NEP-141.

Entre os fatores importantes estão oferta total, oferta circulante, regras de emissão, regras de queima, emissões, recompensas, vesting, alocação para a tesouraria, utilidade, taxas, governança e liquidez.

A NEP-141 define o comportamento do token, mas não determina se sua tokenomics é saudável.

Um token pode seguir o padrão e ainda ter utilidade fraca, inflação alta, propriedade concentrada ou desbloqueios pouco claros.

Os usuários devem avaliar a tokenomics antes de considerar valioso um token NEP-141.

Os desenvolvedores devem explicar se a oferta pode aumentar e quem controla a emissão.

Os projetos devem divulgar em linguagem clara as alocações da tesouraria, os cronogramas de vesting e as emissões de recompensas.

Uma tokenomics sólida deve vincular a demanda do token à atividade real do ecossistema.

Uma tokenomics fraca costuma depender apenas de hype ou incentivos de curto prazo.

NEP-141 e emissão

Emitir significa criar novas unidades de token e aumentar a oferta.

A NEP-141 inclui o comportamento de transferência e saldo, mas o método exato de emissão depende da implementação do contrato.

Alguns contratos de token emitem uma oferta fixa na implantação.

Alguns permitem que um proprietário, DAO ou função autorizada faça novas emissões posteriormente.

Alguns contratos emitem recompensas com base em staking, jogos, liquidez ou atividade do protocolo.

A autoridade de emissão é um dos fatores de risco mais importantes de um contrato de token fungível.

Se uma conta puder emitir tokens sem limite, os titulares poderão enfrentar risco de diluição.

Os projetos devem divulgar claramente a autoridade de emissão e as regras de oferta.

Os usuários não devem avaliar um token apenas pela oferta atual se ainda houver possibilidade de novas emissões.

NEP-141 e queima de tokens

Queimar significa remover unidades de token de circulação de acordo com as regras do contrato.

Um contrato de token pode queimar tokens em resgates, taxas, criação de itens em jogos, redução de oferta, decisões de governança, saídas de bridges ou mecanismos do protocolo.

Quando implementados corretamente, os eventos padrão NEP-297 podem ajudar indexadores a acompanhar a atividade

.

A queima pode reduzir a oferta, mas não torna automaticamente um token valioso.

A demanda, a utilidade, a liquidez e a distribuição continuam sendo importantes.

Os usuários devem entender por que as queimas acontecem e quem pode acioná-las.

Os projetos devem explicar se as queimas são permanentes e se reduzem a oferta total.

Os mecanismos de queima devem ser auditados e testados, pois erros na contabilização da oferta podem prejudicar a confiança.

A queima só é relevante quando os usuários entendem sua justificativa econômica.

NEP-141 e permissões de conta

As contas NEAR podem usar chaves de acesso com diferentes permissões.

Isso é importante para transferências de tokens NEP-141, pois ações confidenciais precisam ser assinadas por uma conta com autoridade adequada.

Alguns aplicativos podem solicitar chaves de acesso limitadas para facilitar interações repetidas.

O acesso limitado pode melhorar a experiência do usuário, mas é importante entender o que a chave pode fazer.

Uma permissão maliciosa ou ampla demais pode criar riscos para os tokens.

Os usuários devem revisar as permissões dos aplicativos antes de aprová-las.

Devem remover chaves de acesso antigas ou não utilizadas quando deixarem de ser necessárias.

Os projetos devem solicitar apenas as permissões necessárias para cada aplicativo.

A segurança da conta faz parte da segurança dos tokens na NEAR.

NEP-141 e chamadas entre contratos

As chamadas entre contratos são centrais ao projeto de aplicativos NEP-141.

O modelo assíncrono da NEAR significa que os contratos se comunicam por meio de promessas e callbacks, em vez de uma pilha simples de chamadas síncronas.

O padrão

permite que um contrato de token e um contrato receptor coordenem a entrega de tokens e a lógica do aplicativo.

Isso oferece suporte a depósitos, pagamentos, staking, jogos, bridges, empréstimos e outros fluxos de contratos inteligentes.

Os desenvolvedores precisam tratar cuidadosamente os resultados dos callbacks, pois os contratos receptores podem falhar, rejeitar tokens ou devolver quantidades não utilizadas.

Os usuários devem entender que depósitos em contratos não são iguais a transferências entre carteiras.

Depois que os tokens são enviados a um contrato, a lógica receptora determina o que acontece de acordo com o código.

Antes de o usuário assinar, os aplicativos devem exibir o contrato receptor e a mensagem da ação.

A composabilidade entre contratos é poderosa, mas exige um projeto cuidadoso das interfaces.

NEP-141 e indexadores

Os indexadores leem dados da blockchain e os organizam para aplicativos.

Para tokens NEP-141, os indexadores podem acompanhar transferências, emissões, queimas, saldos, titulares, metadados do contrato e eventos DeFi.

Os logs de eventos padronizados facilitam esse trabalho porque as ferramentas podem analisar nomes de eventos conhecidos.

Carteiras, exploradores, ferramentas fiscais, dashboards de análise e rastreadores de portfólio podem depender de dados indexados dos tokens.

Os dados indexados ainda podem estar atrasados, em cache, incompletos ou incorretos.

Quando os saldos exatos forem importantes, os aplicativos devem verificar o estado do contrato além dos resultados do indexador.

Os usuários devem lembrar que o saldo exibido em uma interface geralmente é uma camada visual baseada nos dados do contrato e do indexador.

Bons indexadores melhoram a usabilidade dos tokens, mas não substituem o contrato do token como fonte de verdade.

Os desenvolvedores devem considerar a compatibilidade com indexadores ao projetar eventos e metadados.

Como verificar um token NEP-141

Comece verificando na fonte oficial do projeto a conta do contrato do token.

Verifique a conta do contrato do token em vez de confiar apenas no símbolo.

Consulte

para confirmar o nome, o símbolo, as casas decimais e a especificação do token.

Consulte

para entender a oferta total atual.

Consulte

para verificar o saldo de uma conta.

Verifique se a conta precisa de

antes de receber ou usar o token.

Analise a tokenomics, a autoridade de emissão, as regras de queima, os saldos da tesouraria e a documentação do projeto.

Verifique se o token tem utilidade real, liquidez e integrações ativas.

Uma conta de contrato verificada é mais importante do que um nome conhecido ou um ícone atraente.

Boas práticas para usuários da NEP-141

Os usuários devem verificar a conta do contrato do token antes de enviar, receber, trocar ou depositar tokens.

Devem manter NEAR nativo suficiente para gas e depósitos de armazenamento.

Devem registrar o armazenamento quando um aplicativo exigir isso.

Devem ler as solicitações da carteira antes de assinar transferências ou chamadas de transferência.

Devem testar novas interações com contratos usando primeiro quantidades pequenas.

Devem evitar tokens promovidos por mensagens diretas, alegações urgentes ou promessas de lucro garantido.

Devem verificar os metadados e as casas decimais do token antes de confiar em um saldo exibido.

Devem entender a diferença entre NEAR nativo e tokens NEP-141.

Devem manter registros para impostos, contabilidade e controle pessoal.

Devem tratar toda interação com tokens como irreversível, a menos que o contrato ofereça claramente uma possibilidade de reembolso.

Boas práticas para desenvolvedores da NEP-141

Os desenvolvedores devem implementar corretamente a interface central da NEP-141.

Também devem implementar os metadados NEP-148 para que as carteiras exibam o token corretamente.

Devem usar o gerenciamento de armazenamento NEP-145 para evitar abuso dos custos de armazenamento.

Devem emitir eventos padronizados NEP-297 para transferências, emissões e queimas.

Devem tratar cuidadosamente os casos extremos de

e .

Devem testar reembolsos, chamadas de receptores com falha, quantidades zero ou muito pequenas, registro de armazenamento e ações não autorizadas.

Devem documentar a autoridade de emissão, as regras de queima, as permissões de atualização, as chaves do proprietário, os controles de pausa e o comportamento da tesouraria.

Devem evitar poderes administrativos ocultos que possam surpreender os usuários.

Um bom contrato NEP-141 deve ser compatível, seguro, transparente e fácil de integrar a aplicativos.

Erros comuns com a NEP-141

Um erro comum é pensar que os tokens NEP-141 ficam armazenados diretamente na conta do usuário.

Outro erro é esquecer que o contrato do token registra os saldos internamente.

Um terceiro erro é enviar tokens antes de o destinatário registrar o armazenamento.

Um quarto erro é confundir NEAR nativo com um token NEP-141.

Um quinto erro é confiar no símbolo de um token sem verificar a conta do contrato.

Um sexto erro é ignorar as casas decimais e interpretar incorretamente as quantidades brutas de tokens.

Um sétimo erro é usar

com um contrato receptor desconhecido.

Um oitavo erro é presumir que a conformidade com o padrão significa que a tokenomics é segura.

Um nono erro é ignorar a autoridade de emissão ou as permissões de atualização.

Um décimo erro é não manter registros fiscais e de transações.

Equívocos comuns sobre a NEP-141

Um equívoco comum é pensar que a NEP-141 é igual ao token nativo NEAR.

Na realidade, a NEP-141 é um padrão de contratos inteligentes para tokens fungíveis, enquanto o NEAR nativo é o ativo básico da rede.

Outro equívoco é pensar que todo token NEP-141 é seguro por seguir um padrão.

Um token pode seguir um padrão e ainda apresentar riscos de golpe, liquidez fraca, tokenomics ruim ou controles administrativos perigosos.

Um terceiro equívoco é achar que os metadados do token comprovam sua autenticidade.

Os metadados podem ser copiados; por isso, a conta do contrato e as fontes oficiais do projeto são mais importantes do que o símbolo ou o ícone isoladamente.

Um quarto equívoco é pensar que depósitos de armazenamento são taxas perdidas para sempre.

Alguns contratos permitem que os usuários recuperem depósitos de armazenamento não utilizados cancelando o registro quando as condições são atendidas.

Um quinto equívoco é achar que

é apenas uma transferência normal.

Ele combina uma transferência com a lógica do contrato receptor, por isso os usuários devem entender o contrato de destino antes de assinar.

Resumo de SEO e AEO sobre NEP-141 (NEAR)

NEP-141 é o padrão de tokens fungíveis para contratos inteligentes na blockchain NEAR.

Ele define métodos padronizados como

, , , , e .

Os tokens NEP-141 são registrados em contratos inteligentes, e não diretamente nas contas dos usuários.

A NEP-148 acrescenta metadados de tokens fungíveis, como nome, símbolo, ícone, casas decimais, referência e hash de referência.

A NEP-145 gerencia o armazenamento para que os contratos de tokens possam registrar contas e cobrir custos de armazenamento persistente.

A NEP-297 oferece suporte a eventos padronizados, como

, e .

A NEP-141 pode dar suporte a ativos estáveis, tokens de utilidade e governança, tokens de staking líquido, moedas de jogos, tokens de recompensa, ativos wrapped e tokens DeFi.

Antes de interagir com qualquer token NEP-141, os usuários devem verificar contas de contrato, metadados, registro de armazenamento, tokenomics, permissões, impostos e segurança.

Perguntas frequentes

O que significa NEP-141?

NEP-141 é o padrão de tokens fungíveis para contratos inteligentes na blockchain NEAR.

NEP-141 é o mesmo que NEAR nativo?

Não. O NEAR nativo é o ativo básico da rede, enquanto a NEP-141 é um padrão para tokens fungíveis emitidos por contratos inteligentes.

Quais métodos fazem parte da NEP-141?

A NEP-141 inclui métodos como

, , , e .

O que é

ft_transfer

?

é o método padrão para enviar uma quantidade de tokens NEP-141 da conta de quem fez a chamada para outra conta NEAR.

O que é

ft_transfer_call

?

envia tokens a um contrato receptor e aciona a lógica desse contrato no mesmo fluxo de transferência.

Por que os tokens NEP-141 precisam de depósitos de armazenamento?

Os depósitos de armazenamento ajudam a cobrir o armazenamento persistente on-chain usado quando contratos de tokens registram saldos de contas.

O que é a NEP-148?

A NEP-148 é o padrão de metadados de tokens fungíveis, que define campos como nome, símbolo, ícone, casas decimais, referência e hash de referência.

Os tokens NEP-141 podem ser usados em DeFi?

Sim. Os tokens NEP-141 podem ser usados em depósitos DeFi, swaps, pools de liquidez, sistemas de staking, recompensas, governança e outros fluxos de contratos inteligentes.

Todos os tokens NEP-141 são seguros?

Não. A compatibilidade com a NEP-141 não garante segurança, liquidez, tokenomics justa, contratos seguros ou comportamento legítimo do projeto.

Como posso verificar um token NEP-141?

Você pode verificar um token NEP-141 conferindo a conta oficial do contrato, os metadados, a oferta total, os métodos de saldo, o registro de armazenamento, a tokenomics e a documentação do projeto.

Conclusão

A NEP-141 é o principal padrão de tokens fungíveis da blockchain NEAR.

Ela oferece aos contratos de tokens uma interface comum para consultas de oferta e saldo, transferências, chamadas de transferência e resolução de transferências.

Esse padrão ajuda carteiras, protocolos DeFi, jogos, DAOs, ferramentas de análise e outros aplicativos a integrar tokens fungíveis com mais confiabilidade.

A NEP-141 funciona melhor quando combinada com metadados NEP-148, gerenciamento de armazenamento NEP-145 e eventos padronizados NEP-297.

Para os usuários, os conceitos mais importantes são verificar a conta do contrato, registrar o armazenamento, entender as casas decimais e o gas em NEAR nativo e revisar as solicitações da carteira.

Para os desenvolvedores, as principais responsabilidades são implementar corretamente a interface, criar uma lógica segura para chamadas de transferência, definir metadados claros, gerenciar o armazenamento de forma confiável, emitir eventos padronizados e manter controles administrativos transparentes.

Para os projetos, a NEP-141 oferece compatibilidade, mas não cria automaticamente tokenomics sólida, liquidez, utilidade ou confiança.

Para aplicativos DeFi e jogos, a NEP-141 permite fluxos poderosos de tokens por meio de

, mas a segurança dos contratos receptores continua sendo importante.

Um token NEP-141 pode ser útil, líquido e amplamente integrado quando é bem desenvolvido e gerenciado.

Um token NEP-141 também pode ser arriscado se tiver metadados enganosos, segurança fraca, regras de oferta pouco claras, baixa liquidez ou contratos inseguros.

A forma mais segura de entender a NEP-141 é considerá-la uma base técnica para tokens fungíveis na NEAR, e não uma garantia de valor ou legitimidade.

Quando usada com responsabilidade, a NEP-141 ajuda a NEAR a oferecer suporte a pagamentos, DeFi, jogos, recompensas, staking líquido, governança e muitos outros casos de uso de tokens cripto.