21 Mandatos Web3: A Dónde Fueron Realmente los Costes de Gas, y Qué Cadenas Elegiríamos Hoy

A lo largo de 21+ mandatos Web3 que Wavect ha lanzado, aproximadamente 60-75% del coste acumulado de gas fue a transacciones de write en flujos de cara al usuario, alrededor del 15-20% a deploys de contrato (one-time pero doloroso en mainnet), aproximadamente 5-10% a llamadas de read que deberían haber sido off-chain, y el resto a retries, transacciones fallidas y migraciones. Si eligiéramos cadenas hoy con lo que sabemos ahora, casi ningún producto greenfield se lanzaría primero en Ethereum mainnet. Base, Arbitrum o Solana manejarían el 80% de los casos de uso.

Los números son agregados a lo largo de mandatos, enmarcados como rangos del historial de engagements de Wavect, no auditorías exactas por proyecto.

¿Dónde se acumula realmente el gas en un producto Web3 típico?

Los founders se preocupan por el coste de deploy. El deploy es un golpe one-time. El coste real se compone en las transacciones de write de cara al usuario a lo largo de meses. Aquí está cómo lo vemos desglosado en los mandatos.

• Deploys de contrato (15-20%). One-time por contrato. Doloroso en Ethereum mainnet (a menudo cifras de cuatro a cinco dígitos en EUR para lógica no trivial). Trivial en L2s y Solana.
• Transacciones de write (60-75%). Mints, transfers, swaps, actualizaciones de posición, flujos de claim. Cada acción de usuario. Este es el presupuesto que se compone.
• Llamadas de read (5-10%). Deberían ser gratuitas vía RPC estándar. Se convierte en coste cuando los equipos usan providers de pago (tiers pagados de Alchemy, Infura) o hacen reads on-chain que deberían haber sido un subgraph.
• Compute off-chain (variable). Indexers, oracles, keepers, signers. No es "gas" estrictamente, pero está en el mismo presupuesto operacional. A menudo subestimado.
• Retries y txs fallidos (3-7%). Fallos de slippage, conflictos de nonce, subestimación de gas. Se come más presupuesto del que los founders esperan.

¿Cómo se comparan realmente las cadenas para workloads típicos?

Comparación entre las cadenas en las que hemos lanzado. Los costes son order of magnitude típicos, no snapshots exactos de pricing (los mercados de gas se mueven). Úsalo como framework de decisión, no como una cotización.

El patrón es obvio. Cualquier L2 EVM es aproximadamente 50-200x más barato que mainnet por transacción. Solana es aproximadamente otras 5-20x más barato que las L2s para ops simples. Para casos de uso consumer de alta frecuencia, mainnet no es competitivo en coste.

¿Qué lanzamos realmente en qué cadena?

Algunos detalles de productos que Wavect construyó. Trátalo como contexto de engagement, no como un leaderboard de cadenas.

• Scramble Pay: flujos de pago cross-chain, multi-chain EVM por diseño. La selección de cadena fue una decisión de producto, no una decisión de coste.
• Quivr: construido alrededor de Solana por el coste de transacción y la velocidad de confirmación en flujos consumer. Producto distinto, cadena distinta, misma lógica.
• Trabajo de account abstraction: L2 EVM por defecto. La AA en mainnet existe, la economía rara vez la justifica para flujos consumer.
• Lightbridge: mensajería cross-chain, por definición multi-chain. La selección de cadena aquí es "donde el usuario ya está", no "donde es más barato".
• Trabajo de MetaMask Snap: ecosistema EVM por diseño. El Snap es la capa de extensión de wallet, la cadena depende de con qué interactúa el usuario.

"La selección de cadena es una decisión de producto, no una decisión de tecnología. Elige la cadena donde tus usuarios ya están, y donde tu economía unitaria sobreviva a la frecuencia de transacciones que tu producto necesita."

¿Qué cadenas elegiríamos hoy, por caso de uso?

• App consumer, masa-mercado, bajo valor por tx. Solana, o Base si tienes que quedarte en EVM. Mainnet es equivocado. Polygon es aceptable pero perdiendo share relativo.
• Producto DeFi, usuarios sofisticados, mayor valor por tx. Arbitrum o Base. Mainnet es aceptable si tu tamaño promedio de tx justifica $20+ de gas.
• Producto NFT-heavy. Solana por coste, Base por distribución a usuarios adyacentes a Coinbase, Polygon si tienes un pipeline de marca existente allí.
• Infraestructura cross-chain o de wallet. EVM-first más soporte selectivo de Solana. Ambos ecosistemas son demasiado grandes para ignorar en 2026.
• Producto de account abstraction. L2 EVM por defecto. El tooling de AA en L2s está más maduro que las alternativas para la mayoría de equipos.
• Caso de uso regulado / institucional. Ethereum mainnet o un L2 regulado. El ecosistema de compliance y auditoría sigue concentrándose allí. El coste no es el criterio primario.

¿En qué nos equivocamos al elegir cadenas?

Honestamente: demasiado default-a-Ethereum-mainnet en 2021 y 2022. En su momento, las L2s no estaban tan maduras y la UX de bridge era ruda. Con hindsight, varios mandatos habrían estado mejor servidos lanzando directamente en Arbitrum o Polygon, incluso con el ecosistema de tokens ligeramente menos líquido en el momento. El coste de producto de estar en mainnet era mayor que el beneficio de distribución para el segmento de usuario.

También subestimamos Solana para casos de uso de cara al consumidor durante demasiado tiempo. La cadena tiene trade-offs (toolchain distinto, pool de contratación con skills EVM más pequeño), pero para transacciones sub-dólar en flujos consumer la economía no está cerca.

¿Cómo debería un founder elegir una cadena en 2026?

1. Estima transacciones por usuario al mes a escala. No en MVP. A escala.
2. Multiplica por 12 meses por target de cuenta de usuarios. Esa es tu huella de gas anualizada al coste unitario X.
3. Si ese número en Ethereum mainnet es más del ~5% de los ingresos esperados por usuario, mainnet es equivocado.
4. Luego decide entre L2s EVM (pool de desarrolladores, madurez de tooling) y Solana (coste, velocidad) basado en el resto de tu superficie de producto.
5. Evita lanzar multi-chain el día uno. Elige una. Añade cadenas cuando tengas usuarios y razones.