Talently
Talently
Desarrollador Web3

Desarrollador Web3

Construye aplicaciones descentralizadas y contratos inteligentes que operan sobre blockchain con seguridad, eficiencia y transparencia.

Un Web3 Developer diseña e implementa aplicaciones descentralizadas (dApps) y contratos inteligentes sobre redes blockchain como Ethereum, Solana o Polygon. Su trabajo abarca desde la escritura y auditoría de smart contracts hasta la construcción del frontend que interactúa con la blockchain y la integración con protocolos DeFi, NFTs y DAOs. A diferencia del desarrollo web tradicional, el Web3 Developer trabaja en un entorno donde el código desplegado es inmutable, las transacciones son irreversibles y los errores pueden costar millones. La seguridad no es opcional: es el requisito más crítico del rol. Colabora con tokenomics designers, auditores de seguridad y comunidades de usuarios descentralizadas.

SolidityEthereumHardhatethers.jsIPFSDeFi

Recluta al mejor Desarrollador Web3 aquí

Empieza ahora

Responsabilidades Principales

  • •Diseñar e implementar smart contracts en Solidity con patrones de seguridad probados y optimización de gas.
  • •Construir el frontend de las dApps con frameworks como React integrado con wallets (MetaMask, WalletConnect) mediante ethers.js o wagmi.
  • •Escribir tests exhaustivos para los contratos inteligentes cubriendo todos los caminos posibles incluyendo los vectores de ataque conocidos.
  • •Realizar revisiones de seguridad de contratos propios e identificar vulnerabilidades antes del despliegue en mainnet.
  • •Integrar protocolos DeFi, estándares de tokens (ERC-20, ERC-721, ERC-1155) y oráculos de datos externos como Chainlink.
  • •Gestionar el ciclo de vida del contrato: despliegue, verificación en exploradores de bloques, upgrades y monitoreo post-despliegue.

Habilidades Clave

Technical Skills

  • Solidity avanzado: patrones de diseño de contratos, optimización de gas, assembly inline y conocimiento profundo del EVM
  • Frameworks de desarrollo y testing: Hardhat o Foundry para compilación, testing, deployment y scripting de contratos
  • Librerías Web3: ethers.js o wagmi para interacción desde el frontend con contratos y wallets
  • Estándares de tokens y protocolos: ERC-20, ERC-721, ERC-1155, OpenZeppelin contracts y protocolos DeFi como Uniswap y Aave
  • Seguridad de contratos: conocimiento profundo de los vectores de ataque más frecuentes y las mitigaciones correspondientes
  • Infraestructura descentralizada: IPFS para almacenamiento, The Graph para indexación de eventos y Chainlink para oráculos

Soft Skills

  • Mentalidad de seguridad ofensiva: pensar como un auditor o atacante antes de desplegar en mainnet
  • Rigor extremo en el testing dado que los contratos desplegados son inmutables y los errores son irreversibles
  • Capacidad de diseñar sistemas con incentivos económicos correctos que no sean explotables por actores maliciosos
  • Comunicación con comunidades técnicas y no técnicas sobre las capacidades y limitaciones de los contratos
  • Actualización continua en un ecosistema que evoluciona más rápido que cualquier otro en el desarrollo de software
  • Criterio para decidir qué lógica va en la blockchain y qué puede mantenerse off-chain para reducir costos y complejidad

Casos de uso reales

Contexto

Los protocolos DeFi manejan millones de dólares en valor bloqueado. La correctitud y seguridad de sus contratos es la diferencia entre un protocolo exitoso y un exploit de ocho cifras.

Ejemplos reales

  • Token ERC-20 con mecánicas de staking, vesting y distribución de recompensas
  • Automated Market Maker (AMM) con pools de liquidez y cálculo de precios con fórmulas invariantes
  • Protocolo de lending con tasas de interés dinámicas y mecanismos de liquidación de colateral
  • Yield aggregator que optimiza las estrategias de inversión entre múltiples protocolos DeFi

Contexto

Los NFTs permiten representar propiedad digital verificable. Su implementación requiere estándares correctos, metadatos eficientes y protección contra vulnerabilidades de reentrancy en las transferencias.

Ejemplos reales

  • Colección NFT con ERC-721 y generación de metadatos almacenados en IPFS
  • Marketplace con soporte de royalties on-chain según EIP-2981
  • NFTs con atributos dinámicos que cambian según eventos on-chain o datos externos de oráculos
  • Mecanismos de mint con lista blanca, precio variable por etapa y prevención de bot minting

Contexto

Las DAOs permiten que las comunidades tomen decisiones colectivas de forma transparente y sin intermediarios. Su diseño determina si la gobernanza es genuinamente descentralizada o susceptible a ataques de gobernanza.

Ejemplos reales

  • Sistema de votación con token-weighted voting y timelock para ejecutar las propuestas aprobadas
  • Multisig governance con Gnosis Safe para gestión de tesorería de la DAO
  • Delegation de votos para que los holders deleguen su poder de voto a representantes
  • Protección contra ataques de flash loan que podrían manipular el voto en una sola transacción

Contexto

Los contratos inteligentes son deterministas y no pueden acceder a datos externos por sí solos. Los oráculos son el puente entre la blockchain y el mundo real, con sus propias consideraciones de seguridad.

Ejemplos reales

  • Integración con Chainlink Price Feeds para precios de activos en tiempo real en protocolos DeFi
  • Uso de Chainlink VRF para generación de aleatoriedad verificable en juegos y NFTs
  • Integración con protocolos DeFi existentes como Uniswap o Aave desde un contrato propio
  • Automatización on-chain con Chainlink Automation para ejecutar funciones del contrato según condiciones

Contexto

Los contratos son inmutables por defecto, pero los proyectos de largo plazo necesitan poder corregir bugs o añadir funcionalidades. Los patrones de upgrade son técnicamente complejos y tienen sus propios riesgos de seguridad.

Ejemplos reales

  • Proxy patterns con OpenZeppelin Upgrades para contratos actualizables con separación de storage y lógica
  • Proceso de upgrade con timelock y multisig que garantiza que los cambios son revisados y auditados
  • Migración de datos de contratos legacy a nuevas versiones sin pérdida de estado del usuario
  • Monitoreo post-despliegue con sistemas de alerta ante comportamientos anómalos del contrato

Preguntas básicas

El gas es la unidad de medida del costo computacional de ejecutar operaciones en la EVM. Cada opcode tiene un costo en gas que el usuario paga al minero o validador. Para optimizar: usar tipos de datos del tamaño correcto (uint256 es más eficiente que uint8 en la mayoría de los casos por el padding de la EVM), empaquetar variables del mismo slot de storage cuando sea posible (32 bytes por slot), preferir memory sobre storage para variables temporales (storage es 100-200x más caro), evitar loops con longitud no acotada que pueden superar el gas limit del bloque, y usar eventos para datos que no necesitan ser leídos on-chain en lugar de almacenarlos en storage.
Reentrancy ocurre cuando un contrato externo malicioso llama de vuelta al contrato original durante la ejecución de una transferencia, antes de que el estado se actualice. El ataque más famoso es el hack de The DAO (60M USD en 2016). Prevención: seguir el patrón Checks-Effects-Interactions: verificar condiciones primero, actualizar el estado del contrato, y luego ejecutar las llamadas externas. Nunca enviar ETH o llamar contratos externos antes de actualizar el estado. Usar el modificador nonReentrant de OpenZeppelin ReentrancyGuard para contratos complejos. Preferir pull payments (el usuario retira sus fondos) sobre push payments (el contrato envía fondos) cuando sea posible.
call: ejecuta código de otro contrato en el contexto del contrato llamado (su propio storage). Usado para llamadas normales a funciones externas. Retorna éxito/fallo y datos de retorno. delegatecall: ejecuta código de otro contrato pero en el contexto del contrato llamador (usa el storage del llamador). La base de los proxy patterns para contratos upgradeables. Peligroso si se usa incorrectamente porque el contrato externo puede modificar el storage del llamador. staticcall: como call pero revierte si el código intentara modificar el estado. Usado para llamadas de solo lectura que garantizan no efectos secundarios.
Los eventos son registros de bajo costo almacenados en los logs de la transacción, no en el storage del contrato. Son esenciales para las dApps porque: el frontend puede suscribirse a eventos para reaccionar a cambios en el contrato en tiempo real, los servicios de indexación como The Graph los usan para construir bases de datos consultables del estado histórico del contrato, y son la forma más económica de registrar información que no necesita ser leída por otros contratos. Los eventos indexados (parámetros con indexed) permiten filtrar eficientemente los logs. No emitir eventos en operaciones importantes es un anti-patrón que hace la dApp difícil de integrar y auditar.
Frontrunning ocurre cuando un actor (típicamente un bot MEV) observa una transacción pendiente en el mempool y envía su propia transacción con mayor gas para que se ejecute antes. En una subasta: un bot puede ver la oferta ganadora y enviar una oferta ligeramente mayor antes de que se incluya en el bloque. En un DEX: un bot puede ver un swap grande que moverá el precio, comprar antes del swap y vender después (sandwich attack). Mitigaciones: commit-reveal scheme para subastas (el usuario primero commitea un hash de su oferta, luego la revela cuando el período de commit cierra), slippage protection en DEX (la transacción revierte si el precio se mueve más de un porcentaje aceptado), y uso de protocolos MEV-aware como Flashbots.
Los nodos de la blockchain deben poder verificar independientemente el resultado de cada transacción para alcanzar consenso. Si un contrato pudiera llamar a una API externa, distintos nodos obtendrían potencialmente distintas respuestas, haciendo imposible el consenso. El oracle problem es el desafío de introducir datos del mundo real en la blockchain de forma verificable y resistente a manipulación. Chainlink resuelve esto con una red descentralizada de oráculos que agregan datos de múltiples fuentes y proveen pruebas criptográficas de la integridad de los datos. El riesgo del oráculo no desaparece: si el oráculo es manipulado o falla, el contrato usa datos incorrectos. Por eso los protocolos DeFi importantes usan múltiples fuentes de precios con mecanismos anti-manipulación como los TWAPs (Time-Weighted Average Prices).
El patrón proxy separa el storage del contrato (en el proxy) de la lógica (en la implementación). El usuario interactúa con el proxy, que usa delegatecall para ejecutar la lógica de la implementación en su propio contexto de storage. Para upgradear, se despliega una nueva implementación y se actualiza el puntero en el proxy. Riesgos críticos: storage collision (si la nueva implementación usa los mismos slots de storage con tipos distintos, puede corromper datos), initialization issues (los constructores no se ejecutan en upgrades, se usan funciones initializer que deben protegerse con modificadores), y centralización del control del upgrade (quién puede actualizar el contrato tiene poder total sobre él). OpenZeppelin UUPS y Transparent Proxy son las implementaciones más auditadas y usadas.
ERC-20: tokens fungibles donde todas las unidades son idénticas e intercambiables. Para monedas, tokens de gobernanza, tokens de utilidad. ERC-721: tokens no fungibles donde cada token tiene un ID único y puede tener atributos distintos. Para NFTs de arte, coleccionables, representación de activos únicos. ERC-1155: multi-token standard que soporta tanto fungibles como no fungibles en el mismo contrato con transferencias en batch. Para juegos donde hay monedas (fungibles) y items únicos (no fungibles), o para colecciones donde algunos tokens son escasos (no fungibles) y otros son comunes (semi-fungibles). ERC-1155 es más eficiente en gas para transferencias múltiples y reduce el número de contratos necesarios.

Preguntas técnicas

El algoritmo de rewards per token acumulados es el estándar para distribución de recompensas sin iteración. Mantener una variable global rewardPerTokenStored que acumula las recompensas por token a lo largo del tiempo. Por cada usuario, almacenar el rewardPerTokenPaid en el momento de su último claim o stake. Las recompensas pendientes de un usuario son (rewardPerTokenStored - rewardPerTokenPaid[user]) × balanceOf[user] + rewards[user]. Actualizar rewardPerTokenStored en cada operación de stake, unstake o claim con el tiempo transcurrido desde la última actualización. Este patrón implementado en Synthetix Staking Rewards es O(1) independientemente del número de stakers porque nunca itera sobre todos los usuarios.
Los tests deben cubrir: correctitud matemática de los cálculos de precio con la invariante x*y=k, verificando que las fórmulas producen los resultados correctos con precisión de punto fijo. Reentrancy en las funciones swap y addLiquidity usando un contrato de ataque que intenta re-entrar durante la ejecución. Price manipulation: verificar que el precio no puede manipularse en un solo bloque de forma que afecte a otras operaciones del bloque. Slippage protection: verificar que los swaps revierten si el slippage supera el máximo especificado. Flash loan attacks: simular un flash loan que toma liquidez del pool, ejecuta una manipulación y devuelve la liquidez, verificando que el contrato es resistente. Invariant testing con Foundry usando fuzzing sobre las funciones críticas para encontrar estados inesperados.
Los ataques de flash loan en gobernanza toman prestados tokens de gobernanza, votan en una propuesta, y los devuelven en la misma transacción. La mitigación estándar es usar snapshots de balance en un bloque anterior al período de votación: el poder de voto se calcula en el bloque N (el bloque del snapshot) y la votación ocurre a partir del bloque N+delay. Los tokens adquiridos o tomados prestados después del snapshot no tienen poder de voto en esa propuesta. Implementación con OpenZeppelin Governor: el token de gobernanza debe implementar ERC20Votes que registra checkpoints de balance por bloque. El Governor usa getVotes(account, blockNumber) con el blockNumber del snapshot para calcular el poder de voto. El timelock adicional entre la aprobación y la ejecución de la propuesta da tiempo a la comunidad para reaccionar ante propuestas maliciosas.
Los arrays en storage son costosos: cada lectura y escritura de un elemento es una operación SLOAD/SSTORE (100 y 20000 gas respectivamente). Estrategias: cargar el array completo en memoria al inicio de la función y operar sobre la copia en memory, escribiendo de vuelta al storage solo al final si hay cambios. Usar mappings en lugar de arrays cuando el acceso es por clave y no se necesita iterar: los mappings tienen costo O(1) en lugar de O(n). Para arrays que deben iterarse en el contrato, imponer un límite máximo de longitud para que el gas nunca supere el block gas limit. Para procesamiento de arrays largos sin límite práctico, usar el patrón de procesamiento por batches donde el caller paga el gas de cada batch.
Implementar siguiendo el patrón Checks-Effects-Interactions. Primero verificar (checks): require(balances[msg.sender] >= amount, error). Luego actualizar el estado (effects): balances[msg.sender] -= amount (usando Solidity 0.8+ que tiene overflow protection nativa, o SafeMath en versiones anteriores). Finalmente ejecutar la transferencia (interactions): (bool success, ) = msg.sender.call{value: amount}(''); require(success). El modificador nonReentrant de OpenZeppelin como segunda línea de defensa. Con Solidity 0.8+, los overflows y underflows revierten automáticamente sin necesitar SafeMath. Usar custom errors en lugar de require strings para reducir el gas cost de los revertes.
Crear un subgraph con el schema de entidades (los objetos que se quieren consultar: Token, Transfer, User) definidos en schema.graphql. En subgraph.yaml, definir los data sources: qué contrato indexar, desde qué bloque, y qué eventos escuchar con sus mappings. Los mappings son funciones AssemblyScript que se ejecutan ante cada evento y crean o actualizan entidades en el store del subgraph. Por ejemplo, ante un evento Transfer del ERC-20, el mapping crea o actualiza la entidad Token con el nuevo supply, y actualiza el balance de los wallets emisor y receptor. El subgraph se despliega en The Graph Network o en un nodo propio. El frontend consulta con GraphQL el estado histórico del contrato sin depender de un backend centralizado.
Usar wagmi o RainbowKit que abstraen la gestión de chains múltiples con configuración declarativa. Definir la lista de chains soportadas con sus RPC endpoints, block explorers y direcciones de contrato. El frontend detecta la chain activa del wallet del usuario y muestra el estado correspondiente. Para las direcciones de los contratos, mantener un objeto de configuración indexado por chainId que el frontend consulta según la chain activa. Los contratos en diferentes redes no comparten estado, por lo que el frontend debe gestionar el contexto de qué red está activa y qué datos mostrar. Implementar una capa de abstracción que envuelve las llamadas a los contratos para que el resto del frontend no tenga que gestionar la chain activa directamente.
El proceso de auditoría tiene múltiples capas. Análisis estático automático: Slither detecta vulnerabilidades conocidas (reentrancy, integer overflow, unchecked return values, uso de tx.origin) en segundos. Mythril y Echidna para análisis más profundo con fuzzing. Revisión manual sistemática: leer el contrato línea por línea con el OWASP Smart Contract Top 10 y el SWC Registry como checklist. Revisar específicamente: acceso a funciones privilegiadas, manejo de ETH y tokens, interacciones con contratos externos, manipulabilidad de timestamps y block numbers, y correctitud matemática de los cálculos financieros. Invariant testing con Foundry: definir propiedades que siempre deben ser verdad y usar fuzzing para intentar violarlas. Para contratos con valor significativo, una auditoría externa independiente es obligatoria antes del mainnet.

Preguntas avanzadas

Principio de mínimo privilegio entre contratos: cada contrato tiene acceso solo a los contratos que necesita y solo a las funciones que necesita. Separar las responsabilidades en contratos distintos: el contrato de lógica del protocolo separado del contrato de almacenamiento de fondos (vault). Interfaces explícitas entre contratos para que las dependencias sean transparentes. El contrato de vault solo acepta llamadas del contrato de lógica, nunca directamente de usuarios. Pausability con roles diferenciados: un rol de pausa de emergencia que puede detener el protocolo sin necesitar el timelock completo ante un exploit en curso. Los fondos del usuario nunca deben pasar por más contratos de los estrictamente necesarios: cada hop adicional es una superficie de ataque. El timelock en el contrato de governance garantiza que cambios al protocolo tienen un período de revisión pública antes de ejecutarse.
Un death spiral ocurre cuando la caída del precio del token de gobernanza reduce los incentivos de los proveedores de liquidez, lo que reduce la liquidez, lo que aumenta el slippage, lo que reduce el uso del protocolo, lo que reduce los ingresos, lo que reduce el precio del token. Diseñar para evitarlo: los ingresos del protocolo deben ser independientes del precio del token de gobernanza (tasas de uso del protocolo que existen aunque el token valga cero). La emisión de tokens como incentivo debe ser finita y decreciente, no infinita. La liquidez del protocolo no debe depender principalmente de la emisión de tokens: si la liquidez solo existe por los incentivos, desaparece cuando los incentivos terminan. Los mecanismos de burning de tokens que reducen el supply ante el uso creciente pueden crear presión de precio orgánica. Modelar matemáticamente el equilibrio del sistema antes del lanzamiento para identificar escenarios de colapso.
Los bridges cross-chain tienen un historial de exploits (Ronin, Wormhole, Nomad). La arquitectura más segura actual es usar protocolos de mensajería cross-chain auditados (LayerZero, Axelar, Wormhole v2 con su modelo de guardian) en lugar de construir un bridge propio. El contrato en la chain de origen envía un mensaje al protocolo de mensajería especificando la acción a ejecutar en la chain destino. El contrato en la chain destino verifica la autenticidad del mensaje y ejecuta la acción. La mayor complejidad es la gestión del estado en caso de fallo: si el mensaje llega pero la transacción falla en la chain destino, el estado de la chain origen ya se modificó. Diseñar para eventual consistency con mecanismos de retry y reembolso si la operación no puede completarse.
El TVL no es un indicador de seguridad. La evaluación requiere: revisar los informes de auditoría del protocolo (quién auditó, cuándo, qué findings se encontraron y cuál fue la resolución de cada uno). Tiempo en producción sin incidentes: los protocolos más seguros tienen al menos 12-18 meses en mainnet con el TVL actual sin exploits. Revisar el código directamente en Etherscan o en el repositorio: ¿los contratos son verificados? ¿coinciden con lo que dicen los documentos? Evaluar la centralización del control: ¿hay un multisig con timelock que gestiona los upgrades, o un EOA (Externally Owned Account) sin restricciones puede pausar o drenar el protocolo? Revisar el historial de incidentes y cómo fueron manejados. Para la integración, asumir que el protocolo externo puede ser pausado o comprometido y diseñar el contrato propio para manejar ese escenario gracefully.
Los exploits DeFi ocurren en segundos. El proceso de respuesta debe estar pre-diseñado, no improvisado. Diseño preventivo: el contrato debe tener una función de pausa de emergencia accesible por un multisig de respuesta rápida (3/5 firmantes con los Core devs) sin timelock, y separada del governance normal que sí tiene timelock. Al detectar el exploit (monitoreo automatizado de transacciones anómalas, alertas en Discord de la comunidad): verificar que el exploit es real, pausar el contrato si hay función de pausa, y contactar a exchanges y bridges para que listen las transacciones del attacker si aún tiene los fondos. Comunicar a la comunidad en tiempo real con la información disponible. Post-exploit: análisis forense completo, disclosure responsable del exploit, plan de remediación y, si es posible, negociación con el attacker (muchos exploiters devuelven fondos a cambio de una bounty). Auditoría independiente antes de reanudar el protocolo.
La transparencia de la blockchain es una característica, no solo un problema, pero hay casos de uso donde la privacidad es un requerimiento legítimo. Enfoques técnicos: Zero-Knowledge Proofs (ZKPs) permiten demostrar conocimiento de información sin revelarla (que tienes suficiente balance para un pago sin revelar el balance). Tornado Cash era el ejemplo más conocido de privacidad para ETH usando ZKPs, con implicaciones regulatorias significativas. Para aplicaciones empresariales, las redes permissioned como Hyperledger Fabric o Quorum permiten visibilidad selectiva de transacciones. Para metadatos de usuario (qué wallet pertenece a qué persona), la separación de wallets y el uso de stealth addresses añade privacidad sin cambios al protocolo. El diseñador debe evaluar qué datos realmente necesitan ser públicos en la blockchain y cuáles pueden mantenerse off-chain con solo su hash o commitment on-chain.

Errores comunes en entrevistas

Un Web3 Developer que no puede hablar de reentrancy, flash loan attacks, price manipulation, frontrunning y acceso no autorizado a funciones privilegiadas demuestra que desarrolla contratos sin la mentalidad de seguridad que el dominio exige. Los auditores y equipos de seguridad que entrevistan para estos roles esperan que el candidato piense en adversarios desde el diseño.
Los contratos desplegados en mainnet son inmutables y manejan fondos reales. Un candidato que describe su proceso de desarrollo sin mencionar el testing con Hardhat/Foundry, el fuzzing con Echidna, el análisis estático con Slither y la auditoría externa antes del mainnet demuestra que trabaja con el mismo rigor que el desarrollo web tradicional en un dominio donde un bug puede costar millones.
Poner todo en la blockchain porque el proyecto es Web3 es un error de diseño que produce contratos costosos, lentos y con lógica innecesariamente compleja. Un buen Web3 Developer puede articular qué necesita las garantías de la blockchain (transferencias de valor, ownership, voting) y qué puede mantenerse off-chain (metadatos de NFTs en IPFS, lógica de matching de órdenes en un servidor) reduciendo costos y complejidad.
No todos los problemas requieren una solución blockchain. Un candidato que propone blockchain para casos de uso donde una base de datos centralizada sería más eficiente, más barata y con mejores garantías demuestra pensamiento de hype en lugar de criterio de ingeniería. La blockchain tiene costos reales (latencia, costo de gas, complejidad) que solo se justifican cuando sus garantías de descentralización son necesarias.
Los tokens de seguridad, los protocolos de mixing, los sistemas de préstamo con interés y otros casos de uso Web3 tienen implicaciones regulatorias significativas que varían por jurisdicción. Un Web3 Developer que ignora completamente estas implicaciones puede construir técnicamente correctamente pero producir un producto que enfrenta problemas legales que destruyen el proyecto.
Los usuarios pagan gas por cada transacción. Un contrato con operaciones costosas produce una mala experiencia de usuario que reduce la adopción. Un Web3 Developer que no puede hablar de las operaciones más costosas del EVM, de las estrategias de empaquetado de storage, o del impacto del gas en las decisiones de arquitectura del contrato demuestra que no ha desarrollado contratos con usuarios reales.