Scope: Este análisis es exclusivamente una lectura técnica y de riesgo basada en lo visible en CertiK Skynet para el proyecto Vanar Chain (página: Vanar Chain – CertiK Skynet Project Insight).
No es auditoría formal, no es recomendación de inversión y no infiere cosas que no estén soportadas por evidencia pública en Skynet.
---
0) Metodología (controlada)
Fuente única: CertiK Skynet (panel del proyecto).
Objetivo: identificar señales técnicas verificables, límites de evidencia, y riesgos residuales plausibles desde perspectiva de ciberseguridad y due diligence.
En cada punto marco:
- Hecho verificado: aparece explícito en Skynet
- Inferencia razonable: consecuencia lógica limitada desde lo visible
- Sin evidencia pública (en Skynet): no se puede afirmar
---
1) Snapshot de evidencia (lo que Skynet sí confirma)
Identidad del activo observado (Hecho verificado)
- Proyecto: Vanar Chain
- Token/contrato mostrado (Ethereum): 0x8de5b80a0c1b02fe4976851d030b36122dbb8624
- Deployer (Ethereum): 0x6CAF72f26231B7c240794184723B4a199FaB21A9
Scores Skynet (Hecho verificado)
- Skynet Score: 81.73 (A)
- Sub-scores:
- Code Security: 65.71
- Operational: 82.85
- Governance: 84.11
- Fundamental: 71.10
- Market: 92.90
- Community: 98.00
Lectura técnica: “A” general puede coexistir con áreas específicas débiles; aquí Code Security es el sub-score más bajo del set mostrado.
---
2) Evidencia de auditorías y verificaciones (gobernanza y control humano)
Auditorías (Hecho verificado)
- CertiK Audit: No
- 3rd party audit: Sí
- Auditor listado: Beosin
- Fecha publicada (Skynet): 01/09/2025
- Total audits disponibles: 1
Inferencia razonable: existe al menos un reporte público accesible desde Skynet (aunque el contenido/alcance del PDF no se evalúa aquí).
KYC / Team Verification (Hecho verificado)
- CertiK KYC: No
- 3rd party KYC: No
- Estado: Not Verified By CertiK
Bug bounty (Hecho verificado)
- CertiK Bounty: No
- 3rd party bounty: No
Implicación técnica directa (inferida): no hay señal pública en Skynet de un canal económico formalizado de “continuous security testing” vía bounty.
---
3) Token Scan (riesgo a nivel token/contrato mostrado)
Token Scan Score (Hecho verificado)
- Token Scan Score: 67.74
Concentración de holders (Hecho verificado)
- Top 10 Holders Ratio: 41%
Inferencia razonable: una concentración del 41% en top10 es un vector relevante para:
- shocks de liquidez por movimientos coordinados
- cambios abruptos en distribución de oferta
- dependencia de actores grandes
Señales de centralización (Hecho verificado, pero con limitación)
Skynet muestra categorías de checks como:
- Mintable, Hidden Owner, Proxy Contract, Tax Can Be Modified, Blacklist/Whitelist, Transfer Pausable, Can Modify Balance, Ownership Not Renounced, etc.
Sin evidencia pública (en lo visible):
El panel enumera los checks, pero no expone aquí cuáles están marcados como “true/false” en detalle (eso usualmente está en “View Findings / Full Scan”).
Por disciplina: no afirmo que Vanar tenga cualquiera de estos flags activos sin ver el detalle.
---
4) Riesgo de custodia y dependencia de exchanges (estructura de mercado observable)
CEX Holding Analytics (Hecho verificado)
Skynet muestra:
- Wallet Discovery: 15 exchanges
- Market cap held en CEX: $11.39M
- % Market cap held: 53.73%
- “Top exchanges by holding”:
- Binance: $9.69M (45.79%)
- Bybit: $927K (4.30%)
- Bitget: $291K (1.35%)
- Otros (Crypto.com, Indodax, Kucoin, CoinDCX, Ascendex, etc.)
Inferencia razonable (técnica, no narrativa):
- Hay una dependencia estructural de infraestructura CEX para custodia/liquidez.
- Esto introduce riesgo fuera del control del protocolo:
- congelamientos / compliance / incidentes CEX
- concentraciones de flujo y price discovery
- correlación de riesgo operacional ajeno al chain stack
---
5) Salud operativa y “observability posture” desde Skynet
Incident History (Hecho verificado)
- “No security incidents in the past 90 days.”
Limitación técnica (Hecho verificado): es una ventana “last 90 days”, no una garantía histórica completa.
Monitor (Hecho verificado)
Skynet muestra Skynet Active Monitor, pero:
- Website: Not Activated
- Code Repository: Not Activated
- Smart Contract: Not Activated
- Social Media: (monitor existe, pero estado visible indica no activación a nivel de monitor del proyecto)
Inferencia razonable: el monitoreo en Skynet no está configurado como control operativo continuo desde esta vista.
---
6) Website Scan (infra/app/DNS) — qué se puede y no se puede concluir
Skynet lista:
- Network Security: “0 Attentions”
- App Security: “0 Attentions”
- DNS Health: “0 Attentions”
También se muestran checklists típicos (ej. HSTS, CSP, X-Frame-Options, SPF/DMARC/DKIM, SSH weak cipher, etc.)
Hecho verificado: el panel reporta “0 attentions” por categoría.
Sin evidencia pública: no se expone aquí el detalle técnico verificable (hosts exactos, puertos, resultados raw, timestamps de scan).
Inferencia razonable: es un escaneo point-in-time; no sustituye revisión de infraestructura/CI/CD.
---
7) Métricas de madurez y uso (señales de adopción operativa)
Project maturity (Hecho verificado)
- Maturity Indicator: Medium / Somewhat Developed
- Project Age: 5 yrs 2 mos
- Token Launch Date: 2 yrs 2 mos
- Market Cap (mostrado): ~$20M (Skynet lista 20M)
Actividad (Hecho verificado)
- Active Users (7d): 246
- Transactions (7d): 1,997
- Token Transferred (7d): $10.66M
- Most Active Timezone: GMT+6 & GMT+7 (muestra: Maldives, Pakistan, Kazakhstan)
Inferencia razonable: actividad no trivial pero aún moderada en usuarios; transferencias 7d relativamente altas comparadas con usuarios (posible concentración de flujos).
---
8) Límites de confianza (qué Skynet NO permite verificar aquí)
Con evidencia únicamente de esta vista, quedan fuera:
1) Arquitectura formal del protocolo (L1/L2/app/DA)
- Sin evidencia pública (Skynet view): descripción técnica completa del stack y su capa exacta.
2) Repositorios oficiales / commits / releases
- Sin evidencia pública en el panel visible: links a GitHub, paths, tags, CI.
3) Modelo de gobierno real
- multisig, llaves, timelocks, upgrade authority: no verificable aquí.
4) Estado real de flags críticos del token
- proxy, mintable, blacklist, pausability, ownership: requiere abrir “findings”.
5) Garantías cuantitativas / invariantes
- safety/liveness, límites operativos, condiciones de fallo: no aparecen.
---
9) Riesgo residual (integrado SOLO con lo verificable)
Sin severidad y sin mitigaciones; solo persistencia lógica:
R1) Riesgo residual por evidencia incompleta de “Code Security”
- Hecho verificado: Code Security 65.71 (sub-score más bajo).
- Implicación: superficie de incertidumbre técnica en implementación (no confirmable desde este panel).
R2) Riesgo residual por concentración de holders
- Hecho verificado: Top10 holders ratio 41%.
- Implicación: dependencia de comportamiento de grandes tenedores (riesgo sistémico de liquidez/distribución).
R3) Riesgo residual por dependencia de custodia CEX
- Hecho verificado: 53.73% de market cap held en exchanges identificados.
- Implicación: riesgos fuera del control del protocolo (operación CEX, compliance, incidentes).
R4) Riesgo residual por ausencia pública de KYC/bounty (según Skynet)
- Hecho verificado: sin CertiK KYC y sin bounty listados.
- Implicación: menor “señal operacional” de incentivos y accountability continua (esto NO prueba inseguridad, solo limita evidencia).
R5) Riesgo residual por monitoreo no activado
- Hecho verificado: monitores “Not Activated” en Website/Repo/Contract.
- Implicación: menor trazabilidad operacional automatizada desde el stack Skynet.
---
10) Preguntas de verificación (para investigación técnica real, no para hype)
Si estás haciendo due diligence serio, estas son las preguntas que Skynet deja abiertas:
1) ¿Dónde está el repo oficial y cuál es el pipeline de releases/CI?
2) ¿El contrato es proxy/upgradable y quién controla upgrades?
3) ¿Existen mecanismos on-chain de pausado/blacklist/mint y están habilitados?
4) ¿Cuál es el modelo de seguridad formal (invariantes, límites, supuestos)?
5) ¿Qué componentes críticos dependen de infra externa (RPC, indexers, servicios)?
---
11) Debate técnico (elige una opción)
A) “El principal riesgo aquí es concentración y estructura CEX, más que bugs.”
B) “El principal riesgo es falta de evidencia primaria de código/arquitectura en esta vista.”
C) “El principal riesgo es gobernanza (controles humanos no verificables desde Skynet).”
D) “Con esta evidencia, aún no se puede priorizar nada con rigor.”
Responde con A/B/C/D y continúo con el siguiente bloque que tú indiques, manteniendo el mismo estándar “audit-ready”.
