Request

¿Qué es Request?

Request es un protocolo de código abierto para solicitudes de pago cripto y conciliación que permite a una empresa o usuario crear una solicitud de pago firmada similar a una factura, almacenar los datos de la solicitud en una infraestructura descentralizada y hacer coincidir los pagos posteriores on-chain con esa solicitud sin ceder la custodia de los fondos a un procesador de pagos. Su problema central no es “mover tokens” en abstracto, algo que muchas wallets y pasarelas de pago ya hacen, sino crear un objeto contable verificable alrededor del pago: quién lo solicitó, qué importe se debía, qué moneda o unidad de cuenta se utilizó, dónde se produjo la liquidación y si el pago puede detectarse y conciliarse de forma automática.

La ventaja práctica del protocolo radica por tanto en la integración con los flujos de trabajo más que en la capa base de consenso: Request combina solicitudes de pago firmadas, almacenamiento en IPFS, anclaje on-chain de CIDs, eventos de referencia de pago, webhooks, herramientas de API y enrutamiento de pagos multichain para conformar un primitivo de back-office financiero, tal como se describe en la documentación de Request Network y en su visión general del protocolo. docs.request.network

Request no es una Layer 1 dominante, ni un rollup, ni un gran mercado monetario DeFi; es una capa de aplicación especializada en pagos y herramientas para desarrolladores, construida en torno a la facturación cripto, la detección de pagos y la conciliación.

A finales de mayo de 2026, los proveedores de datos de mercado situaban a REQ en el universo de tokens de baja a media capitalización, en lugar de entre los criptoactivos sistémicamente importantes: CoinMarketCap mostraba a Request cerca del puesto n.º 384, mientras que CoinGecko y DeFiLlama informaban capitalizaciones bursátiles que variaban de forma significativa debido a distintas metodologías de suministro circulante y de calendario. Para este tipo de protocolo, el TVL es una métrica limitada: la Request Network page de DeFiLlama muestra datos del tesoro y del mercado del token, en lugar de una cifra convencional de TVL de préstamos/AMM, lo que es coherente con el papel de Request como infraestructura de pagos en vez de como un pool de depósitos de usuarios. Sus indicadores de escala más relevantes son el volumen de pagos y la actividad empresarial procesada; el sitio web de la fundación afirma más de 2.000 millones de dólares en volumen procesado y una amplia cobertura de stablecoins, mientras que el panel comunitario Request Activity Dashboard sigue los pagos diarios y el volumen de pagos, pero no proporciona un conjunto limpio de usuarios DAU/MAU comparable al de wallets de consumo o exchanges. (coinmarketcap.com)

¿Quién fundó Request y cuándo?

Request fue fundada en 2017 por Christophe Lassuyt y Etienne Tatur, ambos vinculados al anterior proyecto fintech MONEYTIS; Y Combinator lista a Request Network como una empresa del Winter 2017 con sede en París, con Lassuyt como Founder/CFO y Tatur como Founder/CTO. El contexto de lanzamiento es relevante: REQ surgió durante el ciclo de ICO de 2017, cuando muchos proyectos intentaron generalizar Ethereum más allá de las transferencias de tokens hacia la contabilidad, el comercio y la automatización empresarial. Las bases de datos históricas de ICO sitúan la venta del token en octubre de 2017, con un suministro inicial de aproximadamente mil millones de REQ, aunque el suministro actual es menor tras quemas y cambios en la contabilidad del token. Esa “añada” supone tanto una ventaja como una carga: Request ha sobrevivido a varios ciclos de mercado y ha conservado software funcional, pero también arrastra el lastre reputacional común a los proyectos de utility tokens de 2017, cuyos relatos iniciales a menudo superaron la adopción a corto plazo. (ycombinator.com)

La narrativa del proyecto se ha ido acotando con el tiempo.

El planteamiento original era una amplia red de pagos descentralizada para facturas, trazabilidad de auditoría, cumplimiento de la normativa comercial y solicitudes de pago globales; el énfasis actual del producto es más operativo y menos ideológico, centrado en pagos cripto basados en API, facturación on-chain, detección de pagos, enrutamiento entre cadenas, pagos por lotes, pagos recurrentes y conciliación.

Esa evolución es visible en las actualizaciones de la fundación en 2025: Request lanzó la API V2, pagos parciales, webhooks mejorados, flujos de trabajo cripto-a-fiat, pagos por lotes y funcionalidad de pagos cross-chain, en lugar de intentar convertirse en una nueva blockchain de propósito general. En términos institucionales, el giro va de “PayPal en blockchain” hacia middleware para equipos financieros, proveedores de servicios de pago y empresas cripto-nativas que necesitan registros de pago estructurados en múltiples cadenas. request.network

¿Cómo funciona Request Network?

Request no tiene su propio mecanismo de consenso de prueba de trabajo, prueba de participación, DAG, conjunto de validadores, secuenciador ni rollup. Es un protocolo híbrido off-chain/on-chain que persiste la mayor parte del contenido de las solicitudes en IPFS, ancla el identificador de contenido de IPFS en la blockchain y procesa los pagos mediante contratos inteligentes en las cadenas de liquidación compatibles.

La documentación indica que las solicitudes se crean almacenando CIDs en Gnosis Chain, mientras que los pagos pueden realizarse en más de 20 cadenas EVM-compatibles o en NEAR; el saldo de la solicitud se calcula después indexando los eventos de pago on-chain asociados a una referencia de pago derivada. En términos técnicos, Request es un protocolo de capa de aplicación y una API para desarrolladores que hereda liveness y finalidad de redes externas como Gnosis, Ethereum, Base, Arbitrum, Optimism, Polygon y otras, en lugar de proporcionar su propio presupuesto de seguridad de capa base. docs.request.network

El mecanismo distintivo del protocolo es la referencia de pago. En el modelo recomendado basado en referencias, un identificador único derivado de los datos de la solicitud vincula un pago en blockchain con la factura o solicitud de pago subyacente; los contratos proxy reenvían los fondos al receptor y emiten eventos que contienen el importe del pago y la referencia, mientras que los subgraphs indexan esos eventos para su posterior conciliación.

El sistema no utiliza sharding ni ZK-rollups como primitivos nativos de escalado, y su modelo de verificación se parece más a una liquidación indexada por eventos más metadatos de solicitudes firmadas que a la verificación criptográfica de pruebas de rollup. Los Request Nodes proporcionan una puerta de enlace entre IPFS, contratos inteligentes y The Graph; la fundación opera nodos para comodidad de los desarrolladores, pero aconseja a los constructores en producción que ejecuten su propio nodo, lo que es importante porque la dependencia de puertas de enlace y APIs alojadas por la fundación es un vector de centralización incluso si los datos de las solicitudes y los contratos subyacentes son de código abierto.

Las solicitudes privadas añaden cifrado asimétrico y AES: el contenido de la solicitud se cifra con una clave AES y esa clave se cifra para la clave pública de cada parte interesada antes de persistirse en IPFS. docs.request.network

¿Cuáles son los tokenomics de REQ?

REQ es un token ERC-20 lanzado originalmente con aproximadamente mil millones de unidades, y su perfil de suministro se entiende mejor como mayoritariamente fijo con un mecanismo de quema modesto, en lugar de como un activo con emisiones inflacionarias. A finales de mayo de 2026, Etherscan mostraba el contrato del token ERC-20 en 0x8f8221afbb33998d8584a2b05749ba73c37a938a con un suministro máximo total de unos 999,416 millones de REQ, mientras que CoinMarketCap informaba de un suministro circulante de alrededor de 796,7 millones de REQ y CoinGecko mostraba una cifra de suministro circulante diferente, lo que subraya que el suministro “circulante” depende de cómo se clasifiquen las reservas, los bridges y los saldos inactivos.

El panel comunitario indicaba aproximadamente 583.000 REQ quemados, una pequeña fracción del suministro original, por lo que el efecto deflacionario existe pero no es lo bastante grande por sí mismo como para constituir la tesis central de inversión. (etherscan.io)

La captura de valor de REQ es indirecta y debe tratarse con cautela.

La documentación identifica contratos del token REQ y del mecanismo de quema que pueden bloquear, puentear y quemar REQ cuando se almacenan solicitudes, mientras que la documentación de la API describe una comisión de protocolo de 5 puntos básicos sobre los pagos procesados a través de la API, limitada a unos 25 $ o 25 € para las principales stablecoins respaldadas en USD y EUR.

Esto no equivale a un rendimiento convencional de staking PoS, y Request no está asegurado mediante staking de REQ de la forma en que Ethereum está asegurado por validadores de ETH. Algunas descripciones de terceros presentan la utilidad de REQ en términos de anti-spam, gobernanza, staking, descuentos e independencia, pero la documentación técnica oficial actual no presenta un gran mercado líquido de staking, un calendario de recompensas para validadores ni un programa recurrente de emisiones para los tenedores de REQ.

La lectura de tokenomics más defendible es, por tanto, que REQ es un token heredado de tipo utilidad/gobernanza con un suministro limitado y elementos de quema vinculados al uso, mientras que la mayor parte del uso del protocolo a corto plazo puede acumularse de forma más directa en la capa de producto y en los servicios de API operados por la fundación que automáticamente en los tenedores pasivos del token. docs.request.network

¿Quién está utilizando Request?

La diferencia entre el trading especulativo de REQ y la utilidad real de Request Network es importante. El volumen del token en los exchanges refleja la liquidez de mercado y la rotación de inversores, mientras que el uso del protocolo se mide mejor por las solicitudes creadas, los pagos detectados, el volumen de pagos, la adopción de la API y la integración en los flujos de trabajo financieros.

La propia actualización del ecosistema de Request de mayo de 2025 trasladó explícitamente su énfasis de reporte desde los recuentos genéricos de transacciones al “número de pagos”, porque la creación, aprobación, rechazo de facturas y otras acciones pueden inflar las métricas de transacciones sin representar una actividad real de liquidación.

El panel comunitario también informa del volumen de pagos y del recuento de pagos en las cadenas compatibles, pero estos son indicadores diarios volátiles y no deben interpretarse como cifras estables de usuarios activos. Por sector, Request se sitúa en la intersección entre pagos cripto, liquidación con stablecoins, facturación, nóminas, contabilidad y tesorería, más que en la liquidez DeFi, el gaming o la especulación con NFT. request.network

La evidencia de adopción más sólida son las integraciones con productos identificables de finanzas u operaciones cripto, no los recuentos anónimos de wallets. Request’s Las actualizaciones del ecosistema de 2025 mencionaron a constructores activos como Animal Social Club, intrXn, 0 Finance, Allora y Request Finance, mientras que actualizaciones anteriores también hacían referencia a Huma Finance, BSOS, Joba Network y otros participantes del ecosistema.

En octubre de 2025, Kryptos anunció que había integrado la API de Request Network para impulsar la facturación dentro de Kryptos Enterprise, con Request proporcionando creación de facturas, liquidación on-chain, webhooks de eventos y conciliación; ese anuncio también citaba la propia instantánea de adopción de Kryptos de más de 200.000 usuarios registrados, más de 50 empresas Web3 incorporadas en fases tempranas y miles de integraciones con wallets, CEX, DeFi y cadenas. Estas cifras deben interpretarse como escala a nivel de plataforma asociada más que como adopción directa por parte de tenedores de REQ, pero siguen siendo más sustanciales que los rumores de alianzas sin fuentes. request.network

¿Cuáles son los riesgos y desafíos para Request?

El riesgo regulatorio para Request es más sutil que para un exchange, un protocolo de préstamos o un mezclador de privacidad, pero no es nulo. Búsquedas públicas y texto de demandas de la SEC disponibles a través de los resultados de búsqueda no mostraron a REQ como un token mencionado en las principales demandas de 2023 de la SEC contra Coinbase o Binance, y no hay una demanda activa ampliamente reportada de la SEC específicamente contra Request Network a finales de mayo de 2026.

Eso no equivale a un puerto seguro regulatorio. REQ se vendió en la era de las ICO de 2017, se negocia en mercados secundarios y los reguladores estadounidenses históricamente han examinado con detenimiento los tokens que se distribuyeron para financiar el desarrollo de protocolos.

El negocio de pagos del protocolo también roza cuestiones de AML, filtros de sanciones, KYC, regulación de stablecoins, transmisión de dinero y declaración de impuestos, especialmente donde Request admite liquidación cripto-a-fiat, filtrado de wallets y facturación empresarial. El riesgo de centralización también es práctico más que teórico: la API operada por la fundación, el panel, la página de pago segura, los Request Nodes y la infraestructura de detección de pagos pueden generar una dependencia operativa incluso si los contratos, el SDK y el modelo de datos siguen siendo de código abierto. sec.gov

La competencia es intensa porque el problema de cara al usuario que aborda Request puede atacarse desde varias direcciones. Los procesadores de pago tradicionales están añadiendo liquidación con stablecoins; los procesadores de pago cripto centralizados pueden ofrecer cumplimiento normativo, políticas de contracargos, rampas de salida a fiat y paneles de control para comercios; las wallets y los exchanges pueden añadir enlaces de pago directamente; y los proveedores de contabilidad cripto para empresas pueden incorporar la conciliación de facturas en sus propios stacks. Dentro de Web3, productos tipo Safe o Coinbase Commerce, herramientas de tesorería multisig, plataformas de nóminas, proveedores de checkout con stablecoins, paneles de contabilidad on-chain y APIs de enrutamiento cross-chain pueden cada uno absorber partes del flujo de trabajo de Request.

La amenaza económica es que la comisión de 5 puntos básicos de Request y su vinculación a la quema de REQ podrían verse comprimidas por la competencia si el enrutamiento de pagos y la conciliación se convierten en funciones de API comoditizadas. Su capacidad defensiva depende de si los desarrolladores tratan el objeto de factura de Request, su estándar de referencia de pagos y sus herramientas de conciliación como una capa de integración duradera y no solo como un envoltorio de conveniencia fácilmente reemplazable. docs.request.network

¿Cuál es la perspectiva futura para Request?

La hoja de ruta de Request a corto plazo parece centrarse en la profundidad de producto más que en la reinvención de la capa de consenso. Documentación verificada de 2025 y principios de 2026 apunta a la migración a la API V2, pagos con stablecoins cross-chain, pagos por lotes, pagos parciales, flujos cripto-a-fiat, pagos recurrentes, personalización de comisiones, mejoras en el cambio de wallets y redes, un seguimiento de pagos más amplio y compatibilidad con más de 25 cadenas a través de la superficie de la API. Los pagos cross-chain son particularmente importantes porque abordan un punto de dolor operativo real: los pagadores pueden tener USDT en Optimism mientras las facturas solicitan USDC en Base, y los equipos financieros no quieren gestionar puentes, swaps, tokens de gas y conciliación de forma manual.

La documentación de Request indica que los pagos cross-chain admiten USDC (USDC), USDT (USDT) y DAI (DAI) en Ethereum (ETH), Arbitrum One (ARB), Base y OP Mainnet (OP), con rutas clasificadas según las comisiones de transacción y la velocidad de procesamiento; la página pública del producto cross-chain declara que Request utiliza el enrutamiento de LI.FI manteniendo una lógica unificada de detección de pagos y webhooks. request.network

El obstáculo estructural es la densidad de adopción. Request no necesita superar a Ethereum, Visa, Stripe o a todos los procesadores de stablecoins en un sentido amplio; necesita que suficientes aplicaciones empresariales, productos de contabilidad, PSP y equipos financieros cripto-nativos se estandaricen en torno a su capa de solicitud y conciliación. El escenario bajista es que los pagos con stablecoins se integren directamente en wallets, bancos y APIs de exchanges, dejando a Request como una pequeña herramienta para desarrolladores con una captación limitada para el token.

El escenario alcista es más moderado que una narrativa de precio: si la liquidación con stablecoins sigue expandiéndose y los equipos financieros requieren registros de pagos auditables, no custodiados y multichain, la combinación de Request de solicitudes firmadas, referencias de pago, webhooks, flujos por lotes, pagos recurrentes y enrutamiento cross-chain podría seguir siendo infraestructura viable.

El futuro del proyecto depende por tanto menos de la demanda especulativa de REQ y más de si Request puede convertir su larga trayectoria operativa en integraciones duraderas, métricas de uso transparentes y un modelo de token cuya vinculación económica con pagos reales sea lo bastante clara como para que usuarios institucionales y tenedores de tokens puedan respaldarla.