# 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 (). 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).