TECNOLOGÍAS

Solana

Una blockchain de alto throughput y baja comisión, con un runtime distinto al de la EVM. Otro modelo de programación, otros trade-offs.

Última revisión: 2026-05-24 porKevin Riedl wiki ↗

Solana no es compatible con EVM. Los smart contracts (en Solana se llaman „programs") se escriben en Rust, se despliegan como bytecode BPF y los ejecuta el runtime de Solana. La arquitectura optimiza throughput (miles de TPS) y comisiones bajas, al coste de requisitos de hardware más altos para validadores y un perfil de descentralización distinto (algunos dicen más centralizado).

Para aplicaciones de consumo donde el usuario paga comisiones por debajo del céntimo y la confirmación es sub-segundo, Solana es difícil de batir. Para componibilidad DeFi profunda con el ecosistema EVM, el coste de cruzar el bridge no es trivial. La chain adecuada depende de qué trade-off pesa más en tu producto.

Wavect entrega tanto en Solana como en EVM. No tenemos sesgo de chain; tenemos sesgo de caso de uso.

// FAQ

Preguntas frecuentes

Preguntas frecuentes

Solana si la UX exige confirmación sub-segundo y comisiones invisibles para el usuario. L2 EVM si necesitas integrarte con DeFi existente o si tu equipo ya domina Solidity. La diferencia rara vez es técnica; es de ecosistema y de talento disponible.
El modelo de cuentas. En Solana cada cuenta que toca el programa tiene que pasar explícitamente como parámetro, y los datos se guardan en cuentas separadas del código. Equipos que vienen de EVM intentan trasladar patrones de mapping y storage globales, y aterrizan en código que no compila o que rompe en runtime con errores opacos.
Anchor para el 95 % de los proyectos: menos boilerplate, mejor seguridad por defecto, ecosistema de auditoría más maduro. Solana nativo si necesitas optimización extrema de compute units en un programa con tráfico altísimo. Empezar nativo „para aprender" suele costar semanas y producir bugs que Anchor habría evitado.