"Integre una billetera": ¿qué capa está vendiendo realmente?
Un único mensaje Telegram que solicite "integrar una billetera" puede significar trabajo frontend, lógica de firma o autorización de contrato. Leer primero las palabras de acción es mejor que enviar una cotización comercial a ciegas.
Ya has cotizado un precio como este antes.
Un equipo de proyecto pregunta en un chat grupal: “¿Se puede integrar una billetera?” Devuelve una cotización comercial de integración frontend. Tres días después, te dicen que han encontrado a otra persona, no por el precio, sino porque lo que realmente necesitaban no era “conectar una billetera” en absoluto. Fue “los usuarios aprobaron la asignación sin leerla y tenemos que arreglar eso”. Citaste la capa que no era la que estaba sufriendo.
Esta escena no es un único trato cerrado. Es un patrón que los pares de ventas de valores mencionan cuando se recuerdan entre sí que la palabra “integrar” significa trabajo diferente para diferentes personas (escenario compuesto ilustrativo, no datos a nivel de proyecto).
Si recibieras ese mensaje, ¿por dónde empezarías a leer?
Tres acciones, un mensaje, tres caminos diferentes
Imagine que ve esto en el grupo de discusión técnica de un proyecto sobre Telegram:
Ilustrativo/compuesto Telegram mensaje de grupo — @alex_build: Nuestra DApp necesita integración de billetera. Los usuarios ingresan a través de WalletConnect y firman transacciones. También necesitamos el mensaje de confirmación en el lado de la aprobación: alguien aprobó sin verificar la asignación antes. Los equipos que puedan terminar en dos semanas, envíanos un mensaje privado. Presupuesto negociable.
Tres líneas, tres palabras de acción: connect (WalletConnect), sign (firma de transacciones), approve (solicitud de confirmación + asignación).
Estas no son tres maneras de decir lo mismo. Apuntan a diferentes capas técnicas. Se asignan a diferentes rangos de cotizaciones comerciales. También le dicen en qué etapa se encuentra el equipo del proyecto. No es necesario que se encargue de los tres usted mismo. Necesitas ver que no son una sola cosa.
“Conectar”: el punto de entrada, no la respuesta
WalletConnect es un protocolo de código abierto que establece un vínculo entre una billetera telefónica y una DApp (aplicación descentralizada) basada en la web. Un usuario escanea un código QR o toca un mensaje de autorización en su teléfono, y la DApp puede leer la dirección de la billetera y enviar solicitudes de transacción. Esta capa no toca contratos inteligentes y no escribe nada en la cadena. Es pura integración frontend.
Si ve “WalletConnect” y una cotización comercial, su cotización comercial para el trabajo frontend. Pero en esta escena ilustrativa, el problema más urgente del equipo del proyecto no es ese.
El valor de “conectar” no está en la cotización comercial. Te ayuda a juzgar la composición del equipo. Si la respuesta es “nuestra persona de frontend ya está en esto”, alguien se está encargando de esa parte; puedes saltearla y hablar sobre el resto. Si la respuesta es “aún no hemos encontrado a nadie, queremos solucionarlo entre todos”, es posible que estés ante un equipo sin capacidad de frontend. En ese caso, es posible que lo que necesiten no sea una solución de seguridad primero; puede ser una referencia a alguien que pueda construir esa capa o una comprensión más clara de si realmente están buscando un desarrollador frontend en este momento.
En este mensaje, “conectar” es el punto de entrada. No es la respuesta.
“Firmar”: lo que ve el usuario antes de presionar confirmar
La firma es el acto criptográfico de aprobar una transacción con una clave privada. Una vez que una transacción firmada se transmite a la cadena, revertirla es casi imposible.
El problema es lo que ve el usuario en el momento en que toca confirmar. Si la DApp envía una solicitud de firma a la billetera sin analizar los parámetros, el usuario ve una cadena hexadecimal, no una línea legible como “Enviar 100 USDT a 0xABC”. Tocar para confirmar el contenido que no comprende es una firma ciega. La solicitud de firma de una DApp legítima y la solicitud maliciosa de un sitio de phishing parecen idénticas en la ventana emergente de billetera. El usuario no puede diferenciarlos.
Si sigue esta dirección, la entrada no reescribe su código de interfaz. Es una pregunta que puedes formular en una sola frase: “¿Pueden tus usuarios ver el importe y el destinatario antes de confirmar?” Si no pueden responder, usted decide: ¿esto entra dentro del trabajo de auditoría de firmas que ofrece?
“Aprobar”: el agujero en el que ya entró el usuario
Esa última línea, “alguien aprobó sin verificar antes la asignación”, es la parte del mensaje que vale la pena seguir más de cerca.
La aprobación es el mecanismo mediante el cual un usuario autoriza a una dirección de contrato específica a mover tokens de su billetera. El método approve del estándar ERC-20, cuando se llama sin límite (establecido en el máximo uint256), significa que el contrato aprobado puede agotar el saldo total del token en una sola transacción. Muchos incidentes de phishing conocidos se remontan exactamente a esto.
El equipo del proyecto ve el problema. Por eso buscan una solución. Pero la “advertencia de gran cantidad” que mencionan es una copia del frontend: una línea roja de texto que aparece para advertir al usuario. Algunos usuarios lo notarán. Los que causaron el primer incidente pueden hacer clic en él de la misma manera.
Una solución más exhaustiva se encuentra en la capa del contrato: limite la asignación de aprobación al monto realmente necesario o use increaseAllowance / decreaseAllowance para ajustarlo dinámicamente. Un patrón más sutil es el Permit de EIP-2612: aprobación fuera de la cadena que permite al usuario firmar fuera de la cadena y la asignación se otorga sin que el usuario vea una transacción dentro de la cadena.
En este mensaje simulado, el problema más urgente del equipo del proyecto se encuentra en la capa de aprobación. Los comentarios de los usuarios ya existen. El problema tiene una forma concreta. Éste no es un requisito “preventivo”: es un requisito con consecuencias visibles.
Dos números que necesitas antes de tu cotización comercial
El mensaje grupal le da dirección. No le da una base para cotización comercial. En el momento en que se vio este mensaje, dos datos críticos no son confirmables solo por parte del grupo.
En primer lugar, ¿qué significa aquí realmente “cantidad elevada”? Una “cantidad alta” para una transferencia de tokens de rutina y una “cantidad alta” para un puente entre cadenas (un protocolo que mueve activos entre diferentes cadenas de bloques) no son diferentes en un factor de dos. Pueden diferir en dos o tres órdenes de magnitud. Necesitaría ver los parámetros del contrato, o al menos conocer el tipo de token y el caso de uso, antes de poder juzgar a qué se refiere “alto”. Otra posibilidad: el equipo del proyecto tampoco tiene una cifra clara. Recibieron comentarios de los usuarios, pero aún no los han desglosado a nivel cuantitativo.
En segundo lugar, ¿de dónde viene el plazo de dos semanas? Si proviene de un compromiso de hoja de ruta, es posible que una auditoría de seguridad no esté incluida en esta versión del contrato; es posible que simplemente estén buscando contratistas frontales. Si se trata de un requisito de un socio, ese socio puede tener estándares de seguridad específicos con los que usted debe alinearse. El primer escenario apunta su seguimiento hacia “la revisión de seguridad más pequeña que podamos finalizar dentro de un período de dos semanas”. El segundo escenario apunta hacia una propuesta más completa.
El chat grupal te brinda el punto de entrada. Sin esos dos números no se puede cotizar comercialmente.
Ya sabes qué preguntar primero
Mire el mensaje nuevamente. El remitente está desconectado ahora. No tienes prisa por responder.
Lo que lee ya no es “una solicitud de integración de billetera”. “Connect” te informa sobre la etapa del equipo. “Signo” señala un punto ciego en la interacción del usuario. “Aprobar” muestra el agujero en el que ya entró un usuario. No es necesario cubrir los tres a la vez. Eliges una capa y haces la primera pregunta.
En esta escena simulada, la capa de aprobación es el punto de partida más claro porque los comentarios de los usuarios ya están sobre la mesa. Puede preguntar: “¿Cómo está configurando la asignación de aprobación en este momento?” Si la respuesta es “sin límite, directo al máximo”, esa es la señal de seguimiento más clara que puede obtener. Si la respuesta es “No estoy seguro de qué patrón estamos usando”, falta alguien en la cadena de decisión; el primer paso es confirmar quién es el contacto.
También puedes hacer cualquiera de las otras dos preguntas, dependiendo de en qué eres más fuerte. “¿Pueden los usuarios ver el monto antes de firmar?” abre la puerta de la auditoría de firmas. “¿Su propia interfaz maneja la integración de WalletConnect?” le ayuda a medir la integridad del equipo.
Cualquiera que sea la pregunta que elijas, el objetivo no es terminar las tres capas en una sola conversación. Es utilizar la primera respuesta para decidir la dirección. Lo que te responden determina si profundizas en esta capa o pasas a otra.
Cuando vuelve a abrir el contexto guardado para este mensaje, verá que el remitente preguntó sobre las pruebas del contrato en un grupo técnico vecino la semana pasada, y la referencia “aprobado sin verificación” esta vez es una continuación del mismo proyecto de billetera. La historia y el mensaje actual van juntos. No se requiere excavación.
Ya sabes qué preguntar primero.
Las conversaciones de mercado y riesgo son evidencia de apoyo
La función principal de Top Prospect es generar leads en Telegram. Las conversaciones de mercado y riesgo pueden aportar contexto a un candidato, pero no se convierten automáticamente en un incidente, tendencia u oportunidad de venta verificados.
