NEP-141: O padrão de token para a rede NEAR

Tokens fungíveis são a espinha dorsal da maioria das experiências web3, desde stablecoins e ações de LP em DeFi até pontos de incentivo e trilhas de pagamento. Na NEAR, tokens fungíveis são implementados via NEP-141 — o padrão de token canônico que define como os contratos devem emitir, transferir e contabilizar saldos em toda a rede. Este guia explica o que é NEP-141, como ele difere dos padrões familiares do Ethereum e o que desenvolvedores e usuários devem saber em 2025.

O que é NEP-141?

NEP-141 é o padrão de token fungível (FT) para NEAR. Ele especifica a interface mínima e os comportamentos que todo contrato FT deve implementar, incluindo:

• Métodos centrais de transferência
• Gerenciamento de armazenamento
• Metadados do token
• Semântica de transferência entre contratos e reembolsos

A especificação oficial é publicada no repositório de Propostas de Melhoria NEAR (NEAR Improvement Proposals) e é a melhor fonte única de verdade para implementadores. Veja o padrão e especificações complementares no GitHub da NEAR:

• Padrão de Token Fungível NEP-141 (métodos, callbacks, lógica de resolução) — FungibleToken.md
• Metadados do token (nome, símbolo, decimais, ícone, etc.) — FungibleTokenMetadata.md
• Gerenciamento de armazenamento (registro de conta e depósitos) — Storage.md
• Convenções de eventos/logs — Events.md

Para contexto sobre a NEAR e seu roadmap atual, confira o site oficial e o blog:

• NEAR Protocol — near.org
• Últimas atualizações do ecossistema e mergulhos técnicos — NEAR Blog

Por que NEP-141 é importante

• Integração consistente entre carteiras e dApps: A conformidade garante que os tokens "simplesmente funcionem" em todos os lugares — de exploradores como NEAR Explorer a aplicativos DeFi como Ref Finance.
• Comportamento previsível para chamadas entre contratos: O modelo assíncrono da NEAR torna as transferências entre contratos poderosas, mas complicadas; NEP-141 padroniza callbacks e semântica de reembolso.
• Contabilidade consciente do armazenamento: A NEAR exige que as contas paguem pelo armazenamento que utilizam. NEP-141 integra depósitos de armazenamento e registro de saldo para que os contratos permaneçam seguros e eficientes.
• Componibilidade do ecossistema: Tokens baseados em padrões permitem integrações limpas com pontes (bridges), indexadores e ferramentas, por exemplo, a Rainbow Bridge ou bibliotecas de contratos Rust.

Como NEP-141 difere do ERC-20

Embora NEP-141 e ERC-20 estejam alinhados conceitualmente, existem diferenças arquiteturais importantes:

• Chamadas assíncronas e reembolsos: As chamadas entre contratos da NEAR são assíncronas. O ft_transfer_call do NEP-141 invoca o ft_on_transfer do receptor e, em seguida, um callback de "resolução" para que tokens não utilizados possam ser reembolsados ao remetente. Isso contrasta com o fluxo síncrono típico do ERC-20. Veja os mecanismos de "resolução" no padrão — FungibleToken.md.
• Sem padrão "approve/transferFrom" por padrão: NEP-141 baseia-se em ft_transfer_call e lógica explícita do receptor em vez de um sistema de permissões global. Isso reduz a superfície de ataque baseada em permissões e se alinha melhor com a execução baseada em promessas da NEAR.
• Depósitos de armazenamento: Os usuários geralmente precisam "registrar" contas no contrato de token depositando uma pequena quantidade de NEAR para cobrir o armazenamento. Isso é formalizado no Padrão de Armazenamento — Storage.md.
• Registro de eventos: A NEAR usa formatos de log padrão em vez de eventos EVM. O Padrão de Eventos descreve como emitir logs estruturados que os indexadores podem analisar — Events.md.

Essas diferenças refletem o foco de design da NEAR em execução escalável e assíncrona e em taxas baixas, preservando a ergonomia do desenvolvedor e a segurança do usuário.

A interface NEP-141 em resumo

Métodos típicos voltados para o usuário:

• ft_transfer(receiver_id, amount, memo?): Transfere tokens para outra conta.
• ft_transfer_call(receiver_id, amount, memo?, msg): Transfere tokens e chama a lógica do contrato do receptor; tokens não utilizados são reembolsados.
• ft_balance_of(account_id): Consulta saldo.
• ft_total_supply(): Consulta o suprimento total.
• ft_metadata(): Lê metadados (nome, símbolo, decimais, ícone, hash de referência).
• Relacionados ao armazenamento: storage_deposit, storage_balance_of, storage_withdraw (do Padrão de Armazenamento).

Requisitos do contrato receptor:

• ft_on_transfer(sender_id, amount, msg) -> String: Retorna a quantidade de tokens que o receptor não utilizou (a ser reembolsada ao remetente). O contrato de token, posteriormente, chama seu próprio resolvedor para finalizar a transferência e lidar com os reembolsos.

Se você estiver desenvolvendo em Rust, use as bibliotecas canônicas:

• near-sdk (framework de contrato) — docs.rs/near-sdk
• near-contract-standards (implementação FT pronta) — docs.rs/near-contract-standards

Padrão FT mínimo em Rust (near-contract-standards)

Abaixo está um esboço simplificado; contratos de produção devem depender de near_contract_standards::fungible_token e implementar os padrões de armazenamento e eventos.

use near_contract_standards::fungible_token::FungibleToken;
use near_contract_standards::fungible_token::metadata::{FungibleTokenMetadata, FT_METADATA_SPEC};
use near_sdk::{near_bindgen, AccountId, PanicOnDefault, BorshDeserialize, BorshSerialize};

#[near_bindgen]
#[derive(BorshDeserialize, BorshSerialize, PanicOnDefault)]
pub struct Token {
    pub ft: FungibleToken,
    pub metadata: FungibleTokenMetadata,
}

#[near_bindgen]
impl Token {
    #[init]
    pub fn new(owner_id: AccountId, total_supply: near_sdk::json_types::U128) -> Self {
        let mut this = Self {
            ft: FungibleToken::new(b"t".to_vec()),
            metadata: FungibleTokenMetadata {
                spec: FT_METADATA_SPEC.to_string(),
                name: "Example Token".to_string(),
                symbol: "EXT".to_string(),
                icon: None,
                reference: None,
                reference_hash: None,
                decimals: 24,
            },
        };
        this.ft.internal_register_account(&owner_id);
        this.ft.internal_deposit(&owner_id, total_supply.0);
        this
    }

    // Expor métodos NEP-141 delegando para `ft` (transfer, transfer_call, balance_of, etc.)
}

Use os auxiliares de gerenciamento de armazenamento para que os usuários possam registrar contas e você possa rastrear o uso de armazenamento com precisão. Implemente logs estruturados de acordo com o Padrão de Eventos para indexadores.

Melhores práticas para contratos de token

• Imponha depósitos de armazenamento adequados: Exija storage_deposit antes de transferências e emissões para novas contas para evitar inchaço de estado e casos extremos — Storage.md.
• Siga os padrões de metadados e eventos: Metadados completos e logs estruturados melhoram a descoberta e a análise — FungibleTokenMetadata.md, Events.md.
• Use ft_transfer_call com cuidado: Trate a lógica do receptor como não confiável. Valide valores, lide com reembolsos por meio do resolvedor e evite suposições inseguras — FungibleToken.md.
• Mantenha saldos em inteiros de 128 bits e decimais consistentes: A NEAR comumente usa 24 decimais; documente sua escolha claramente nos metadados.
• Emita logs legíveis por humanos e analisáveis por máquinas: Indexadores e análises dependem de logs padronizados; não crie seu próprio formato.
• Forneça métodos de administração claros com controle de acesso: Emissão, pausa e atualização devem ser transparentes e auditáveis.

O impacto do ecossistema em 2025

NEP-141 impulsiona um conjunto diversificado de ativos na NEAR, incluindo stablecoins importantes. Por exemplo, a Tether integrou USDT na NEAR, melhorando as opções de liquidação e liquidez para usuários de DeFi — Tether lança USDT na NEAR. Tokens fluem entre ecossistemas através de pontes como a Rainbow Bridge, e são negociados em plataformas como a Ref Finance.

No lado do protocolo, a NEAR continua avançando na abstração de cadeia e em experiências de usuário multichain, proeminentemente através de iniciativas como Chain Signatures — que visam simplificar interações cross-chain e gerenciamento de chaves. Você pode acompanhar lançamentos contínuos e atualizações técnicas no blog oficial — NEAR Blog e o mergulho profundo na abstração de cadeia — Chain Signatures.

Para construtores, isso significa que os tokens NEP-141 participam cada vez mais de fluxos cross-chain, onboarding compatível com dispositivos móveis e composição de front-end através da stack de desenvolvedores do ecossistema NEAR. A adesão aos padrões agora garante que seus ativos permaneçam compatíveis à medida que essas capacidades se expandem.

Dicas de integração para carteiras e dApps

• Gerencie fluxos de armazenamento na UI: Solicite aos usuários que se registrem com storage_deposit antes de transferências ou trocas iniciais.
• Suporte tanto ft_transfer quanto ft_transfer_call: Muitos dApps usam este último para realizar operações atômicas e reembolsos.
• Exiba metadados de forma limpa: Use decimais para formatar saldos corretamente; exiba ícones e hashes de referência onde disponíveis.
• Analise logs padronizados: Indexe eventos NEP-141 para alimentar notificações, análises e visualizações históricas.

Os usuários podem rastrear saldos e transferências de tokens através do NEAR Explorer, e os dApps podem inspecionar contratos ou verificar implantações usando as especificações oficiais no repositório NEAR NEPs — NEPs no GitHub.

Custódia e segurança

As taxas baixas e a finalidade rápida da NEAR a tornam conveniente para transferências frequentes, mas a custódia continua sendo crítica. Se você detém tokens NEP-141 significativos ou interage com DeFi, considere mover suas chaves para uma carteira de hardware offline para verificação de transações e redução de risco de phishing. A OneKey fornece confirmações no dispositivo e suporte multichain, o que ajuda a garantir que você está aprovando os parâmetros pretendidos de ft_transfer ou ft_transfer_call durante operações críticas. Para usuários ativos da NEAR, a combinação de uma carteira de hardware com permissões de conta sensatas e dApps auditados pode reduzir materialmente sua superfície de ataque.

Principais conclusões

• NEP-141 é o padrão FT autoritativo na NEAR, combinando transferências, depósitos de armazenamento, metadados e registro de eventos em uma interface componível — FungibleToken.md.
• O modelo assíncrono e a semântica de reembolso fornecem interações entre contratos mais seguras do que os padrões baseados em permissões.
• Implemente os padrões de armazenamento e metadados; emita logs estruturados para indexadores.
• Tokens que aderem ao NEP-141 se integram perfeitamente entre pontes (bridges), carteiras e aplicativos DeFi no ecossistema em crescimento da NEAR — Rainbow Bridge, Ref Finance, NEAR Explorer.
• À medida que a NEAR evolui sua abstração de cadeia e onboarding de usuários em 2025, a conformidade com os padrões garante que seus tokens permaneçam portáteis e à prova de futuro — NEAR Blog, Chain Signatures.

Seja emitindo um novo ativo ou detendo tokens NEP-141 existentes, trate o padrão como seu projeto — em seguida, adicione segurança robusta e UX clara por cima.