Emite exactamente 300.000.000 BTOWN una sola vez a un destinatario del constructor
Sin emisión adicional, propietario, bloqueo de transferencias ni pausa del contrato
Las constantes de asignación no crean once saldos separados
BATTLE TOWN
Oferta, asignación y vesting de BTOWN
Consulta los 300M BTOWN, once asignaciones y calendarios de vesting. Distingue la asignación prevista de la custodia contractual.
Navegación
Distribución de 300M BTOWN
El whitepaper v3.4 fija una emisión única de 300.000.000 BTOWN en el constructor y once constantes de asignación. La liquidez es 10 M iniciales más 20 M de reserva. La mayoría son referencias numéricas, no controles contractuales de custodia.
Tres calendarios contractuales terminan en los meses 10, 16 y 22. Los torneos oficiales se crean con al menos 60 días de separación, sin garantía trimestral. Las partes del ganador y jugadores aleatorios se transfieren completas al liquidar, sin tercios mensuales. Las comisiones comunitarias se reparten nominalmente en 95% al ganador, 1,5% a la época NFT y 3,5% a Treasury, según redondeos enteros y condiciones de apertura de época.
Las constantes Solidity solo dividen la liquidez en 10.000.000 BTOWN iniciales y 20.000.000 de reserva. Ningún contrato de este código aporta liquidez, bloquea esos saldos ni impone un calendario, reparto DEX/CEX, reserva para creación de mercado o fórmula basada en recaudación.
Las asignaciones son referencias numéricas, no un mapa completo de custodia. El constructor Token emite los 300 M una vez a un destinatario; Vesting limita TEAM y el despliegue de referencia financia RewardsVault con 80 M. Los contratos no imponen un presupuesto de ingresos de preventa. La finalización envía a RewardsVault el inventario no vendido por encima de las obligaciones bloqueadas.
Whitepaper oficial (PDF)Un núcleo de contratos inteligentes
El whitepaper v3.4 corresponde al código inmutable SHA-256 7990a8a2f26d289ef24a28b7aabfae624ab5bdd6e8ef1ca146e118a68f027143. El catálogo incluye Presale desplegable. El despliegue mainnet (chain ID 56) se publica por separado abajo; el whitepaper sigue siendo la referencia inmutable del código. El panel de preventa lee el estado actual de la venta desde el contrato.
BNB Smart Chain · Mainnet · Chain ID 56
Seguridad
El código usa primitivas de propiedad y reentrada de OpenZeppelin. No incluye pausa de emergencia, proxy, ruta de actualización ni requisito multisig en cadena.
Consulta el informe PDF y su alcance en Seguridad. El informe revisa el código fuente; el bytecode desplegado y la configuración en producción quedan fuera de su alcance. Las direcciones actuales de los contratos aparecen en la página de preventa.