Cómo mover USDT de Tron a EVM sin quedar atrapado por la liquidez

2 de abril de 2026 15 minutos de lectura

Si llevas suficiente tiempo en DeFi, el exploit CrossCurve probablemente no le sorprendió. El 1 de febrero de 2026, CrossCurve experimentó un incidente de cadena cruzada que provocó aproximadamente $3M en pérdidas. Para nosotros, no se trata sólo de “noticias del mercado”. Es un control de calidad obligatorio antes de cualquier integración de socios. Somos responsables tanto de nuestra propia arquitectura como de la seguridad de nuestros clientes. Por eso, paralelamente a las actualizaciones públicas de CrossCurve, revisamos los detalles del incidente y evaluamos cómo la causa raíz podría (o no) afectar a nuestras integraciones previstas.

Contexto de este artículo

¿Qué le pasó exactamente a CrossCurve? Sin profundizar innecesariamente en la terminología, no se trató de un hackeo de blockchain, sino de una patrón de diseño poco intuitivo procedente del SDK Axelar GMP (v5.10.0) que puede pasar desapercibida incluso en auditorías profesionales si no se comprende explícitamente el riesgo. El propio contrato ReceiverAxelar había sido auditado y verificado en la cadena, pero la vulnerabilidad se encontraba en una ruta de ejecución acelerada para mensajes a través de la cadena, en la que se podía activar una operación crítica sin una validación completa de la fuente a través de la pasarela. En el caso concreto de CrossCurve, la situación se vio agravada por una configuración débil del umbral de confirmación (umbral = 1), que reducía la solidez general del modelo de validación.

Este incidente es también una señal más amplia para los integradores de Axelar: al seguir ejemplos oficiales y heredar de contratos de ejecución “exprés”, los proyectos pueden exponer involuntariamente una superficie de ataque peligrosa incluso si el resto del código es correcto y parece listo para producción. Otro punto importante es que el riesgo no desaparece por sí solo al actualizar: incluso las versiones más recientes del SDK contienen patrones similares, y si los equipos migran sin reconocer el problema arquitectónico, pueden arrastrar el riesgo. En la práctica, la conclusión es sencilla: cualquier ruta de ejecución rápida debe estar estrictamente restringida o reforzada con fuertes comprobaciones de origen/autorización en el lado del integrador; de lo contrario, la mecánica de estilo exprés puede convertirse en una elusión de tus propios supuestos de seguridad.

Al mismo tiempo, nuestra postura sobre CrossCurve sigue siendo positiva e, irónicamente, la complejidad de su arquitectura hace que este incidente sea menos universal y repetible de lo que podría parecer a primera vista. El exploit se basaba en un patrón de mensajería/ejecución específico (una elección de diseño de SDK particular), mientras que la solución hacia la que CrossCurve se dirige ahora -y la que estamos considerando en nuestros propios productos para transferencias seguras de activos entre cadenas- no depende de ese vínculo vulnerable. Por esa razón, incluso si ya hubiéramos estado integrados con CrossCurve en el momento del incidente, este vector de ataque exacto no habría afectado a nuestra arquitectura, porque nuestros puntos de confianza y validación están estructurados de forma diferente y no se basan en la misma ruta de ejecución exprés.

Finalmente, la actualización oficial de CrossCurve, publicada el 13 de febrero de 2026, confirmó efectivamente las conclusiones a las que nuestro equipo llegó de forma independiente. Están restaurando el sistema por etapas, comenzando por los componentes que no se vieron afectados (el agregador ya está activo, con enrutamiento a través de Rubic y Bungee), y luego volviendo a habilitar el Puente de Tokens y el Puente de Consenso con medidas de seguridad adicionales. En particular, declararon que el puente de consenso sólo se activará una vez completadas las comprobaciones de seguridad reforzadas. En “restaurar sólo lo que se verifique con seguridad, y endurecer antes de la reactivación” se ajusta bien a la forma en que evaluamos la madurez de los protocolos de los socios antes de la integración.

Esa es exactamente la razón por la que mover USDT de Tron a las redes EVM no es tan sencillo como conectar un puente y darlo por terminado. Tron es donde realmente se mueve una enorme cantidad de USDT: las comisiones eran baratas (ya no lo son, de ahí la necesidad de puentes), los flujos son familiares y los volúmenes son reales. Así que cuando dices “necesitamos liquidez en Tron”, la verdadera cuestión es dónde está el dinero, a quién se le permite moverlo y qué se rompe cuando una suposición resulta ser errónea.

Este artículo está aquí para frenar esa conversación en el buen sentido. Te guiaré a través de las principales formas en que USDT se mueve de Tron a las redes EVM, cómo se comportan esos enfoques cuando el volumen real golpea, y luego dar un paso atrás para hacer la única pregunta que realmente importa: ¿qué riesgos estás realmente dispuesto a llevar.

Obtenga una revisión rápida de su ruta de mensajes a través de la cadena

Establecer el marco: Tron, liquidez y las verdaderas disyuntivas

Llegados a este punto, la cuestión es cómo se traslada realmente USDT de Tron a una red EVM, y qué estás asumiendo cuando eliges un camino en lugar de otro.

La mayoría de las discusiones se atascan en el nivel del protocolo, pero ésta no lo hará. Antes de nombrar soluciones concretas, quiero ser explícito sobre las dimensiones que realmente importan cuando se trata de volumen real. En la práctica, todos los diseños de cadena cruzada acaban haciendo concesiones a lo largo de los mismos axe, aunque el lenguaje de marketing difiera.

La primera es liquidez. Algunos modelos exigen que el capital esté previamente depositado en ambas partes. Otros lo evitan por completo, pero introducen distintas formas de fideicomiso. El segundo es identidad del activo. A veces los usuarios reciben lo que todo el mundo está de acuerdo en que es “el” USDT. A veces no, y esa distinción tiene efectos reales en DeFi. Además comportamiento de los costes bajo carga, finalidad velocidad, hipótesis de seguridad, esfuerzo de integración, y lo dependiente que te vuelves de la hoja de ruta de otra persona.

Si se alinean estas dimensiones, el espacio de diseño se colapsa en cuatro grandes enfoques. No son variaciones de lo mismo porque resuelven problemas distintos y fallan de maneras diferentes. La tabla siguiente es una orientación rápida.

Un mapa rápido de los cuatro enfoques

Acérquese a	Donde vive la liquidez	Tipo de activo	UX a volumen real	Riesgo primario
Puentes / piscinas LP	Prefinanciación por ambas partes	USDT nativo	Bueno hasta que se vacíen las piscinas	Agotamiento de la liquidez, desequilibrio
Bloquear-desbloquear/quemar-desbloquear	Encerrado en Tron	Puenteado / envuelto	Previsible	Confianza, fragmentación
Ejecución basada en intenciones	Con solucionadores / MM	Depende de la ruta	Muy bueno si los solucionadores se quedan	Salida del solucionador, fijación de precios
Entrada híbrida	Cadenas líquidas externas	Canónico por diseño	Estable si se mantiene el enrutamiento	Mensajería, agregación

Lo importante es señalar que ninguno de estos enfoques elimina el riesgo; sólo lo redistribuyen. Algunos concentran el riesgo en la provisión de liquidez, mientras que otros lo trasladan a la confianza, la lógica de ejecución o los operadores externos. Una vez aclarado esto, el resto del debate resulta mucho más sencillo.

Con este marco en mente, ahora podemos analizar cada enfoque en detalle y ver lo que realmente se obtiene y lo que se asume en silencio cuando se elige.

Vea qué servicios relacionados ofrecemos

Enfoque #1. Puentes de LP y fondos de liquidez nativos

El modelo es sencillo. Un usuario deposita USDT en un pool en Tron y recibe USDT de un pool correspondiente en la cadena EVM de destino. Idealmente, no aparecen tokens envueltos o sintéticos. El mismo activo se mueve a través de las cadenas, pero se requiere liquidez “aquí y allá” para hacerlo posible.

Desde el punto de vista del usuario, esto suele parecer una transferencia directa. El puente no acuña un nuevo activo. Redistribuye la liquidez existente entre pools desplegados en diferentes redes.

Pros

Cuando los puentes LP se instalan correctamente, ofrecen varias ventajas claras.

La UX suele ser muy buena. Las transferencias son rápidas, los flujos fáciles de entender y los usuarios sienten que “tienen el mismo activo” al otro lado.
No hay fragmentación de la liquidez a nivel de activos. No hay proliferación de “diferentes versiones de USDT”, lo que simplifica las integraciones DeFi en los EVM.
Economía transparente para los proveedores de liquidez. Las comisiones se comportan “como en un fondo DEX”, lo que facilita la explicación y el razonamiento sobre los rendimientos.

Contras

El principal inconveniente es la liquidez. Los puentes de LP requieren liquidez inicial, a veces de millones. Sin ella, las grandes transferencias se “comerán el fondo común”, lo que provocará límites estrictos o un fuerte aumento de las comisiones y los deslizamientos. Esta restricción se aplica independientemente de la red EVM que esté en el lado receptor.

También hay un dependencia crítica de la infraestructura de mensajería. Los puentes de este tipo se basan en la mensajería entre cadenas para coordinar los lanzamientos de pools, y la mayoría de las soluciones ya preparadas se integran con los principales proveedores de mensajería. En la práctica, esto significa:

la incorporación de un protocolo de mensajería de primer nivel,
pagando unos costes de integración que suelen oscilar de $250k a $500k en función de la urgencia,
esperando en colas de integración que pueden alargarse hasta medio año.

En ese momento, ya no se trata de “sólo conectar un puente”. Es la puesta en marcha y el mantenimiento de un mercado de liquidez.

Riesgos

Los puentes LP conllevan múltiples niveles de riesgo simultáneamente.

Riesgo del contrato inteligente y riesgo de la infraestructura de mensajería o repetidor. Los fallos en los contratos o en la gestión de mensajes pueden congelar los fondos o liberarlos incorrectamente.
Escenarios de quiebra bancaria en condiciones de desequilibrio y pánico. Si los flujos se inclinan fuertemente en una dirección, las piscinas pueden vaciarse más rápido de lo que pueden recuperarse.
Riesgo de cumplimiento de Stablecoin. La inclusión en listas negras o la pausa por parte de un emisor se aplica a todos los enfoques, pero en los puentes basados en pools es especialmente visible porque los pools representan un objetivo claro y concentrado.

Recientes incidentes en cadenas cruzadas han demostrado cómo los fallos en la validación de mensajes pueden propagarse en cascada por las redes. Aunque estos incidentes no tenían que ver necesariamente con pools de LP, ponen de manifiesto que la gestión correcta de los mensajes también es un aspecto crítico para los puentes basados en pools.

Ejemplos del mundo real y lo que implican

Núcleo Allbridge (mensajería dentro de Allbridge)
Allbridge se posiciona como un swap de stablecoin entre cadenas construido en torno al modelo de pool, con comisiones distribuidas a favor de los proveedores de liquidez. Los materiales públicos hacen hincapié en que la seguridad no se basa en un único control, sino en múltiples prácticas y capas de control. Las comunicaciones públicas también describen un reparto de comisiones del tipo “80% a los LP y 20% a la tesorería”.

Stargate / Ecosistema LayerZero (mensajería a través de LayerZero)
Stargate aborda históricamente los pools unificados y las dinámicas de desequilibrio ajustando las comisiones en respuesta a la dirección del flujo. Al mismo tiempo, el ecosistema ha avanzado hacia la “distribución oficial omnichain” de stablecoins, incluida la aparición de USDT0 como activo OFT bajo el estándar LayerZero.

La documentación de LayerZero enumera explícitamente USDT0 como compatible con OFT. En las descripciones públicas, el lanzamiento de USDT0 sigue el modelo “lock on Ethereum, mint on target networks”.

Se trata de un matiz importante. Demuestra que La lógica del LP y la del cerrojo y la acuñación se mezclan a menudo en la práctica. En algunos casos, la “natividad” no procede de los pools, sino de la creación a nivel de emisor o de infraestructura de un activo omnichain canónico.

Celer cBridge / Estado de simbiosis (mensajería y validación a través de la Red Guardian)
Estas soluciones suelen ofrecer una amplia cobertura de la cadena, pero vuelven a la misma pregunta subyacente: ¿dónde se encuentra la liquidez y quién la tiene?

Para las redes EVM, la respuesta suele reducirse a dos opciones:

los socios o inversores siembran liquidez en los fondos comunes,
o el sistema acepta límites de volumen y calidad de ruta.

Esa pregunta recurrente de quién financia la liquidez es lo que, en última instancia, define hasta dónde pueden llevar los puentes de LP a un ecosistema EVM.

Obtenga una nota de riesgo simple sobre su configuración actual del puente

Aproximación #2. Puentes de bloqueo y maceración / quema y desbloqueo

Este modelo sigue una lógica diferente a la de los pools de liquidez. En Tron, el activo original está bloqueado. En el lado de destino, se acuña una versión “puente” de ese activo. Cuando los fondos regresan, el activo puenteado se quema y el activo original se desbloquea en Tron.

No hay grupos que deban equilibrarse entre cadenas. La capacidad viene determinada por la cantidad bloqueada, no por la liquidez disponible en otro lugar. Sin embargo, hay una complejidad técnica a tener en cuenta. Dado que las redes basadas en Tron y EVM difieren significativamente, la mayoría de los puentes de bloqueo y acuñación se basan en tecnologías diferentes en cada lado. Esto aumenta la complejidad de la implementación y eleva el listón para un funcionamiento correcto, especialmente cuando se trata de stablecoins.

Ventajas del modelo de puente canónico

Sin requisito de liquidez bilateral
- Las piscinas LP no son una condición obligatoria.
- No es necesario prefinanciar la liquidez en la cadena de destino.
Capacidad previsible
- Las transferencias no fallan porque una reserva “se haya agotado”.
- La capacidad varía en función de la cantidad bloqueada.
Rápido de arrancar
- Puede lanzarse “desde cero”, incluso con un TVL pequeño.
- No depende de socios o inversores que aporten fondos por adelantado.

El coste de los activos envueltos

La contrapartida es la identidad de los activos.

En casi todos los casos, aparece un activo envuelto o puenteado en la red EVM. Esto introduce varios problemas:

Confianza y riesgo de rescate
- Los usuarios deben confiar en que el mecanismo de bloqueo y desbloqueo funcione correctamente.
- La redención depende de que el puente siga funcionando según lo previsto.
Fragmentación de “USDT”
- Múltiples versiones de USDT pueden coexistir en la misma red.
- Cada versión compite por la liquidez y la adopción.
Resistencia a la adopción de DeFi
- Los protocolos y pools pueden negarse a admitir la versión “incorrecta”.
- Las integraciones se vuelven más selectivas y fragmentadas.

En el caso de las stablecoins, este problema es especialmente grave. El mercado prefiere sistemáticamente la versión más canónica de un activo.

Perfil de riesgo de los puentes levadizos

Riesgo de validador, clave o administrador
- Si no se minimiza totalmente la confianza en el puente, el control sobre la acuñación y el desbloqueo se convierte en un supuesto crítico de confianza.
Riesgo de mensajería y coherencia
- Los puentes que dependen de la orquestación o la mensajería asíncrona pueden sufrir eventuales problemas de coherencia.
- Los fallos o retrasos en la coordinación pueden provocar atascos o estados incoherentes.

Los puentes Lock-and-Mint eliminan la presión constante de los fondos comunes de financiación, pero la sustituyen por cuestiones de confianza, identidad de los activos y aceptación a largo plazo dentro de los ecosistemas DeFi.

Enfoque #3. Ejecución basada en la intención (solucionadores y creadores de mercado)

Los sistemas basados en intenciones dan la vuelta al flujo habitual. En lugar de decirle al sistema cómo para mover los activos paso a paso, el usuario declara el resultado que desean. Por ejemplo: “Quiero USDT en la red EVM”. Los detalles de enrutamiento, intercambio y puente se dejan en manos del mercado.

Los solucionadores compiten para cumplir ese objetivo ofreciendo cotizaciones. Las normas de ejecución se aplican en la cadena, de modo que, una vez aceptada la oferta de un solucionador, la liquidación sigue las condiciones del protocolo. La atomicidad no procede de un único contrato puente, sino de las reglas que rigen cómo se emparejan y ejecutan las intenciones.

Por qué las intenciones parecen atractivas para Tron

Este modelo se ajusta al caso de uso de Tron por algunas razones concretas:

Velocidad: Los solucionadores ya disponen de inventario, por lo que la ejecución puede realizarse rápidamente sin esperar a que se reequilibren los pools.
Eficiencia del capital: La liquidez no está bloqueada en fondos comunes propiedad de protocolos. Está en manos de los creadores de mercado, que deciden cómo desplegarla.
Disposición de los gestores de la movilidad a mantener existencias: Algunos creadores de mercado están dispuestos a mantener USDT y activos relacionados si hay un rendimiento claro o un flujo de órdenes fiable, desplazando la carga de capital de la propia red.

Donde brillan los sistemas basados en la intención

Cuando la participación de los solucionadores es saludable, la ejecución basada en la intención ofrece resultados sólidos.

La mejor experiencia de usuario: Los usuarios realizan una única acción en lugar de encadenar los pasos de puente, intercambio y puente.
Potencialmente el coste más bajo: La competencia de los solucionadores puede comprimir los diferenciales, lo que hace que los intentos sean más baratos que las rutas multisalto.
Acceso a liquidez a escala de red: La cobertura crece con el mercado de solucionadores en lugar de con la liquidez propia del protocolo, lo que permite ampliarla sin tener que reconstruir los grupos en cada red.

Donde el modelo empieza a tensarse

Las mismas propiedades que hacen atractivas a las intenciones también definen sus límites.

Dependencia del solucionador: Si los solucionadores abandonan o reducen su actividad, la calidad de la ejecución disminuye inmediatamente.
Riesgo implícito de fijación de precios: Los costes están incluidos en las cotizaciones del solver, que pueden ampliarse o volverse agresivas en mercados poco activos.
Previsibilidad limitada para caudales muy grandes: La fijación de precios refleja las normas contables fijas en lugar del comportamiento de los creadores de mercado, razón por la cual los modelos mint-and-burn suelen seguir siendo los preferidos para los carriles pesados.

Perfil de riesgo de las intenciones

La ejecución basada en la intención conlleva tres riesgos principales. Hay riesgo de lentitud si los solucionadores se van. Hay riesgo de integridad de los precios si las cotizaciones se vuelven agresivas o distorsionadas en condiciones de baja liquidez. Y hay riesgo operativo, Esto significa que es necesario controlar la calidad de la ejecución y disponer de rutas alternativas en caso de que la ejecución del intento se deteriore.

Envíenos su flujo de llamadas y determinaremos las lagunas de confianza.

Enfoque #4. Modelo híbrido. Metaagregación más entrada individual

El modelo híbrido parte de una premisa diferente a la de los diseños basados en pools: no poseen liquidez.

En lugar de tratar de atraer y mantener el capital dentro de pools propiedad de protocolos, el sistema se basa en la liquidez que ya existe en redes grandes y líquidas. La propia red EVM sólo controla el punto final de entrada y salida, en lugar de toda la ruta a través de la cadena.

Este diseño evita la principal limitación de los puentes basados en LP. No hay una reserva local que agotar, porque la liquidez no se concentra en la red de destino. No hay límites de volumen impuestos por la TVL local. Las transferencias se escalan con la profundidad de los mercados externos, no con la cantidad de capital que la red consigue atraer.

La liquidez se queda donde ya existe, en las grandes cadenas, en los DEX establecidos y en los sistemas de enrutamiento maduros.

Cómo funciona en la práctica. El ejemplo de Haust

Haust es una red de capa 2 compatible con EVM construida sobre zk-rollups, con soporte nativo para la abstracción de cuentas, la ejecución entre cadenas y el enrutamiento agregado. Esto la convierte en un buen caso de referencia para el modelo híbrido, porque ya trata la entrada en la cadena cruzada como una infraestructura, no como un complemento.

En la práctica, el flujo es el siguiente:

Selección de la cadena de origen
Haust selecciona una o dos cadenas EVM en las que la liquidez de stablecoin ya es profunda y se enruta activamente. Los candidatos típicos son BNB Smart Chain, Arbitrum o Base. No se intenta replicar esa liquidez dentro de Haust.
Entrada individual en Haust
Un puente específico conecta cada cadena fuente seleccionada con Haust. El puente sigue un modelo "lock-and-mint" o equivalente de uno a uno:
- USDT está bloqueado en la cadena de origen.
- Se acuña una representación puente dentro de Haust.
Este activo es sintético a nivel de protocolo, pero tratado como canónico dentro de la propia pila DeFi de Haust.
Enrutamiento agregado ascendente
Los usuarios no interactúan directamente con el puente. En su lugar:
- El usuario entra a través de un agregador de rutas desde cualquier cadena admitida,
- El agregador dirige los fondos a la cadena de origen elegida y los normaliza en la stablecoin requerida,
- El salto final a Haust se ejecuta a través del puente de uno a uno.
Costura y ejecución de rutas
Todos los pasos se cosen en la capa de agregación. Desde la perspectiva del usuario, se trata de una única ruta. Desde la perspectiva de Haust, sólo la entrada final es propia y se hace cumplir.

La propiedad clave es que la liquidez nunca se sienta dentro de las piscinas Haust. Permanece en grandes cadenas, DEXs y agregadores. Haust controla la corrección de la ejecución en el límite e integra el resultado directamente en su capa de abstracción de monederos y cuentas.

Los equilibrios arquitectónicos

El enfoque híbrido no es gratuito.

Una contrapartida es la identidad de los activos. Un puente de uno a uno en la red de destino crea una versión de la stablecoin que es canónica dentro de esa red, pero no globalmente. Esto requiere una decisión consciente sobre qué activos se tratan como canónicos y cuáles se consideran importados o heredados.

También hay requisitos de integración. La mensajería, la indexación y el soporte de monederos deben gestionarse de forma limpia para que la experiencia de entrada y salida resulte coherente, aunque la ruta abarque varios sistemas.

Por último, puede haber limitaciones de tiempo. La compatibilidad con cadenas fuente específicas, como Tron, depende de hojas de ruta de agregadores y puentes, lo que puede introducir retrasos temporales.

Perfil de riesgo del modelo híbrido

Es importante entender que el modelo híbrido no desplaza el riesgo, sino que lo elimina.

Dependencia de los agregadores: La calidad de la ejecución depende de los agregadores externos, incluida su cobertura, lógica de enrutamiento y comportamiento de degradación.
Reducción de la exposición financiera en comparación con los modelos de LP: La red evita el coste continuo de subvencionar pools y gestionar desequilibrios.
Riesgo de calendario vinculado a la habilitación de la cadena: La disponibilidad depende del momento en que las cadenas fuente específicas sean compatibles con la infraestructura circundante.

A cambio de renunciar al control directo de la liquidez, la red gana flexibilidad y evita depender permanentemente de su propio balance.

Que no cunda el pánico. Piensa con claridad.

Este incidente no se trataba de un “hackeo” llamativo. Se trataba de una ruta de ejecución que permitía ejecutar una acción delicada sin las comprobaciones que la gente suponía que existían. Mi consejo: utiliza incidentes como este de la forma correcta. Trátalos como una auditoría forzada de tus suposiciones. Anota en qué confías, por qué confías y qué se rompe si esa confianza es errónea.

Si desea repasar su flujo exacto, paso a paso, y ver dónde puede doblarse o romperse, nuestro consultores blockchain puede revisarlo con usted antes de que la liquidez tome la decisión por usted.

Andrew Nalichaev

Experto en Blockchain y analista de DeFi

Andrew vive y respira blockchain. Ayuda a sus clientes a navegar por un espacio en constante evolución, traduciendo grandes ideas en estrategias técnicas seguras, escalables y diseñadas para su uso en el mundo real.

Seguir leyendo

Índice

Contáctenos

Reserve usted una llamada o rellene usted el siguiente formulario y nos pondremos en contacto con usted cuando hayamos procesado su solicitud.

Nombre

Empresa

Correo electrónico

Teléfono

Mensaje

Envíenos un mensaje de voz

Adjuntar documentos

Cargar archivo

Puede adjuntar 1 archivo de hasta 2 MB. Formatos de archivo válidos: pdf, jpg, jpeg, png.

Al hacer clic en Enviar, autoriza a Innowise a procesar sus datos personales de acuerdo con nuestra política de privacidad. Política de privacidad para proporcionarle información relevante. Al enviar su número de teléfono, acepta que nos pongamos en contacto con usted a través de llamadas de voz, SMS y aplicaciones de mensajería. Pueden aplicarse tarifas de llamadas, mensajes y datos.

También puede enviarnos su solicitud
a contact@innowise.com

¿Qué pasa después?

Una vez recibida y procesada su solicitud, nos pondremos en contacto con usted para detallarle las necesidades de su proyecto y firmar un acuerdo de confidencialidad. Proyecto y firmaremos un acuerdo de confidencialidad.

Tras examinar sus deseos, necesidades y expectativas, nuestro equipo elaborará una propuesta de proyecto con el alcance del trabajo, el tamaño del equipo, el plazo y los costes estimados con el alcance del trabajo, el tamaño del equipo, el tiempo y las estimaciones de costes.

Concertaremos una reunión con usted para hablar de la oferta y concretar los detalles.

Por último, firmaremos un contrato y empezaremos a trabajar en su proyecto de inmediato.