Question 1

¿Cómo se creó la emisión inicial de MIC y existe una vía de emisión posterior?

Accepted Answer

En el constructor se acuñaron una sola vez 1.000 millones de MIC para quien realizó el despliegue, con 18 decimales. Esta implementación de MIC no expone una función externa para acuñaciones posteriores; la acuñación inicial tampoco implica que todos esos tokens estuvieran ya en circulación.

Question 2

¿El “LP burn” del contrato MIC reduce el totalSupply?

Accepted Answer

El mecanismo transfiere MIC que posee el par objetivo a la dirección dead y después llama a sync para actualizar las reservas del par. Trata MIC dentro del pool, no participaciones LP; la función de transferencia invocada solo modifica ambos saldos y no reduce totalSupply, por lo que no equivale a una disminución del suministro total.

Question 3

¿La transferencia automática de MIC dentro del pool ocurre necesariamente cada dos horas?

Accepted Answer

No ocurre solo porque haya transcurrido el tiempo. Una transferencia debe entrar en un AMM marcado, el remitente no debe estar exento de comisiones, la función debe estar habilitada, debe haberse alcanzado el intervalo y no debe haber un intercambio interno para activar el proceso. El código fija inicialmente un intervalo de 7.200 segundos y una proporción del 0,25 % del saldo MIC del pool objetivo. Son parámetros iniciales, no una configuración actual ni una promesa de ejecución periódica.

Question 4

¿Qué límites tiene la transferencia manual de MIC dentro del pool?

Accepted Answer

Solo el owner puede invocar la función manual, y el momento de la llamada debe ser estrictamente posterior al último procesamiento manual más 30 minutos. La proporción por llamada no puede superar el 10 % del saldo MIC del pool objetivo; el MIC transferido va a la dirección dead y luego se sincronizan las reservas. Esta ruta usa un registro temporal distinto del activador automático.

Question 5

¿Cómo se componían las comisiones de compra y venta al desplegar MIC?

Accepted Answer

En el código, las comisiones iniciales totales de compra y venta son ambas del 25 %: 20 % para marketing, 5 % para liquidez y 0 % para desarrollo. Si cualquiera de las partes está exenta de comisiones, no se cobra esa comisión de compra o venta; el owner dispone de funciones para modificar comisiones, así que los valores iniciales no indican el cobro vigente.

Question 6

¿Una transferencia entre billeteras ordinarias de MIC también paga comisión de compra o venta?

Accepted Answer

Las transferencias entre billeteras ordinarias no pagan la comisión que el contrato aplica a compras y ventas en AMM, pero eso no garantiza que toda transferencia tenga éxito. Si el remitente o el destinatario está en la lista negra, la transferencia se revierte; también pueden impedirla comprobaciones aplicables como los límites de saldo de billetera.

Question 7

¿En qué se diferencian el límite por transacción y el límite de billetera de MIC?

Accepted Answer

El límite inicial por transacción es el 1 % del suministro, es decir, 10 millones de MIC; el límite de billetera es el 2 %, o 20 millones de MIC. Con los límites activos y direcciones pertinentes no exentas, una compra comprueba el importe de la operación y la suma del importe antes de comisión con el saldo anterior; una venta comprueba el importe de la operación, y una recepción ordinaria también puede quedar sujeta al límite de billetera. Estas comprobaciones también dependen de excepciones relacionadas con el owner y del estado de intercambio interno, entre otras condiciones; el owner puede desactivar los límites. Los valores iniciales no representan los límites actuales.

Question 8

¿Por qué pueden fallar recepciones consecutivas de MIC en el mismo bloque?

Accepted Answer

Cuando están activos tanto los límites generales como el retraso de transferencia y la operación entra en las comprobaciones correspondientes, el contrato registra el número de bloque por tx.origin; una segunda transferencia aplicable del mismo iniciador en un bloque falla. Hay excepciones, como cuando el destinatario es el owner, el router o el par principal, por lo que no significa simplemente que cada billetera solo pueda recibir una vez por bloque. El owner puede desactivar el retraso de transferencia; esta implementación no ofrece una función para volver a habilitarlo.

Question 9

Además de abrir la negociación de MIC, ¿qué cambia enableTrading?

Accepted Answer

Cuando el owner llama a enableTrading, se habilitan a la vez la negociación y el intercambio de comisiones, se fija el registro temporal del procesamiento automático del pool en el momento de la llamada y se registra el bloque de lanzamiento. Si la negociación no está habilitada y se aplican las comprobaciones de límites, al menos una parte de la transferencia debe estar exenta de comisiones o esta se revierte. Describe la lógica del contrato, no prueba que una activación se haya ejecutado.

Question 10

¿Cuándo entran las comisiones MIC acumuladas por el contrato en el procesamiento de intercambio?

Accepted Answer

Una vez que el MIC del contrato alcanza el umbral de intercambio, también deben estar habilitados los intercambios, no debe haber un intercambio interno, el remitente no debe ser un AMM marcado y ninguna parte de la transferencia debe estar exenta de comisiones para activar swapBack. Alcanzar el umbral por sí solo no basta; una transferencia entre billeteras que cumpla las condiciones también puede activarlo. Dentro de swapBack, la función retorna directamente si el saldo del contrato o la suma de contadores de distribución de comisiones es cero.

Question 11

Cuando el mecanismo de comisiones añade liquidez, ¿quién recibe las nuevas participaciones LP?

Accepted Answer

El procesamiento de comisiones solo llama a la función para añadir liquidez cuando tanto el MIC reservado como el ETH asignado a liquidez son mayores que cero. La función añade MIC y ETH al pool y fija deadAddress como receptor de las nuevas participaciones LP; este proceso no distribuye participaciones LP a cada titular de MIC.

Question 12

Después de desactivar los límites de negociación, ¿también se detiene la comprobación de lista negra?

Accepted Answer

No. removeLimits solo desactiva la rama de límites controlada por limitsInEffect; la comprobación de lista negra está fuera de esa rama. Mientras alguna de las partes de una transferencia siga marcada en la lista negra, la transferencia se revierte; el contrato tiene una función exclusiva del owner para establecer o quitar esa marca.

Precio de Magic Internet Cash (MIC)