Preço de BullBear AI (AIBB)

O construtor cunhou 10^17 AIBB de uma só vez e creditou-os ao implementador. O contrato usa 18 casas decimais: cada AIBB corresponde a 10^18 unidades-base, pelo que a emissão inicial corresponde a 10^35 unidades-base. Trata-se da emissão inicial na implementação, não da oferta circulante atual.

Só o owner pode chamar launch, e apenas quando o contrato ainda não foi ativado. A chamada regista o número do bloco e o carimbo temporal, permitindo que remetentes sem autorização pré-lançamento ultrapassem a verificação de ativação; continuam a aplicar-se requisitos como saldo suficiente. O interruptor descreve transferências do token, não o estado de lançamento de um produto de IA.

A restrição anterior ao lançamento verifica o remetente. Se o remetente constar de canAddLiquidityBeforeLaunch, ignora a exigência de o contrato já estar ativado; o facto de só o destinatário constar não permite a um remetente comum passar. Apesar do nome da variável, a verificação é usada no percurso de transferência do token. O construtor inclui o implementador e o próprio contrato nessa lista, e o owner pode acrescentar outros endereços. A lista branca só dispensa a verificação de ativação; a transferência continua a exigir, por exemplo, saldo suficiente.

O owner pode registar um par inicial uma única vez com initializePair e depois adicionar ou remover endereços não nulos com addPair e delPair. O registo é um conjunto interno de endereços e não prova que exista um pool ativo. Apesar do nome, getMinterLength devolve o número de pares, não o número de endereços autorizados a cunhar.

O contrato verifica primeiro o remetente: se for um par registado, trata a operação como compra. Caso contrário, se o destinatário for um par registado, trata-a como venda. Se ambos forem pares, a verificação do remetente tem prioridade; se nenhum for par, a transferência comum não entra neste ramo de taxas. A classificação não implica por si só uma taxa: o contrato tem de estar ativado e nem remetente nem destinatário pode estar isento.

Não. Quando o contrato está ativado, ambas as partes não estão isentas e intervém um par registado, cobra-se o montante de tesouraria mais o montante de queima da direção aplicável. São quantidades fixas em unidades-base, não uma percentagem do valor transferido; 10^18 unidades-base correspondem a 1 AIBB. Quantidade recebida = quantidade transferida − montante de tesouraria da direção − montante de queima da direção. O owner pode ajustar separadamente ambos os montantes de compra e de venda; «fixos» descreve o método de cálculo, não valores imutáveis. A fórmula do montante líquido aplica-se apenas a uma transferência bem-sucedida. Se o total das taxas aplicáveis exceder a quantidade transferida, a subtração causa um underflow e toda a transação é revertida. Assim, um aumento das taxas pelo owner pode fazer falhar uma transferência antes possível; isto não confirma as taxas atuais.

Numa transferência com taxa, com o contrato ativado, sem isenções e envolvendo um par registado, a parte de tesouraria sai do remetente para treasureWallet e continua a ser uma transferência. A parte de queima é destruída do saldo do remetente e reduz totalSupply. Os montantes dependem da direção de compra ou venda; o owner define o destinatário da tesouraria, e este mecanismo não concede dividendos da tesouraria aos titulares.

Não. isFeeExempt guarda a isenção, que o owner pode definir ou revogar; se remetente ou destinatário estiver isento, o ramo de taxas de compra/venda não é aplicado. A autorização pré-lançamento usa uma lista diferente e verifica apenas o remetente. A isenção de taxa não substitui a autorização de envio pré-lançamento.

transferFrom primeiro verifica e consome a autorização dada pelo remetente ao chamador e só depois transfere. Uma autorização finita diminui pelo montante total solicitado, não pelo líquido recebido após taxas; se for insuficiente, falha. Uma autorização igual ao máximo de uint256 é infinita e não diminui ao ser usada. A autorização não elimina as restrições de envio pré-lançamento. Após a ativação, se nenhuma parte estiver isenta e houver um par registado, aplicam-se também as taxas da direção pertinente.

burn destrói do saldo do próprio chamador a quantidade indicada de AIBB e exige saldo suficiente. Com êxito, o saldo dessa conta e totalSupply diminuem na mesma quantidade. Não há devolução de outro ativo ao chamador, pelo que não é um resgate de outro ativo por AIBB.

Não. burnFrom exige primeiro autorização da conta-alvo ao chamador e saldo suficiente na conta-alvo. A autorização finita diminui pela quantidade queimada; a autorização infinita no máximo de uint256 não diminui. Uma queima bem-sucedida reduz tanto o saldo alvo como a oferta total; conhecer um endereço não basta para destruir os seus ativos.

rescueToken só pode ser chamado pelo owner e transfere para o chamador todo o saldo do ERC-20 especificado mantido no endereço do contrato AIBB. clearStuckEthBalance permite ao owner retirar o saldo de ETH do contrato. As funções referem-se a ativos do próprio contrato, não aos saldos de titulares arbitrários.