Negociação de NFT por contratos inteligentes: ordens e aprovações

A negociação de NFT por contratos inteligentes envolve vários contratos

Comece pelo contrato do NFT. Num item EVM típico, a combinação de rede, endereço de contrato e identificador do token distingue o ativo. A imagem e o nome da coleção são descrições úteis, mas não substituem esses identificadores. Dois contratos podem apresentar arte quase idêntica e registar tokens diferentes.

Um protocolo de mercado tem uma função diferente. Verifica as condições suportadas das ordens e coordena transferências especificadas quando a concretização é válida. Seaport é um exemplo EVM importante; o seu modelo de ordens separa ativos oferecidos de contrapartidas exigidas. Essa estrutura pode representar mais do que uma troca simples de um NFT por um pagamento.

Um contrato de token de pagamento acrescenta outra fronteira quando a operação usa um ativo ERC-20 como WETH. O saldo de ETH nativo e o saldo de WETH da carteira são distintos. O ativo exigido de pagamento tem de corresponder à ordem, e a permissão relevante de transferência tem de ser válida quando necessária.

Componentes adicionais podem impor restrições de transferência, rendimentos dos criadores ou outras condições suportadas. A sua presença deve ser compreendida a partir da via efetiva em vez de inferida de um nome familiar de coleção. Um diagrama genérico com comprador, vendedor e mercado pode ocultar várias verificações significativas.

A visão geral de Seaport da OpenSea fornece o vocabulário básico de oferta e contrapartida. Use esse vocabulário para identificar ativos e destinatários numa ordem EVM, verificando os detalhes atuais de implementação no fluxo específico suportado.

As normas de tokens alteram o significado da quantidade

Um identificador de token ERC-721 identifica tipicamente um NFT distinto com um único proprietário atual no modelo de propriedade dessa norma. Uma instrução de negociação deve identificar o token pretendido em vez de apenas a coleção. A propriedade do token 17 não estabelece a propriedade do token 18.

ERC-1155 suporta vários tipos de tokens num contrato e quantidades para cada identificador. Uma ordem de uma unidade de um identificador pode, portanto, diferir de uma ordem de todas as unidades detidas pela carteira. A apresentação de um anúncio precisa de conservar a quantidade selecionada e o ID do token.

A documentação de ERC-721 e a documentação de ERC-1155 da Ethereum descrevem estas interfaces diferentes. Ajudam a explicar por que um contador genérico de saldo de NFT é insuficiente para analisar transações.

Considere uma carteira fictícia que detém cinco unidades de um identificador ERC-1155. Uma venda proposta de duas unidades deve deixar três se for executada como pretendido e não houver outras alterações relevantes. Um relatório que marca todo o identificador como vendido apagaria o inventário restante.

A norma também afeta aprovações suportadas e comportamento de receção. Uma transferência pode falhar porque o destino ou as condições da chamada são incompatíveis, mesmo quando o nome e o montante apresentados parecem corretos. Analise o ativo e a via efetivos em vez de presumir que todos os NFT seguem a mesma função de transferência.

Uma aprovação é permissão, e não uma compra

Uma aprovação autoriza um operador a agir num âmbito definido. Não é o mesmo que assinar um preço de compra, colocar um anúncio ou confirmar que ocorreu uma venda. Separar estes conceitos ajuda a explicar por que uma carteira pode pedir mais de uma autorização durante um fluxo.

Em ERC-721, as permissões podem incluir aprovação de um token específico ou aprovação de operador para os tokens do proprietário nesse contrato. ERC-1155 usa aprovação de operador na sua interface padrão. As autorizações de tokens de pagamento têm a sua própria semântica de montante e entidade autorizada a gastar. A permissão exata deve ser verificada antes de ser concedida.

As aprovações na negociação de NFT por contratos inteligentes devem, portanto, ser analisadas por contrato, operador e âmbito. «Aprovar mercado» é um rótulo conveniente, mas a pergunta com consequências é que endereço recebe que capacidade sobre que ativos. Um logótipo familiar não responde a essa pergunta.

Uma aprovação existente pode permanecer depois de uma operação específica terminar. Remover um anúncio não revoga necessariamente uma permissão de token, e revogar uma permissão não apaga o registo histórico do anúncio. São controlos relacionados com efeitos diferentes.

A análise prática é proporcional à ação. Compreenda a permissão necessária para a via pretendida, verifique o contexto do pedido e conserve informação suficiente para a examinar ou revogar mais tarde por meios suportados. Nenhuma estratégia de negociação precisa de uma chave secreta copiada para uma nota de investigação para explicar estas fronteiras.

Uma ordem assinada descreve uma troca condicional

Uma ordem assinada regista termos que uma contraparte pode conseguir concretizar enquanto a ordem permanecer válida. O seu significado pode incluir identificadores de ativos, montantes, destinatários, tempos de validade e critérios. Não é simplesmente uma mensagem a dizer que quem assina gosta do preço atual.

Numa venda, examine o que sai do vendedor e o que o vendedor ou outros destinatários designados têm de receber. Numa oferta, examine que ativos o licitante pagará e que critérios de NFT podem satisfazer a troca. A direção muda, mas a necessidade de ler ambos os lados permanece.

As ordens assinadas de negociação de NFT por contratos inteligentes podem ter consequências depois de a interface de assinatura fechar. Uma contraparte pode agir mais tarde enquanto as condições necessárias se mantiverem. É por isso que duração, financiamento, propriedade e estado de cancelamento pertencem à vista contínua da conta.

Identificadores de ordens e hashes de transações respondem a perguntas diferentes. A ordem identifica os termos condicionais. Uma transação de concretização identifica uma tentativa específica de os executar. Várias atualizações de estado de uma ordem não devem ser contadas como várias operações independentes.

Não equipare um pedido de assinatura a um início de sessão inofensivo apenas porque não cobra imediatamente gás. A questão importante é o que a mensagem assinada autoriza. Uma interface bem concebida deve expor o domínio, os termos e o efeito pretendido numa forma compreensível para quem assina.

Leia a contrapartida como um mapa completo de pagamentos

Uma venda pode direcionar partes do pagamento bruto para destinatários diferentes. O montante fornecido pelo comprador nem sempre é o que o vendedor conserva. Essa diferença importa tanto para a análise da transação como para a contabilidade do lucro.

Imagine uma compra inventada com contrapartida total de 1,20 ETH. O mapa especificado de pagamentos envia 1,128 ao vendedor, 0,024 a um destinatário de comissão e 0,048 a um destinatário criador. Esses três montantes somam 1,20. Suponha que o comprador gasta separadamente 0,007 ETH na execução da rede.

A saída total do comprador neste exercício é 1,207 ETH. Acrescentar novamente os 0,024 e 0,048 aos 1,20 contaria duas vezes montantes já incluídos na contrapartida. O recebimento bruto do vendedor no mapa de pagamentos é 1,128, e não 1,20.

Estas percentagens fictícias não são comissões atuais da OpenSea. A finalidade é mostrar por que a discriminação efetiva da transação tem de identificar pagador, destinatário e base de comissão. Uma apresentação de «comissões incluídas» deve ser reconciliada com as transferências, em vez de interpretada como significando que nenhum destinatário recebe uma comissão.

Pagamentos obrigatórios e opcionais aos criadores também precisam de tratamento separado. A referência de concretização de anúncios da OpenSea distingue inclusão opcional de comissões de criadores já obrigatórias. Não se deve presumir que uma definição opcional remove um montante obrigatório da contrapartida.

Um mapa claro de pagamentos torna a operação passível de análise antes da assinatura e o registo reproduzível depois. Também expõe destinatários inesperados que um preço de compra em destaque não revelaria.

A negociação de NFT por contratos inteligentes tem fronteiras de atomicidade

Uma transição atómica de estado significa que as alterações relevantes dentro dessa transação ocorrem segundo as suas regras de execução ou são revertidas quando a transação falha. Isto pode proteger a relação entre um pagamento e uma transferência de NFT dentro de uma troca corretamente concebida.

Ao avaliar negociação de NFT por contratos inteligentes com liquidação atómica, identifique a transação exata cujos efeitos têm de ter sucesso em conjunto. A fronteira é a transação efetiva e o comportamento do contrato. Não inclui automaticamente uma aprovação separada feita antes, uma revenda futura ou uma transferência noutra rede. Uma estratégia composta por várias transações pode, portanto, terminar num estado intermédio mesmo quando cada transação individual segue as suas regras.

Por exemplo, uma aprovação pode ter sucesso e depois uma compra falhar porque o item foi vendido noutro local. A aprovação pode permanecer mesmo que o NFT não tenha sido adquirido. Tratar todo o percurso do utilizador como uma ação atómica produziria uma interpretação errada da conta.

O comportamento em lote também precisa de exame. Algumas vias suportadas podem processar ordens disponíveis e deixar outras indisponíveis sem execução. Uma transação exterior bem-sucedida não deve ser lida automaticamente como confirmação de que cada item originalmente selecionado pelo utilizador foi comprado. Reconcilie transferências e quantidades efetivas.

A pergunta crucial é que efeitos a chamada submetida exige em conjunto e quais permite que tenham sucesso independentemente. Um botão com rótulo comprar em lote, lote ou executar não estabelece essa garantia. A semântica suportada da transação estabelece-a.

Uma compra bem-sucedida não assegura uma revenda

Regresse à aquisição hipotética que custa 1,207 ETH. Suponha que um comprador potencial separado oferece atualmente 1,30 pelo mesmo NFT elegível. Com uma dedução combinada inventada do vendedor de 6% e 0,005 ETH de custos de saída, as receitas líquidas de revenda seriam 1,217 ETH.

Se ambas as operações forem efetivamente concluídas nesses termos, o resultado modelado é um ganho de 0,010 ETH. A liquidação atómica da transação de compra pode assegurar a sua própria troca exigida, mas não conserva a oferta do comprador posterior enquanto o negociante obtém a propriedade e prepara a revenda.

Se a revenda disponível cair para 1,05 antes da segunda ação, os mesmos custos hipotéticos deixam 0,982 ETH de receitas líquidas. Sair aí perderia 0,225 ETH face à aquisição de 1,207. A primeira compra pode ter sido tecnicamente correta enquanto a sequência global se torna desfavorável.

Isto é risco de componentes sequenciais. Surge sempre que a estratégia depende de uma ação futura que não faz parte da mesma fronteira verificada de execução atómica. Software mais rápido pode reduzir algum tempo decorrido sem converter ações separadas numa garantia partilhada.

Uma explicação válida de arbitragem tem, portanto, de identificar a estrutura efetiva de execução suportada. Se a via não conseguir tornar condicionais em conjunto as componentes necessárias, o seu inventário intermédio e a perda possível merecem análise explícita. Chamar contratos inteligentes às componentes não remove essa exposição.

A simulação descreve um estado específico

Uma simulação de transação pode ajudar a identificar transferências esperadas e falhas de execução no estado usado para a simulação. É evidência valiosa, especialmente quando a ação proposta contém vários contratos ou destinatários. Continua a ser uma observação sobre um conjunto específico de condições.

A propriedade, os saldos, as autorizações de montante e a validade da ordem podem mudar antes da inclusão. Um anúncio que simulou com sucesso pode ser concretizado primeiro por outra pessoa. Uma operação sensível a taxas pode enfrentar outro ambiente de custos de rede quando é enviada. O resultado da simulação deve conservar o seu momento e pressupostos.

Use a simulação para comparar os efeitos propostos com a autorização do utilizador. O token pretendido chega ao destinatário pretendido? O pagamento esperado sai no ativo correto? Existem outras aprovações ou transferências que não faziam parte da decisão de investigação?

Não interprete uma simulação bem-sucedida como prova de que o ativo é autêntico, valioso ou tem probabilidade de valorizar. São perguntas diferentes. Uma coleção contrafeita pode conter uma transação tecnicamente executável, e uma ordem economicamente fraca pode simular perfeitamente.

Se uma via mudar após a simulação, repita a análise relevante. Reutilizar um resultado favorável de dados de chamada diferentes ou de outro destinatário testaria a instrução errada. O artefacto útil é uma ligação entre intenção aprovada, transação analisada e execução efetiva.

Uma falha pode ainda ter um custo

Uma execução revertida pode deixar por realizar as transferências pretendidas de ativos e ainda consumir recursos da rede. A documentação de gás da Ethereum explica que falhas de execução podem consumir gás. As tentativas falhadas pertencem, portanto, ao registo de negociação mesmo quando nenhum NFT é adquirido.

Distinga um pedido rejeitado antes de uma transação ser incluída de uma transação que executa e reverte. São estados diferentes com custos potencialmente diferentes. Um rótulo genérico de falha pode ocultar a distinção e tornar pouco fiáveis estimativas de despesas agregadas.

Num exemplo inventado, três tentativas falhadas que custam 0,004 ETH cada acrescentam 0,012 ETH às despesas da estratégia. Se uma operação posterior bem-sucedida ganhar 0,010 após os seus próprios custos, a sequência continua a perder 0,002 quando essas tentativas anteriores pertencem à mesma operação avaliada.

Uma repetição deve começar com evidência sobre a tentativa original. Um tempo limite de um serviço não prova que a rede nunca recebeu a transação. Conserve o identificador da transação e examine o seu estado antes de construir uma nova ação económica.

O guia do bot da Stream API da OpenSea explica como a entrega de eventos e a reconstrução do estado da conta interagem. Uma mensagem do fluxo pode ser evidência útil, mas o programa deve ainda reconciliar os efeitos efetivos da transação e da propriedade antes de finalizar o registo.

Confirmação e finalidade são níveis diferentes de evidência

Um hash de transação identifica uma tentativa. A inclusão num bloco fornece evidência de que a transação foi processada nesse bloco. O resultado da execução e os efeitos emitidos indicam depois o que efetivamente aconteceu. Confirmações adicionais ou finalidade alteram a confiança em que o histórico observado da rede persistirá.

A política adequada de confirmação depende da rede e da atividade realizada. Evite atribuir um número universal de segundos ou blocos a todos os fluxos de NFT. Uma apresentação que se atualiza depressa não define, por si só, o padrão de finalidade da aplicação.

A documentação de transações da Ethereum descreve o ciclo de vida desde uma transação assinada até ao processamento da rede. Uma ferramenta de conta deve tornar visível a etapa relevante em vez de usar um rótulo de sucesso para todos os pontos desse ciclo de vida.

Uma ação subsequente deve indicar que evidência exige. Uma notificação de investigação pode razoavelmente aparecer antes de uma transferência ser final, desde que identificada. Um relatório financeiro que afirma propriedade liquidada precisa de uma base mais forte e explicitamente definida.

Mantenha possíveis as correções nos registos locais. Se um efeito anteriormente observado deixar de fazer parte do histórico aceite da rede, a aplicação não deve conservá-lo silenciosamente como uma venda inquestionada. A reconstrução do estado exige mais do que recolher uma vez notificações de eventos.

Solana exige um modelo próprio de programas

Os exemplos EVM acima não descrevem todas as redes suportadas pela OpenSea. Solana usa um modelo diferente de contas e programas, e as representações de NFT podem diferir dentro desse ecossistema. Uma integração tem de verificar a norma efetiva do ativo e a via suportada.

Um identificador de mint Solana, uma conta de tokens e um proprietário têm funções diferentes. Os NFT comprimidos exigem considerações adicionais de representação em vez de serem forçados a um modelo EVM simples de contrato e ID do token. Uma ficha familiar do mercado não apaga essas distinções.

O suporte atual da OpenSea também separa anúncios Solana visíveis daqueles que podem ser comprados pelas suas vias suportadas. Um construtor de transações deve validar a elegibilidade em vez de tratar cada preço pedido apresentado como executável. Esta é uma questão de suporte do produto além de uma questão de estado na rede.

O guia de ganhar dinheiro a negociar NFT Solana liga essas distinções a custos e pressupostos de revenda. Os princípios financeiros comuns continuam a aplicar-se, mas as permissões, o financiamento e a validação das transações devem seguir a rede relevante.

O reporte entre redes pode usar um formato partilhado de registo mantendo evidência específica de cada rede. Os campos partilhados explicam o resultado económico; os campos específicos da rede explicam por que o registo é fiável. Remover os segundos por simplicidade visual enfraquece o histórico da conta.

Analise a troca concluída como um conjunto de efeitos

Após uma operação, identifique o ativo exato recebido ou entregue, os montantes dos tokens de pagamento, os destinatários, o custo de rede e as permissões restantes ou ordens ativas. Compare esses efeitos com a intenção aprovada. Um recibo de transação sem essa comparação pode ser tecnicamente detalhado mas financeiramente pouco informativo.

Na compra hipotética de 1,20 ETH, o registo deve explicar as componentes de pagamento de 1,128, 0,024 e 0,048 e o custo separado de rede de 0,007. Não deve contar tanto o total bruto como as mesmas transferências para destinatários como despesas separadas.

Num ativo com quantidade, verifique o saldo restante. Numa operação de vários itens, registe cada transferência efetiva. Numa ação falhada, conserve o custo e a autoridade por resolver que permanecem mesmo que o NFT esperado não tenha chegado.

O tutorial de negociação na OpenSea situa esta verificação num fluxo completo do utilizador. Compreender as fronteiras dos contratos inteligentes torna cada etapa mais deliberada: permissão, termos assinados, tentativa de execução e efeitos finais na conta estão relacionados, mas cada um exige a sua própria evidência.

Uma compreensão útil da negociação de NFT por contratos inteligentes termina com a capacidade de explicar essa cadeia de evidência em linguagem clara. O código pode impor os termos que recebe. O utilizador continua a precisar de saber que são os termos pretendidos e que o resultado financeiro concluído lhes corresponde.