Um bot de ofertas de NFT pode manter licitações sobre itens específicos, grupos de características e coleções inteiras. Estas ofertas podem sobrepor-se: um token pode satisfazer os três âmbitos. O desafio contabilístico é determinar quantos ativos o bot poderia adquirir e quanto poderia gastar se vendedores diferentes aceitassem as suas ordens independentemente válidas. Elegibilidade sobreposta não cria automaticamente um único limite partilhado de aquisição.
Isto importa porque cada oferta pode parecer razoável isoladamente. Um colecionador pode aprovar um item especial a um preço, uma característica preferida a outro e qualquer item aceitável da coleção a um preço inferior. Juntas, essas decisões podem criar mais exposição do que o colecionador pretendia. O saldo da carteira, por si só, não explica as obrigações combinadas da estratégia ou as consequências de mudanças futuras de financiamento.
Este guia modela ofertas de itens, características e coleções usando uma coleção Ethereum fictícia chamada Garden Registers. Os exemplos usam preços hipotéticos em WETH e ordens independentes de aceitação única, salvo indicação em contrário. O comportamento efetivo das ofertas tem de ser verificado para a cadeia, protocolo e rota relevantes; o objetivo é tornar compreensível a exposição combinada antes de um bot criar mais ordens.
Mapeie a exposição do bot de ofertas de NFT antes de atribuir preços
Crie um registo para cada ordem independente. Registe o identificador, ativos elegíveis, token de pagamento, montante, quantidade ou capacidade restante de aceitação, expiração, requisitos de financiamento e estado atual. Um agrupamento da interface pode conter várias ofertas aceitáveis independentemente, pelo que o próprio agrupamento não deve ser a unidade de contabilização da exposição.
Uma oferta de item visa um token específico. Uma oferta de característica visa um conjunto definido de tokens que se qualificam, e uma oferta de coleção visa a população permitida da coleção segundo as suas condições. Estes conjuntos podem intersectar-se, mas as identidades das ordens e as capacidades de aceitação continuam separadas, salvo se o mecanismo de execução as ligar explicitamente.
O guia atual de ofertas de coleção da OpenSea descreve uma oferta de coleção que pode ser aceite uma vez, enquanto aumentar a quantidade cria várias ofertas que podem ser aceites separadamente. O mesmo guia descreve filtragem por características para coleções suportadas. Leia a estrutura efetiva das ordens, em vez de traduzir uma quantidade apresentada numa regra universal não sustentada.
A elegibilidade também pode depender de quando a ordem foi construída. Se os metadados das características mudarem mais tarde, os ativos abrangidos por uma ordem existente podem não corresponder a um filtro visual recentemente atualizado. Mantenha os critérios associados à própria ordem. A opinião atual do bot sobre a coleção não deve reescrever silenciosamente o que já autorizou.
Percorra três ofertas sobrepostas
Suponha que Garden Registers contém o token R com capa azul, o token S com capa azul e o token T com capa verde. O bot cria uma oferta de item de 0,60 WETH para R, uma oferta de característica de capa azul de 0,50 WETH e uma oferta de coleção de 0,40 WETH. Cada uma é independentemente válida e pode ser aceite uma vez segundo os pressupostos deste exemplo.
O token R qualifica-se para os três âmbitos, enquanto S se qualifica para as ofertas de característica e coleção e T apenas para a oferta de coleção. Seria errado contar todo o conjunto como uma oferta apenas porque R aparece em todos os grupos de elegibilidade. Três vendedores diferentes poderiam entregar R na oferta de item, S na oferta de característica e T na oferta de coleção.
Essa sequência viável de aceitação gasta 1,50 WETH e adquire três NFT. Se o colecionador pretendia um compromisso máximo de novas ofertas de 1,20 WETH, o plano excede-o em 0,30 WETH antes de quaisquer despesas adicionais. Uma carteira com 1,80 WETH seria capaz de financiar os montantes das três ofertas neste exemplo simplificado, mas esse saldo não se sobrepõe ao limite inferior da política.
A relação entre conjuntos ajuda a explicar possíveis execuções, mas não cria uma regra de cancelamento. A aceitação da oferta de item não cancela automaticamente a oferta de característica ou coleção sem relação apenas porque poderiam ter aceite o mesmo token. O bot tem de acompanhar o que cada ordem efetiva faz quando uma é executada.
Distinga elegibilidade partilhada de exclusão mútua
Um NFT único não pode ser entregue simultaneamente a vários compradores na mesma transferência simples. Essa limitação física não significa que todas as ofertas que o abrangem sejam permanentemente mutuamente exclusivas. Outros tokens elegíveis podem satisfazer as ordens restantes, e transferências futuras podem mudar que ativos estão disponíveis a que vendedores.
Dependa de um limite partilhado apenas quando o mecanismo relevante efetivamente o faz cumprir. Uma nota local a dizer comprar um deste grupo não é o mesmo que uma condição na cadeia ou ao nível do protocolo que impeça ordens aceites adicionais. Se o bot criar várias ordens independentes e planear cancelar as outras após a primeira execução, aceitou uma corrida entre reconhecimento, cancelamento e cumprimentos adicionais.
Para planeamento conservador, some compromissos independentemente executáveis, salvo se existir uma razão verificada para ser possível impor um limite inferior. Uma análise mais elaborada da elegibilidade pode ajudar a explicar cenários, mas não deve reduzir reservas apenas com base no comportamento desejado de vendedores ou na velocidade esperada de cancelamento.
O propósito não é prever que vendedor agirá primeiro. É compreender o que o bot permitiu que acontecesse. Uma política que continua financeiramente comportável em várias sequências plausíveis de aceitação é mais robusta do que uma que funciona apenas se os vendedores chegarem na ordem preferida pelo operador.
Crie o orçamento de ofertas sobrepostas de NFT
O orçamento deve ligar ofertas abertas a posições existentes e outras aquisições pendentes. Um limite de coleção pode restringir nova despesa mesmo quando a carteira tem fundos abundantes. Um limite de carteira de investimento pode restringir várias coleções que partilham o mesmo saldo de pagamento. Mantenha estes limites visíveis como testes separados da mesma ação proposta.
Suponha que as três ofertas Garden Registers totalizam 1,50 WETH, o inventário existente da coleção tem uma base de custo de aquisição de 0,20 WETH e o colecionador reserva 0,05 equivalentes de WETH para despesas operacionais relevantes. Com um limite de campanha deliberadamente simples de 2,00 equivalentes de WETH, a utilização planeada é 1,75 e a capacidade restante é 0,25. Uma nova oferta independente de 0,30 WETH excederia esse limite em 0,05.
O cálculo de unidades equivalentes é um resumo da política, não uma alegação de que gas nativo e WETH são o mesmo token gastável. Saldos e permissões efetivos ainda precisam de verificações específicas de cada moeda. Um sistema pode ter margem sob um limite contabilístico combinado e não ter o token nativo necessário para uma ação na cadeia.
Reserve capacidade antes de publicar a nova ordem. Vários processos não devem ler cada um o mesmo montante restante permitido e comprometê-lo independentemente. O registo de ofertas precisa de uma atualização coordenada que registe a reserva e a intenção associada, para que estratégias concorrentes de coleções não possam gastar cada uma dinheiro já prometido noutro local.
Mantenha o estado de financiamento separado da intenção da ordem
Para ofertas orientadas para Ethereum com WETH detido na carteira, o saldo pode permanecer na carteira até um vendedor aceitar. Isso pode fazer o dinheiro parecer disponível para outra finalidade, mesmo que o bot tenha criado várias utilizações potenciais para ele. O registo interno de compromissos deve refletir as ordens que poderiam tornar-se executáveis nas condições planeadas de financiamento.
O guia de ofertas de coleção da OpenSea também descreve ofertas sem financiamento que voltam a ficar ativas quando regressam fundos suficientes. Remover fundos temporariamente não é, por isso, equivalente a cancelar todas as ordens pendentes. Um depósito posterior destinado a uma nova estratégia pode reativar compromissos antigos se as ofertas subjacentes continuarem eficazes.
Antes de acrescentar fundos, analise ordens ativas, sem financiamento e por resolver. Determine se o novo saldo permitiria aquisições já não desejadas. Um reforço é uma mudança da capacidade de execução do sistema, pelo que merece a mesma atenção que aumentar um orçamento de estratégia, mesmo que não seja criada uma nova ordem nesse momento.
A Solana usa mecanismos diferentes. O guia de ofertas Solana da OpenSea descreve fundos retidos na cadeia com uma oferta e atualmente nenhuma oferta de características. Não importe o modelo de financiamento detido na carteira de Ethereum ou o exemplo de três âmbitos para essa rota sem adaptação. Categorias comuns de relato podem coexistir com regras de compromisso específicas de cadeias.
Trate substituições como ordens potencialmente sobrepostas
Uma atualização de preço pode criar uma nova ordem enquanto a antiga ainda pode executar, dependendo do mecanismo. O bot deve saber se a rota substitui, cancela ou acrescenta independentemente uma ordem. Uma nova linha na apresentação local não estabelece o que aconteceu à autorização anterior.
Suponha que uma oferta existente de característica de 0,50 WETH é seguida de uma nova oferta de 0,52 WETH. Se ambas continuarem independentemente válidas durante uma transição, o compromisso combinado é 1,02 WETH, não apenas o aumento de preço de 0,02 WETH. Reservar apenas a diferença presume uma garantia de substituição que pode não existir.
Quando a oferta antiga for conclusivamente ineficaz, a sua reserva pode ser libertada. Até lá, preserve o seu identificador e estado. Um pedido falhado de cancelamento ou uma resposta incerta não devem fazer a ordem antiga desaparecer da contabilização apenas porque a interface agora destaca o novo preço.
Um licitador automatizado da OpenSea também precisa de uma regra de avaliação que impeça escalada interminável de preços. A contabilização de substituições e a disciplina de preços resolvem problemas diferentes: uma limita compromissos simultâneos, enquanto a outra limita o que o bot está disposto a pagar por cada aquisição individual.
Compreenda o cancelamento como um processo
Um pedido de cancelamento é uma ação destinada a alterar a eficácia de uma ordem. O seu resultado depende do protocolo e da rota. O bot deve registar que mecanismo foi usado, quando foi pedido, que provas confirmam o resultado e se uma autorização anterior de cumprimento ainda pode importar.
A referência de cancelamento fora da cadeia da OpenSea qualifica explicitamente a sua garantia quando foi emitida uma assinatura de cumprimento antes do cancelamento. A lição prática é evitar tratar todas as confirmações da API como prova incondicional de que não pode ocorrer qualquer aceitação adicional. Mantenha visível a incerteza relevante até as condições da rota estarem resolvidas.
Parar o bot não para necessariamente as ordens existentes. Um processo pode deixar de publicar enquanto as suas ofertas anteriormente assinadas continuam ativas. Um procedimento completo de pausa deve inventariar compromissos pendentes e aplicar a política autorizada de cancelamento ou expiração. O relatório deve distinguir criação de novas ordens desativada de todas as ordens anteriores resolvidas.
A expiração também exige interpretação cuidada. Uma ordem expirada pode já não ser executável, mas fundos relacionados ou estado da interface podem atualizar-se segundo o seu próprio calendário, dependendo da cadeia. Registe as condições efetivas da ordem e as provas usadas para libertar recursos, em vez de depender apenas de uma contagem decrescente local.
Concilie cada aceitação no inventário
Quando um vendedor aceita uma oferta, o bot precisa de identificar o ativo adquirido, a quantidade, os fluxos de pagamento e o resultado da transação. Uma notificação que menciona a coleção não basta para estabelecer que token chegou ou que ordem específica foi consumida. Ligue a aceitação ao identificador da ordem e ao registo relevante de inventário.
A reserva da oferta torna-se uma aquisição, em vez de simplesmente desaparecer. Se a estratégia contar inventário detido sob um limite de campanha, uma execução pode deixar a exposição total comprometida aproximadamente semelhante enquanto muda a sua forma. Um bot que liberta todo o montante da oferta como nova capacidade após cada execução pode continuar a acumular inventário além do limite pretendido.
As despesas efetivas devem ser conciliadas segundo a política contabilística escolhida. Algumas podem ser atribuídas ao ativo adquirido, enquanto ações sem sucesso ou administrativas podem pertencer às despesas da campanha. O método deve ser coerente e nunca fazer a mesma comissão ser contada duas vezes ou omitida porque chegou através de outro serviço.
Se a aceitação continuar incerta, retenha um estado de aquisição pendente e evite reutilizar a sua capacidade. Investigue a transação e o registo de propriedade antes de publicar ofertas de substituição. A decisão seguinte deve seguir o estado conciliado, não a ausência de uma mensagem de sucesso na memória de um processo.
Gira o risco de seleção dentro de ofertas abrangentes
Uma oferta abrangente permite aos vendedores escolher que ativo elegível entregar. O inventário resultante pode concentrar-se nos itens menos desejáveis que satisfazem os critérios. Um preço médio de venda ao nível da coleção não garante que os ativos adquiridos através de ofertas abrangentes se assemelhem aos itens responsáveis por essa média.
Filtros de características podem restringir o conjunto sem eliminar este efeito de seleção. Tokens que partilham um atributo podem diferir noutras características, interesse visual, proveniência ou restrições de transferência. Atribua preço à oferta face a todo o conjunto aceitável, incluindo os itens mais fracos que os critérios permitem. Se esses itens forem inaceitáveis, mude os critérios ou não crie a oferta.
O raciocínio de inventário num bot criador de mercado de NFT é útil aqui. Uma política de aquisição deve considerar o que o bot já detém e como outro item semelhante muda a concentração. Continuar a publicar uma oferta abrangente após várias execuções comparáveis pode criar uma posição maior do que o colecionador teria escolhido item a item.
Analise as execuções efetivas face à tese pretendida de seleção. Se os vendedores entregarem consistentemente tokens com fraca procura para revenda, isso é prova sobre a conceção da oferta, não simplesmente azar a excluir do relatório. O bot deve aprender se os seus critérios expressam com proximidade suficiente as preferências reais do colecionador.
Coordene ofertas entre estratégias e carteiras
Um colecionador pode executar uma estratégia de seleção de itens e uma estratégia de licitação de coleções ao mesmo tempo. Se partilharem uma carteira, também partilham saldos, aprovações e capacidade de inventário. Os seus painéis individuais podem parecer financeiramente comportáveis enquanto o plano combinado não é. Um registo comum de compromissos torna visível essa interação.
Carteiras separadas podem reduzir algum acoplamento operacional, mas não diversificam automaticamente a exposição económica. Duas carteiras que licitam na mesma coleção continuam a expor o proprietário à mesma procura da coleção. Uma análise ao nível da carteira de investimento deve agregar as posições mesmo quando a autoridade de transação está dividida.
Evite contar transferências entre essas carteiras como nova procura de mercado ou saídas realizadas. Mover um NFT adquirido para uma carteira de armazenamento muda o local de custódia, não o facto económico de o colecionador ainda o deter. A estratégia de ofertas deve continuar a incluir o ativo em qualquer limite relevante de concentração.
O guia prático de automatizar licitações na OpenSea pode ajudar a ligar a gestão de ordens a esta coordenação mais ampla. A escolha importante de conceção é dar a todas as estratégias uma visão coerente das obrigações que podem afetar a próxima compra autorizada.
Teste um bot de ofertas de NFT com sequências de aceitação
Teste várias sequências possíveis, em vez de uma ordem ideal de eventos. Em Garden Registers, faça a oferta de item executar primeiro num caso, a oferta de característica primeiro noutro e a oferta de coleção primeiro num terceiro. Confirme que cada resultado consome a capacidade adequada da ordem e deixa corretamente representadas as obrigações restantes.
Inclua uma substituição cuja ordem antiga continua por resolver, uma oferta sem financiamento que passa a financiada após um depósito e um reinício após aceitação, mas antes de o inventário local ser guardado. Estes casos testam se o bot preserva compromissos durante transições. Uma demonstração bem-sucedida que começa sem estado anterior não os cobre.
Verifique fronteiras orçamentais com pequenas diferenças. Uma proposta que exceda o montante restante permitido em 0,01 WETH deve falhar com tanta clareza como um excesso muito maior. O tratamento exato dos montantes importa porque arredondar os valores apresentados pode, caso contrário, fazer um compromisso inválido parecer igual ao limite.
Por fim, compare o inventário e os saldos finais do teste com o histórico de ordens. Cada aquisição deve corresponder a um compromisso válido consumido, e cada reserva libertada deve ter uma razão baseada em provas. Se o total não puder ser conciliado, não esconda a diferença num ajuste diverso que equilibre o relatório sem explicar o comportamento.
Mantenha a quantidade separada do número de linhas
Uma interface de relatórios pode mostrar uma linha para uma ordem que representa várias unidades ou várias linhas que descrevem cópias da mesma observação. Nenhuma contagem de linhas é, por si só, uma contagem fiável de aquisições. Guarde explicitamente a capacidade restante da ordem e a semântica de quantidade do ativo e derive depois o relatório desses campos.
Para ativos de edições, distinga o número de unidades do número de identificadores únicos. Adquirir quatro unidades de um identificador cria concentração diferente de adquirir quatro tokens únicos, mesmo que o preço total seja igual. A campanha pode definir tanto um limite de despesa como um limite de unidades quando essa distinção importa para o seu propósito.
A conclusão parcial precisa da mesma precisão. Se uma ordem suportada puder executar por partes, concilie as unidades efetivamente adquiridas e a capacidade que resta nessa ordem específica. Não aplique um exemplo de aceitação única a todas as ordens de protocolos apenas porque o mercado as apresenta no mesmo separador de ofertas.
Analise todo o conjunto de ofertas
Um relatório útil de ofertas começa pelo total de aquisições potenciais, montantes comprometidos por moeda, inventário existente e transições por resolver. Pode depois decompor esses totais nos âmbitos de item, característica e coleção. Começar pelo agregado impede o leitor de confundir três ordens individualmente modestas com uma posição global modesta.
Analise mudanças de elegibilidade e procura, além do estado das ordens. Um evento de toda a coleção pode tornar pouco atrativas várias ofertas sobrepostas ao mesmo tempo. Uma mudança de metadados pode afetar os pressupostos do preço de uma característica. O bot deve ter uma forma de parar de acrescentar exposição enquanto o operador reavalia o conjunto.
A política de ofertas mais forte descreve o que pode acontecer se os vendedores agirem de forma independente e rápida. Não depende de notar a primeira execução a tempo de impedir todas as outras. Um bot de ofertas de NFT torna-se mais previsível quando os âmbitos sobrepostos são mapeados explicitamente, os compromissos partilham um orçamento e as ordens aceites se tornam inventário visível em vez de desaparecerem da vista.