Informe final — Lanzamiento de Baby SIMD (BSIMD)

Fecha: 2026-10-08 · Plantilla: Holders earn · Red objetivo: Ethereum mainnet Estado: contrato, tests, revisión de seguridad y script de despliegue terminados. No se ha desplegado.

1. Respuesta corta

Sí. src/BabySIMD.sol es un ERC-20 con nombre "Baby SIMD", símbolo "BSIMD", 1 000 000 000 tokens y 18 decimales. Redistribuye automáticamente a todos los holders el 3 % de cada compra hecha en el par BSIMD/WETH de Uniswap V2. No tiene owner ni ninguna función que cambie las reglas. No cobra fee en ventas ni en transferencias y no tiene límites. Todos los tests locales pasan. La revisión de seguridad es interna: no hubo ninguna auditoría profesional independiente (ver §5).

2. Requisitos y evidencia

#	Requisito	Cómo se cumple	Evidencia
1	1 000 000 000 tokens, 18 decimales	_T_TOTAL = 1_000_000_000 * 10**18, decimals = 18. No existen mint ni burn.	src/BabySIMD.sol; tests test_SupplyIsOneBillionWith18Decimals, test_SupplyConstantAfterActivity, invariant_SupplyConstant
2	El 3 % de las compras va automáticamente a todos los holders	Contabilidad de reflexión (RFI). Cuando los tokens salen del par, el comprador recibe el 97 % y el 3 % baja la rate, así que el saldo de cada holder sube en proporción a lo que tiene. No hay que reclamar nada ni pagar gas extra.	Tests test_BuyChargesThreePercent, test_BuyRedistributesToAllHoldersProportionally (ganancias en proporción 1:2:3 a los saldos), testFuzz_BuyFeeAndConservation, invariant_ReflectedMatchesThreePercentOfBuys, test_Fork_BuyReflectsThreePercent
3	Sin poderes de owner	No hay owner, roles, setters, pausa, blacklist ni proxy. pair es immutable.	ABI completa de forge inspect BabySIMD methodIdentifiers (listada en docs/AUDIT.md §3); test test_NoAdminFunctions
4	Sin fees ni límites en ventas o compras, aparte del 3 % de la plantilla	Ventas y transferencias: 0 %. Sin max-tx ni max-wallet.	Tests test_SellHasNoFee, test_WalletTransferHasNoFee, test_NoMaxTxOrWalletLimit (compra del 100 % del suministro), test_Fork_SellHasNoFee
5	Tests unitarios de redistribución y suministro	25 tests unitarios/fuzz, 4 invariantes y 5 tests en fork de mainnet	Ver §3
—	Compatible con ERC-20	Las 6 funciones y 2 eventos del estándar con firmas correctas, más errores ERC-6093	slither-check-erc: todo correcto. Solo señala la carrera de approve, que es inherente al estándar

3. Resultados de verificación (hechos, ejecutados localmente)

Verificación	Resultado
forge test --offline (Foundry 1.8.3, solc 0.8.26)	26 pasados, 0 fallidos, 1 suite omitida (fork sin RPC). Fuzz con 512 ejecuciones por test. Invariantes con 128 ejecuciones × 64 llamadas (8 192 llamadas de compra/venta/transferencia, 0 reverts).
forge test --match-contract Fork con MAINNET_RPC_URL=https://ethereum-rpc.publicnode.com (bloque ~26 148 263)	5/5 pasados contra el router real de Uniswap V2. Se comprobó lo siguiente: añadir liquidez no paga fee; una compra refleja exactamente el 3 % y sube el saldo de otro holder; una venta no paga fee; swapExactETHForTokens funciona; removeLiquidityETH revierte y la variante SupportingFeeOnTransferTokens funciona.
Slither 0.11.6 (102 detectores) sobre src/	2 resultados, los dos de estilo (complejidad de _transfer y el nombre WETH() de la interfaz de Uniswap). Ninguno de seguridad.
forge lint	Avisaba de un evento emitido tras llamadas externas en el constructor. Corregido reordenando el código y vuelto a probar.

Dirección del router Uniswap V2 en mainnet: 0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D; factory 0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f. Fuente: la tabla oficial de despliegues de Uniswap (https://developers.uniswap.org/docs/protocols/v2/deployments). También lo comprobé on-chain: factory() del router devuelve esa factory (eth_call, 2026-10-08).

Nota: los resultados anteriores son de mis propias ejecuciones. No tienen certificación independiente. Los tests de fork necesitan red y la verificación del encargo no la tiene, así que allí se omiten.

4. Decisiones de diseño (inferencias y elecciones mías, no especificadas en el encargo)

1. Qué cuenta como "compra": toda transferencia que sale del par BSIMD/WETH de Uniswap V2 hacia otra cuenta. Es la definición habitual en tokens de esta plantilla. Como no hay owner, el par se fija para siempre en el constructor.
2. El par no recibe recompensas. Si las recibiera, cualquiera podría sacar ese excedente con skim().
3. El comprador también participa en el 3 % de su propia compra, en proporción a su nuevo saldo (igual que en RFI clásico). Ejemplo verificado: si un comprador es el único holder, termina con el 100 %.
4. El constructor recibe la dirección del router en lugar de llevarla fija en el código. Así el mismo código se puede probar en testnet o en un fork. En mainnet hay que pasar la dirección oficial de §3.
5. Todo el suministro va a la cuenta que despliega. Quien despliega añade la liquidez (sin fee).

5. Limitaciones y riesgos (ver docs/AUDIT.md)

• No es una auditoría profesional. El encargo pide un contrato "auditado". Lo que se entrega es una revisión interna: lectura del código, Slither, fuzzing, invariantes y fork. Antes de desplegar con valor real se recomienda una auditoría externa.
• Retirar liquidez paga el 3 % porque es una salida del par. Hay que usar removeLiquidityETHSupportingFeeOnTransferTokens (verificado en fork).
• Los compradores necesitan un slippage ≥ 3 % en la interfaz del DEX.
• Solo un pool aplica la regla. Las compras en otros pools (p. ej. Uniswap V3) no pagan el 3 % y, como no hay owner, no se pueden registrar.
• La precisión se degrada a muy largo plazo. Es una estimación analítica, no una medición: los problemas de redondeo empezarían tras un volumen acumulado de compras de unas ~770 veces el suministro total. Aun así el código nunca bloquea una venta.
• Los indexadores no ven las recompensas como transferencias. Los saldos de los holders suben sin evento Transfer. Se emite Reflected(buyer, fee) para poder cuadrar las cuentas.

6. Preguntas abiertas para el solicitante

1. ¿Confirma que el lanzamiento será en Uniswap V2 (par con WETH)? Si prefiere otro DEX u otro par base (p. ej. USDC), hay que cambiar el constructor antes del despliegue.
2. ¿Quiere encargar una auditoría externa antes del lanzamiento?
3. ¿Cuánta liquidez inicial habrá y desde qué cuenta? Eso no forma parte del contrato, pero determina el precio inicial y el reparto.

7. Archivos entregados

src/BabySIMD.sol · test/BabySIMD.t.sol · test/BabySIMD.invariant.t.sol · test/fork/BabySIMD.fork.t.sol · test/mocks/MockUniswapV2.sol · script/Deploy.s.sol · docs/AUDIT.md · README.md · foundry.toml · lib/forge-std (v1.9.7, copiado como archivos normales para compilar sin red).