Seguridad y custodia

Custodia y transparencia de fondos

Los fondos del proyecto se custodian aplicando los más altos estándares de seguridad del ecosistema Solana, y se rigen por un principio innegociable: todo es verificable on-chain. La confianza no se pide — se demuestra.

Cinco carteras, cinco funciones

Los fondos no se guardan en una sola cartera. Se reparten en cinco carteras multifirma —cada una con sus propios firmantes y su propio umbral— siguiendo un principio simple: quien custodia los tokens no es quien opera los contratos, y el compromiso de una cartera no expone a las demás.

El fundador y Vlad no tienen cartera multifirma propia: reciben cada uno su stream de vesting en su propia wallet. Las direcciones de las carteras en mainnet se publicarán cuando existan.

Las carteras que guardan los grandes volúmenes exigen 3 firmas de 5: aunque se comprometieran dos claves, los fondos seguirían a salvo. Las de uso frecuente usan 2 de 3, para no bloquear la operativa del día a día.

La dirección que administra los contratos queda grabada en el propio programa al compilarlo, no es un parámetro que se cambie después. Fijar en ella la cartera de administración operativa es por tanto un paso obligatorio previo al despliegue en mainnet, y sustituirla más adelante exigiría desplegar los contratos de nuevo.

Cómo se firma

Todos los firmantes de las cinco carteras custodian su clave en una hardware wallet. No es una recomendación interna: es la condición para ser firmante, y rige igual para el representante de la comunidad que para el fundador.

Las carteras se crean sin retardo de ejecución: reunidas las firmas del umbral, la operación se ejecuta. Squads permite configurar ese retardo, pero no condicionarlo al importe, así que aplicarlo significaría frenar por igual repartir el supply y pagar a un proveedor — y, en las carteras que guardan los grandes volúmenes, convertir la respuesta a un incidente en una espera forzosa. La protección viene de repartir los fondos en cinco carteras con perfiles de riesgo distintos y de exigir 3 firmas de 5 en las que guardan el supply, no de hacer esperar a quien ya ha firmado.

Auditoría y monitoreo continuo

Además: re-auditorías cada 12 meses o antes de actualizaciones relevantes del protocolo.

Qué cubrió la auditoría, y qué no

Conviene ser precisos sobre el alcance, porque un informe vale por lo que examina:

• Dentro del alcance: el contrato de staking, un contrato de venta con escrow que ya no forma parte del modelo, y el transfer hook del token — el único código on-chain que tenía el repositorio del token. Los dos hallazgos sobre ese hook se resolvieron eliminándolo del diseño, de modo que el componente del token que entró en la auditoría ya no forma parte del token. → El token
• Fuera del alcance: la herramienta de acuñación (un script fuera de la cadena, que es donde se fijan el supply, los decimales y la revocación de las autoridades), la entrega de tokens mediante Streamflow, el pool de Raydium y la compra mediante Jupiter —protocolos de terceros con sus propias auditorías— y las interfaces de usuario.

Los parámetros económicos que viven en el programa de staking auditado —periodos y tasas, cooldown y penalización— quedan verificados por la auditoría. Para mainnet no se modifica su lógica: solo cambian las direcciones compiladas en el programa. Un contrato auditado tampoco acredita por sí solo el estado de un despliegue nuevo, que se verifica on-chain. El supply, los decimales y la revocación de las autoridades no formaron parte del alcance formal, pero son comprobables on-chain por cualquiera.

Protección de la comunidad

La seguridad no es solo custodia: la propia arquitectura del proyecto incorpora capas que protegen a la comunidad.

Concentración: protección estructural, no cosmética

YESHUA no impone un tope on-chain a la cantidad de tokens que puede tener una dirección. Se evaluó implementarlo mediante un transfer hook de Token-2022 y se descartó por dos razones: los DEX de Solana no admiten el listado de tokens con lógica adicional en la transferencia, lo que habría dejado al token sin mercado; y un límite por cartera se elude repartiendo el saldo entre varias direcciones, de modo que su valor como protección era aparente más que efectivo.

La protección frente a la concentración es por tanto estructural —calendarios de liberación escalonados, circulante inicial bajo, custodia multifirma— y no un control por transferencia.

Protección estructural

• Cooldown de 7 días tras retirar del staking, que aporta estabilidad.
• Vesting prolongados — equipo fundador 36 m (12 de cliff + 24), operaciones de treasury, airdrop e incentivos 36 m.
• Circulante inicial contenido (11,65%) — casi todo dentro del pool, sin desbloqueos del equipo ni de treasury en el lanzamiento.
• LP inicial bloqueado — previsto de forma irreversible antes de abrir el trading. → Liquidez
• Gobernanza como candado — cambiar cualquier parámetro de protección exige el respaldo más amplio de la comunidad.
• Transparencia total — todas las wallets del proyecto son públicas y verificables.

→ Continúa con la estrategia de liquidez.