Question 1

Como surgiu a emissão inicial de MIC e há uma função para emitir mais tokens?

Accepted Answer

No construtor, 1 bilhão de MIC foi cunhado de uma só vez para quem chamou a implantação, e o token usa 18 casas decimais. Esta implementação de MIC não expõe uma função externa de emissão posterior; a cunhagem inicial também não significa que todos esses tokens tenham entrado em circulação naquele momento.

Question 2

O “LP burn” do contrato MIC reduz o totalSupply?

Accepted Answer

O mecanismo transfere o MIC detido pelo par-alvo para o endereço dead e então chama sync para sincronizar as reservas do pool. Ele trata MIC no pool, e não cotas de LP; a transferência usada só altera os saldos das duas partes e não reduz totalSupply. Portanto, essa operação não equivale a uma queda do fornecimento total.

Question 3

A transferência automática de MIC no pool ocorre necessariamente a cada duas horas?

Accepted Answer

Não ocorre somente porque o tempo passou. Uma transferência precisa ir para um AMM marcado, o remetente não pode ser isento de taxas, a função precisa estar habilitada, o intervalo precisa ter decorrido e não pode haver swap interno para que o processamento seja acionado. O código define inicialmente 7.200 segundos e 0,25% do saldo de MIC no pool-alvo. São configurações iniciais, não parâmetros atuais nem uma promessa de execução em intervalos fixos.

Question 4

Quais limites se aplicam à transferência manual de MIC no pool?

Accepted Answer

Somente o owner pode chamar a função manual, e a chamada deve ocorrer estritamente depois do último processamento manual mais 30 minutos. A proporção por chamada é limitada a 10% do saldo de MIC no pool-alvo; o MIC transferido vai para o endereço dead e as reservas são sincronizadas depois. Esse caminho usa um registro de tempo diferente do acionamento automático.

Question 5

Como eram compostas as taxas de compra e venda na implantação de MIC?

Accepted Answer

No código, as taxas iniciais totais de compra e venda são ambas 25%: 20% para marketing, 5% para liquidez e 0% para desenvolvimento. Se uma das partes for isenta de taxas, essa taxa de compra ou venda não é cobrada. O owner tem funções para ajustar taxas, portanto os valores iniciais da implantação não representam necessariamente a cobrança atual.

Question 6

Transferências entre carteiras comuns de MIC pagam taxa de compra ou venda?

Accepted Answer

Transferências entre carteiras comuns não pagam a taxa que o contrato aplica a compras e vendas em AMM, mas isso não garante que toda transferência terá sucesso. Se o remetente ou destinatário estiver na lista de bloqueio, a transferência reverte; verificações aplicáveis, como o limite de saldo da carteira, também podem impedi-la.

Question 7

Qual é a diferença entre o limite por transação e o limite de carteira de MIC?

Accepted Answer

O código define inicialmente um máximo por transação de 1% do fornecimento, ou 10 milhões de MIC, e um máximo por carteira de 2%, ou 20 milhões de MIC. Com os limites ativos e sem isenção, compras verificam a quantidade da transação e a soma da quantidade antes da taxa com o saldo existente; vendas verificam a quantidade, e recebimentos comuns também podem estar sujeitos ao máximo de carteira. Essas verificações dependem ainda de exceções ligadas ao owner, do estado de swap interno e de outras condições; o owner também pode desativar os limites. Os números iniciais não representam limites atuais.

Question 8

Por que receber MIC repetidamente no mesmo bloco pode falhar?

Accepted Answer

Quando os limites gerais e o atraso de transferência estão ativos e a operação entra no escopo das verificações, o contrato registra o número do bloco por tx.origin. Uma nova transferência aplicável pelo mesmo originador no mesmo bloco falha. Há exceções para destinatários como owner, roteador ou par principal, então isso não significa simplesmente que cada carteira só pode receber uma vez por bloco. O owner pode desativar o atraso de transferência; esta implementação não fornece uma função para reativá-lo.

Question 9

O que mais muda quando enableTrading ativa a negociação de MIC?

Accepted Answer

Quando o owner chama enableTrading, a negociação e o mecanismo de troca de taxas são ativados, o registro de tempo do processamento automático do pool recebe o instante da chamada e o bloco de lançamento é registrado. Se a negociação não estiver ativa e as verificações de limite se aplicarem, pelo menos uma parte da transferência precisa ser isenta de taxas, caso contrário ela reverte. Isso descreve a lógica do contrato, não prova que uma chamada tenha sido executada.

Question 10

Quando as taxas de MIC acumuladas pelo contrato entram em processamento de troca?

Accepted Answer

Após o saldo de MIC do contrato atingir o limiar de troca, ainda é necessário que a troca esteja habilitada, que não haja swap interno, que o remetente não seja um AMM marcado e que as duas partes não sejam isentas de taxas para acionar swapBack. Assim, atingir o limiar não basta; uma transferência de carteira que cumpra as condições também pode disparar o processamento. Dentro de swapBack, a função retorna imediatamente se o saldo do contrato ou a soma dos contadores de alocação de taxas for zero.

Question 11

Quem recebe as novas cotas de LP quando o mecanismo de taxas adiciona liquidez?

Accepted Answer

O processamento de taxas só chama a função de adição de liquidez quando o MIC reservado e o ETH destinado à liquidez são ambos maiores que zero. A função adiciona MIC e ETH ao pool e define deadAddress como destinatário das novas cotas de LP; esse fluxo não distribui cotas de LP a cada detentor de MIC.

Question 12

Ao desativar os limites de negociação, a verificação da lista de bloqueio também para?

Accepted Answer

Não. removeLimits desativa somente o ramo de restrições controlado por limitsInEffect; a verificação da lista de bloqueio fica fora desse ramo. Enquanto uma das partes da transferência estiver marcada, ela reverte. O contrato tem ainda uma função exclusiva do owner para marcar ou desmarcar um endereço.

Preço de Magic Internet Cash (MIC)