Bot de negociação de NFT em ETH: separe ETH, WETH e inventário

Defina o modelo de conta do bot de negociação de NFT em ETH

O modelo de conta do bot de negociação de NFT em ETH deve separar ETH nativo, tokens fungíveis de pagamento, posições em NFT e compromissos de negociação pendentes. Cada registo responde a uma pergunta diferente e deve reter as suas próprias unidades e provas.

O saldo nativo diz ao operador quanto ETH a conta detém. Um saldo WETH descreve unidades de um contrato de token específico. O inventário de NFT identifica ativos e quantidades. As ordens descrevem possíveis trocas futuras cujos efeitos podem ainda não aparecer em nenhum dos saldos.

Associe a identidade da cadeia a todos os registos. O mesmo símbolo de token ou um endereço de aspeto familiar noutra rede não estabelecem o mesmo ativo ou fundos disponíveis. Um painel entre redes não deve deixar um total combinado tornar-se um pressuposto de transação não suportado.

O modelo também deve distinguir observações atuais de estimativas. Um pagamento esperado não é um saldo disponível, e uma avaliação pelo preço mínimo de uma coleção não é uma receita de venda. Estas separações permitem conciliação posterior quando as interfaces se atualizam em momentos diferentes.

Compreenda a separação dos saldos de ETH e WETH

A separação dos saldos de ETH e WETH reflete uma distinção efetiva entre ativos. WETH representa ETH encapsulado através do seu contrato de token; não é simplesmente outro rótulo de apresentação para o saldo de ETH nativo. A via de transação suportada determina que forma usa.

A explicação de WETH da OpenSea descreve o seu papel nas ofertas de NFT Ethereum. Um bot deve preservar a identidade relevante do token e verificar os requisitos atuais da rota, em vez de presumir que qualquer ecrã denominado em ETH pode gastar ambas as formas sem outra operação.

Encapsular ou desencapsular altera a composição de ativos da conta e pode envolver uma despesa de rede. Deve ser registado como uma conversão com custos associados, não como receita de negociação ou uma transação de NFT que se tornou lucrativa.

A distinção também afeta a disponibilidade. Uma conta com muito WETH mas pouco ETH nativo pode precisar de uma forma suportada de financiar a próxima operação de rede. Um único total combinado pode ocultar essa limitação prática.

Acompanhe uma transação hipotética de encapsulamento

Suponha que uma conta começa com 1,5 ETH e nenhum WETH. Num exemplo inventado, encapsula 1,2 ETH e paga 0,002 ETH de despesa de rede. Após a operação, detém 1,2 WETH e 0,298 ETH.

Com uma avaliação de planeamento assumida de um para um, o montante combinado é 1,498 equivalentes de ETH, refletindo a despesa de 0,002 ETH. Esta convenção de avaliação não funde os saldos nem estabelece que qualquer deles possa pagar diretamente todas as instruções subsequentes.

Se a conta desencapsular posteriormente 0,2 WETH e pagar outra despesa assumida de 0,001 ETH, WETH desce para 1,0 e ETH nativo sobe para 0,497. A operação aumenta o ETH nativo disponível enquanto reduz o saldo encapsulado.

Preserve ambos os lados de cada conversão e a referência efetiva da transação. Um relatório que mostre apenas o ETH recebido do desencapsulamento pode classificar incorretamente capital devolvido como rendimento. O histórico económico subjacente explica por que mudou o saldo.

Mantenha as reservas de gas no ativo que as paga

Numa transação Ethereum convencional em que a conta paga diretamente a comissão de rede, a despesa de gas é paga em ETH. Um saldo WETH não satisfaz automaticamente esse requisito de financiamento nativo. Mecanismos alternativos de pagamento suportados devem ser identificados explicitamente, em vez de presumidos.

O bot deve reservar um montante nativo adequado para operações permitidas e recuperação da conta. Esta reserva é uma escolha de política, distinta de qualquer orçamento de tokens de pagamento usado para adquirir NFT. Deve continuar visível na vista da conta.

O guia de comissões de gas da OpenSea para negociação examina como ações diferentes criam custos de rede. Aqui, o ponto contabilístico importante é que o ativo usado para o NFT e o ativo usado para a operação de rede podem diferir.

Não descreva a reserva como uma despesa até ser efetivamente gasta. Reduz a permissão atual de compra porque o responsável a protegeu para outra finalidade, mas continua a ser um ativo da conta. Confundir uma reserva com uma comissão pode distorcer tanto os totais monetários como o desempenho apresentado.

Calcule o gas nas suas unidades efetivas

A documentação de gas da Ethereum distingue quantidades de gas do preço por unidade de gas. O bot deve preservar essas unidades, em vez de tratar um limite de gas como um montante de ETH ou uma cotação de preço como uma comissão total.

Para uma transação fictícia, um limite de 160 000 unidades de gas e uma comissão máxima de 50 gwei por unidade implicam um montante máximo permitido de custo de gas de 0,008 ETH. O cálculo usa um gwei igual a um milésimo de milionésimo de ETH. Não significa que todo o montante permitido será necessariamente cobrado.

Se o uso efetivo hipotético for de 120 000 unidades a um preço efetivo de 30 gwei, a despesa efetiva é 0,0036 ETH. O registo contabilístico deve guardar esse resultado separadamente da reserva anterior de 0,008 ETH.

Estes são cálculos ilustrativos de Ethereum, não dimensões típicas de transações de NFT ou preços atuais. As estimativas reais dependem da operação e do estado, e outras redes podem ter componentes adicionais de comissões. O modelo deve usar a semântica efetiva dos comprovativos e dos custos da cadeia relevante.

Mantenha os compromissos em WETH separados das posições em WETH

Um saldo de pagamento detido na carteira pode sustentar ofertas assinadas que podem executar mais tarde. O bot precisa de acompanhar esses compromissos, além do saldo atual de tokens. Uma consulta de saldo, por si só, não explica quanto a política de negociação do utilizador já afetou.

Suponha que uma conta Ethereum hipotética detém 1,2 WETH e tem dois compromissos de aquisição ativos separados de 0,45 e 0,50 WETH. A sua possível despesa combinada é 0,95 WETH, deixando 0,25 WETH segundo uma política simples de reserva integral.

A carteira pode continuar a apresentar os 1,2 WETH antes de qualquer oferta executar. Essa apresentação não significa que a política deva autorizar outros 1,2 WETH de obrigações. O cálculo de reservas descreve possível utilização futura dos mesmos ativos.

Não generalize este modelo específico de fundos detidos na carteira a todas as cadeias. As ofertas de mercados Solana podem usar mecanismos de financiamento diferentes. O guia de um processo de negociação de NFT por contratos inteligentes destaca a verificação do mecanismo efetivo subjacente à interface, em vez de aplicar um modelo de conta em todo o lado.

Separe as autorizações de pagamento das permissões de NFT

Uma autorização de token fungível permite a uma entidade autorizada específica gastar segundo as regras desse token. As permissões de NFT autorizam transferências específicas ou um operador segundo a norma do NFT e o comportamento do contrato. Não devem partilhar um único campo ambíguo de aprovado no modelo da conta.

O bot deve identificar a cadeia, o contrato do token, a entidade autorizada a gastar ou o operador e o âmbito relevante. Uma aprovação para gastar WETH não significa que um contrato sem relação possa mover NFT. Uma aprovação de operador de NFT não estabelece que a conta tenha tokens de pagamento suficientes para uma compra.

A política de estratégia da conta continua a ser uma restrição separada. Uma aprovação técnica pode permitir ações mais abrangentes do que o conjunto de coleções ou limite de preço permitidos ao bot. A via de transação precisa de fazer cumprir essas regras mais restritas antes de usar as permissões disponíveis.

Quando uma permissão mudar, preserve as provas e o momento. Um interruptor local não deve ser apresentado como uma revogação na cadeia, salvo se a ação suportada tiver sido efetivamente concluída. Ordens existentes e operações pendentes podem ainda precisar de conciliação separada.

Identifique itens ERC-721 pelo contrato e pelo token

A norma ERC-721 define uma interface para tokens identificados individualmente, incluindo operações relacionadas com propriedade e transferência. Um registo de negociação deve preservar o contrato e o identificador do token juntamente com a cadeia.

Duas coleções podem usar o mesmo identificador numérico sem se referirem ao mesmo NFT. Um número de item como 42 não tem, por isso, significado completo sem o contexto do seu contrato. O nome e a imagem apresentados são metadados adicionais, em vez de substitutos dessa identidade.

Use as provas adequadas de propriedade para o contrato efetivo. Uma contagem de tokens ao nível da coleção não estabelece que a conta detenha o item específico que pretende listar. O bot tem de verificar o ativo específico relevante para a ação proposta.

Preserve também o histórico quando um item sai e regressa mais tarde. O identificador mantém-se, mas o custo de aquisição e o episódio de detenção podem mudar. Substituir o registo antigo apagaria o resultado económico da operação anterior.

Use contabilização de quantidades ERC-1155

A contabilização de quantidades ERC-1155 precisa de saldos para cada identificador de token relevante. A norma ERC-1155 suporta vários tipos de token e quantidades de transferência dentro de um contrato. Um indicador de propriedade de um item não representa corretamente todas essas posições.

Um bot deve preservar o contrato, o identificador, a conta e a quantidade no registo de inventário. Uma transferência de algumas unidades pode deixar um saldo restante sob o mesmo identificador. O item aparecer na carteira depois não significa que a quantidade original permaneça inalterada.

As operações em lote também precisam de interpretação cuidada. Uma transação pode afetar vários identificadores ou quantidades. O processo contabilístico deve reconstruir as mudanças efetivas de ativos, em vez de atribuir toda a transação ao item que a interface mostre primeiro.

O rótulo da norma é um dado para o modelo de propriedade, não prova de que todos os contratos ou rotas de mercado suportem todas as operações possíveis. Verifique o comportamento suportado relevante para a compra ou venda pretendida e recuse claramente os casos não suportados.

Acompanhe uma compra de várias unidades através de uma venda parcial

Considere uma compra fictícia separada de oito unidades a 0,035 equivalentes de ETH cada, com 0,004 equivalentes de ETH de despesa de entrada afetada. O custo total de aquisição é 0,284 equivalentes de ETH. Com afetação igual, cada unidade tem 0,0355 de custo.

Suponha que três unidades são vendidas posteriormente por 0,05 cada. As receitas brutas são 0,15. Uma dedução inventada de 3% é 0,0045, e uma despesa de saída afetada separada de 0,002 deixa receitas líquidas de 0,1435.

As três unidades vendidas têm 0,1065 de custo de aquisição, dando um ganho realizado de 0,037. Restam cinco unidades com 0,1775 de custo afetado. O seu resultado final continua em aberto e não deve ser contado como lucro realizado.

O exemplo usa uma unidade comum de planeamento para facilitar a leitura. Um registo efetivo retém separadamente o token de pagamento e as despesas nativas antes de aplicar um método declarado de avaliação. Isto impede um total conveniente de ocultar que ativos efetivamente entraram ou saíram da conta.

Preserve montantes inteiros e identificadores de tokens

Os valores na cadeia usam frequentemente unidades base inteiras, enquanto as interfaces apresentam montantes decimais. O bot deve efetuar conversões deliberadas usando as casas decimais do ativo relevante e preservar valores exatos para a construção de transações. Aproximações binárias de vírgula flutuante podem ser inadequadas para fronteiras monetárias exatas.

Os identificadores de tokens também precisam de tratamento exato. São identificadores, não valores para arredondar na apresentação ou nas análises. Um identificador grande deve sobreviver ao armazenamento, exportação e consulta sem ser alterado por um tipo de dados escolhido por conveniência.

O registo interno pode fornecer formatação legível por pessoas junto do valor exato. Isto ajuda o operador a inspecionar uma proposta sem perder a precisão necessária para verificar a transação. A formatação da apresentação não deve modificar o montante autorizado subjacente.

Um pequeno conjunto de testes pode incluir um pagamento fracionário, um identificador de token grande e dois ativos com convenções de casas decimais diferentes. Os resultados esperados devem ser conhecidos antes de executar a ferramenta para que um erro de conversão seja visível, em vez de absorvido num total de aspeto plausível.

Interprete separadamente ordens assinadas e resultados de transações

Uma listagem ou oferta assinada expressa condições que podem ser cumpridas segundo o protocolo aplicável. Não é, por si só, prova de que a propriedade ou o pagamento já mudaram. O bot deve manter o estado da ordem e os efeitos na conta como registos ligados mas distintos.

Quando ocorrer execução, inspecione as mudanças efetivas de ativos, o destinatário e a contrapartida. Um indicador geral de sucesso da transação não explica, por si só, todos os efeitos económicos de uma transação que contém várias operações.

Mantenha submissões incertas visíveis até as provas relevantes da cadeia as resolverem. Um tempo de espera esgotado não deve libertar automaticamente a reserva nem criar outra aquisição independente. O processo de recuperação começa pela intenção original e pela referência da transação.

Esta distinção também melhora a interface do utilizador. Uma ordem pode estar ativa enquanto a conta ainda detém o NFT, ou uma aquisição pode estar verificada enquanto um índice do mercado ainda não foi atualizado. O ecrã deve descrever esses estados, em vez de os comprimir num único rótulo enganador de concluído.

Mantenha explícita a identidade da cadeia entre redes EVM

Um formato de endereço compatível com Ethereum não torna saldos ou contratos intercambiáveis entre redes. O bot deve incluir a identidade da cadeia ao guardar contratos de tokens, permissões, rotas de ordens e referências de transações.

O guia de um bot de NFT Polygon fornece uma comparação útil. A compatibilidade EVM pode tornar familiares alguns conceitos de software, enquanto ativos nativos de gas, contratos implementados e vias de mercados suportadas continuam a exigir verificação separada.

Não use um saldo combinado de painel para autorizar uma transação numa rede, salvo se uma via suportada de financiamento fizer parte da proposta efetiva. Fundos detidos noutro local não ficam automaticamente disponíveis no destino apenas porque os símbolos coincidem.

Se uma rota entre redes for usada intencionalmente, registe as suas etapas e custos efetivos. Uma transferência pendente entre redes é outra operação de conta por resolver, não uma desculpa para presumir que o saldo de destino já aumentou.

Concilie transferências sem inventar rendimento de negociação

Encapsular, desencapsular e mover entre carteiras do responsável pode alterar saldos sem criar uma venda lucrativa de NFT. O registo contabilístico precisa de uma classificação que preserve essas diferenças e evite tratar todos os ativos recebidos como receita.

Um NFT recebido sem um registo conhecido de compra pode ter um custo histórico por resolver. Registe o ativo e a informação em falta, em vez de atribuir uma base de custo nula apenas porque não apareceu um pagamento na mesma transação.

Da mesma forma, um NFT enviado pode representar uma transferência interna em vez de uma venda. As receitas de venda exigem provas de contrapartida e contexto. A direção do movimento do token, por si só, não estabelece o resultado financeiro.

Esta disciplina torna a análise de toda a conta mais credível. Despesas de ETH nativo, alterações de tokens de pagamento e transferências de NFT devem conciliar-se num histórico coerente, com itens desconhecidos visíveis, em vez de escondidos num ajuste que torne conveniente o saldo final.

Teste o modelo de conta com incompatibilidades deliberadas

Um teste útil inclui WETH suficiente para uma oferta, mas fundos nativos insuficientes para a operação de rede pretendida e paga diretamente. O resultado esperado é uma rejeição por financiamento ou uma solução suportada analisada separadamente, não uma alegação de que o saldo combinado é suficiente.

Outro caso de teste pode incluir uma venda parcial ERC-1155 e uma observação duplicada de transferência. A quantidade restante e a afetação de custos devem mudar uma vez para a venda efetiva. Provas repetidas não devem criar unidades extra ou receitas extra.

Teste também a cadeia errada e uma autorização de pagamento atribuída à entidade errada para gastar. Estes erros devem ser identificados antes da assinatura, com contexto suficiente para o operador compreender a incompatibilidade. Uma falha genérica após a submissão é um controlo mais fraco.

Os testes estabelecem comportamento dentro do âmbito declarado. Não validam uma estratégia de avaliação nem garantem compatibilidade futura. O seu valor é mostrar que o software preserva as distinções necessárias para compreender a conta.

Um bot de negociação ERC-721 deve preservar a identidade da cadeia, do contrato e do token ao longo das verificações de propriedade, aprovações, ordens e transferências confirmadas.

Mantenha explicável o registo do bot de negociação de NFT em ETH

A vista final da conta deve permitir ao leitor separar ETH nativo disponível para gastar, saldos de tokens de pagamento, possíveis compromissos de ordens, quantidades verificadas de NFT e despesas realizadas. Um total comum de avaliação pode ficar acima desses registos sem os substituir.

Quando um resultado parecer surpreendente, siga-o até às mudanças de ativos subjacentes. Uma diminuição de WETH pode financiar uma aquisição, uma diminuição de ETH pode pagar gas e uma venda parcial de NFT pode deixar uma posição substancial em aberto. O registo contabilístico deve explicar cada relação nas suas próprias unidades.

Analise estimativas e custos efetivos depois de as transações serem concluídas, preservando a autorização original. As diferenças podem melhorar o planeamento posterior, mas reescrever a proposta antiga para a fazer coincidir com o resultado ocultaria se o controlo funcionou.

É mais fácil confiar num bot de negociação de NFT em ETH quando não confunde ativos, normas ou estados. Uma separação clara sustenta autorização correta e análise financeira rigorosa, incluindo a conclusão de que a conta não tem os fundos ou provas certos para a próxima operação proposta.