Resumen
UniCrypt, ahora rebautizado como UNCX Network, es un conjunto de herramientas DeFi multicadena para equipos de tokens. Sus productos principales incluyen bloqueadores de liquidez, calendarios de vesting de tokens, programas de recompensas de staking y farming, y un acuñador de tokens. El proyecto se lanzó en 2020 y su token de utilidad de gobernanza cotiza con el ticker UNCX (referencias más antiguas usan UNC).
Si buscaste "unicrypt" porque estás integrándote con sus contratos, la pregunta práctica generalmente no es qué hace la marca, sino cómo leer y escribir en sus contratos de manera confiable en Ethereum, BNB Chain, Base, Arbitrum, Solana, Polygon y otras redes compatibles. Eso significa un endpoint JSON-RPC confiable, configuraciones de cadena correctas y una forma de depurar transacciones fallidas.
Esta página explica la superficie del producto UNCX desde el punto de vista de un desarrollador, y luego se centra en las decisiones de infraestructura: qué métodos RPC necesitas, cómo manejar lecturas multicadena y cuándo un endpoint público compartido es suficiente frente a cuándo un nodo dedicado tiene más sentido. OnFinality proporciona acceso a la API RPC e infraestructura de nodos dedicados para muchas de las redes que UNCX admite; consulta redes RPC compatibles y precios de RPC antes de comprometerte con una arquitectura.
Puntos clave
- UniCrypt ahora se llama UNCX Network; el ticker del token es UNCX, con referencias más antiguas que usan UNC.
- Los productos de UNCX están basados en contratos: bloqueadores de liquidez, calendarios de vesting, staking/farming y un acuñador de tokens.
- Las integraciones son multicadena por defecto, por lo que tu capa RPC debe manejar varias cadenas EVM además de Solana.
- La mayoría de las rutas de lectura necesitan eth_call, eth_getLogs y estado de archivo para registros históricos de bloqueos y vesting.
- Las rutas de escritura necesitan un envío de transacciones confiable y razones de reversión claras, que es donde se nota la calidad del endpoint.
- Una API RPC compartida es suficiente para paneles y prototipos; los nodos dedicados ayudan cuando consultas logs intensivamente o necesitas un rendimiento predecible.
- Siempre confirma las direcciones de los contratos y las redes compatibles desde la documentación oficial de UNCX antes de integrarlas en producción.
En qué se convirtió UniCrypt y por qué les importa a los desarrolladores
UniCrypt comenzó como un conjunto de utilidades DeFi y ahora se presenta como UNCX Network. El conjunto de productos está dirigido a equipos de tokens: bloquear liquidez para que los tenedores puedan verificar un compromiso, programar el vesting de tokens para asignaciones de equipo e inversores, financiar recompensas de staking o farming de LP, y acuñar tokens sin escribir contratos desde cero.
Para los desarrolladores, el detalle importante es que estos son productos en cadena. Un bloqueador es un contrato que mantiene tokens LP hasta una fecha de desbloqueo. Un calendario de vesting es un contrato o registro que libera tokens con el tiempo. Los programas de staking y farming distribuyen recompensas de un presupuesto que el proyecto financia. Si estás construyendo un panel, una verificación de cumplimiento o una integración que lee estos registros, estás haciendo llamadas a contratos, no consumiendo una API REST.
Eso replantea la búsqueda. Alguien que escribe "unicrypt" puede querer la descripción general del producto, pero un integrador necesita saber en qué cadenas viven los contratos, qué métodos llamar y qué tipo de endpoint RPC no fallará cuando consulte logs de eventos en miles de bloques.
- Bloqueadores de liquidez: mantienen tokens LP durante una duración elegida y exponen un registro de bloqueo público.
- Vesting de tokens: calendarios de liberación con cliffs, lineales y escalonados para los beneficiarios.
- Staking y farming: presupuestos de recompensas distribuidos a tenedores de tokens o LPs.
- Acuñador de tokens: crea y despliega un token sin código personalizado.
- Huella multicadena: Ethereum, BNB Chain, Base, Arbitrum, Solana, Polygon y otras, con disponibilidad de productos que varía según la red.
Guía de decisión: ¿API RPC compartida o nodo dedicado?
Antes de elegir un endpoint, describe tu carga de trabajo con honestidad. Un panel estilo explorador de bloques que lee unos pocos registros de bloqueo por página es muy diferente de un indexador que escanea cada evento de bloqueador en tres cadenas y almacena estado histórico.
Usa la tabla a continuación para mapear tu patrón de integración a una elección de infraestructura. El objetivo no es comprar el plan más grande; es evitar el modo de falla en el que tu ruta de lectura está bien pero tus consultas de logs expiran o tus escrituras se atascan detrás de los límites de velocidad.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Patrón de lectura | eth_call ocasional para estado de bloqueo o vesting versus eth_getLogs continuo en rangos de bloques amplios. | La indexación intensiva en logs es la razón más común por la que un endpoint compartido se vuelve problemático. |
| Estado histórico | Si necesitas saldos o estado de contrato en un bloque pasado, lo que requiere acceso a archivo. | Los nodos que no son de archivo podan el estado antiguo y fallarán en consultas históricas. |
| Frecuencia de escritura | Con qué frecuencia envías transacciones de bloqueo, vesting o staking y cómo manejas el nonce y el reemplazo. | Las ráfagas de escritura exponen rápidamente la confiabilidad del endpoint y el comportamiento del mempool. |
| Cantidad de cadenas | De cuántas redes compatibles con UNCX lees y si necesitas una interfaz consistente. | Las lecturas multicadena multiplican el volumen de solicitudes y la deriva de configuración. |
| Capacidad del equipo | Si quieres ejecutar y monitorear nodos o consumir un endpoint gestionado. | El autohospedaje traslada el trabajo de disponibilidad y actualización a tu equipo. |
Configuraciones de cadena y patrones de endpoint
Los contratos de UNCX están desplegados en varias redes EVM además de Solana, por lo que tu configuración es inherentemente multicadena. Para cadenas EVM, necesitas el ID de cadena, una URL JSON-RPC, el símbolo de la moneda nativa y un explorador de bloques para verificación. Para Solana, necesitas una URL RPC HTTP y, si te suscribes a cambios de cuenta, una URL WebSocket.
OnFinality publica configuraciones específicas de red en cada página de red compatible. Comienza desde redes RPC compatibles, abre la cadena que necesitas y copia el ID de cadena y el endpoint de esa página en lugar de una lista de terceros que puede estar desactualizada. El patrón a continuación muestra cómo se suele cablear un cliente multicadena; reemplaza el marcador de posición con el endpoint de la página de red correspondiente.
- Mantén un objeto de configuración por cadena con chainId, rpcUrl y explorerUrl.
- Almacena las direcciones de los contratos por cadena; no asumas la misma dirección en todas las redes.
- Para Solana, mantén las URL HTTP y WebSocket separadas.
- Registra el ID de cadena al inicio para que un endpoint mal configurado falle de forma ruidosa.
Métodos que realmente llamarás
La mayoría de las integraciones con UNCX caen en dos categorías: leer registros de bloqueo y vesting, y enviar transacciones que los crean o interactúan con ellos. El lado de lectura está dominado por eth_call para funciones de vista y eth_getLogs para eventos como creación de bloqueo o desbloqueo. El lado de escritura necesita estimación de gas, gestión de nonce y una forma de decodificar reversiones.
Si estás indexando, planifica los límites de eth_getLogs. Muchos proveedores limitan el rango de bloques o el número de resultados por solicitud, por lo que tu indexador debe paginar a través de rangos y guardar puntos de control del progreso. Si necesitas estado en un bloque histórico, confirma el acceso a archivo antes de diseñar en torno a él.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| eth_call | Funciones de vista para detalles de bloqueo, tiempo de desbloqueo, calendario de vesting y presupuesto de recompensas. | Esta es la ruta de lectura principal para paneles y páginas de verificación. |
| eth_getLogs | Temas de eventos para creación de bloqueo, desbloqueo, liberación de vesting y recompensas de staking. | Los indexadores dependen de ello; los límites de rango determinan tu estrategia de paginación. |
| eth_getTransactionReceipt | Estado y logs después de una escritura, más datos de reversión en caso de fallo. | Confirma si una transacción de bloqueo o vesting realmente tuvo éxito. |
| eth_estimateGas | Gas para llamadas de bloqueo, vesting y staking antes del envío. | Evita transacciones fallidas por gas subestimado. |
| eth_blockNumber | Cabeza actual para puntos de control y verificaciones de frescura. | Ayuda a detectar un endpoint retrasado antes de que corrompa tu índice. |
Ejemplo: leer un registro de bloqueo con viem
El fragmento a continuación muestra la forma de una integración de lectura. Utiliza un cliente público, una configuración por cadena y un ABI de contrato que proporcionas desde la documentación de UNCX. El valor del endpoint es un marcador de posición a propósito: copia la URL real desde la página de red de OnFinality para la cadena que estás apuntando.
Mantén el ABI y la dirección en una configuración versionada. Cuando UNCX actualice un contrato, querrás un único lugar para cambiarlo y una prueba que falle si la dirección falta para una cadena.
- Usa una fábrica de clientes por cadena en lugar de un cliente global.
- Envuelve las lecturas en un tiempo de espera y reintenta con retroceso exponencial.
- Cachea brevemente los registros de bloqueo; solo cambian al desbloquear o transferir.
- Verifica que el ID de cadena devuelto coincida con tu configuración al inicio.
Modos de falla y cómo depurarlos
La mayoría de los errores de integración con los contratos de UNCX no son exóticos. Son direcciones incorrectas, cadenas incorrectas, estado podado o límites de rango de logs. La tabla a continuación asigna síntomas a causas probables para que puedas depurar en orden en lugar de adivinar.
Cuando una escritura falla, decodifica la razón de reversión antes de reintentar. Una reversión generalmente significa que falló una regla de negocio, como una fecha de desbloqueo en el pasado o una asignación insuficiente, no que el endpoint esté roto. Reintentar una reversión determinista solo quema gas y tiempo.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| La llamada devuelve datos vacíos | Dirección del contrato e ID de cadena. | Una dirección válida en la cadena incorrecta no devuelve nada. |
| La consulta histórica falla | Acceso a archivo en el endpoint. | El estado podado no puede responder lecturas de bloques pasados. |
| eth_getLogs expira | Tamaño del rango de bloques y límites del proveedor. | Se requiere paginación en la mayoría de los endpoints compartidos. |
| Transacción atascada pendiente | Nonce, precio del gas y visibilidad del mempool. | El reemplazo requiere ver la transacción pendiente. |
| Lecturas inconsistentes entre llamadas | Si las solicitudes llegan a diferentes backends o cabezas retrasadas. | Fija las lecturas a un número de bloque cuando la consistencia importa. |
Dónde encaja OnFinality
OnFinality proporciona acceso a la API RPC e infraestructura de nodos dedicados para una variedad de redes, incluidas varias que UNCX admite. Si estás construyendo un panel, un indexador o un flujo de transacciones alrededor de contratos de bloqueo y vesting, puedes comenzar con la API RPC compartida y pasar a un nodo dedicado cuando tu volumen de logs o frecuencia de escritura crezca.
Consulta redes RPC compatibles para las cadenas que necesitas, revisa precios de RPC para dimensionar el plan y lee la guía de selección de proveedores si estás comparando opciones. Para equipos que desean capacidad aislada y su propia configuración, los nodos dedicados son el siguiente paso.
- Comienza con un endpoint compartido para prototipos y paneles de bajo volumen.
- Pasa a capacidad dedicada cuando la indexación de logs o las ráfagas de escritura dominen.
- Confirma las necesidades de archivo y trace antes de comprometerte con un plan.
- Mantén un endpoint de respaldo configurado para failover.
Preguntas frecuentes
¿UniCrypt es lo mismo que UNCX Network?
UNCX Network es la marca actual del proyecto anteriormente conocido como UniCrypt. El ticker del token es UNCX, y las referencias más antiguas pueden usar UNC. La disponibilidad de productos varía según la red, así que consulta el sitio oficial para la lista actual.
¿UniCrypt tiene una API REST para registros de bloqueo?
Los registros de bloqueo y vesting son estado de contrato en cadena. Los integradores normalmente los leen a través de métodos JSON-RPC como eth_call y eth_getLogs en lugar de una API REST dedicada. Cualquier panel o indexador que veas está construido sobre esas llamadas RPC.
¿Qué métodos RPC necesito para una integración con UNCX?
Para lecturas, eth_call y eth_getLogs cubren la mayoría de los casos, con eth_blockNumber para puntos de control. Para escrituras, necesitas eth_estimateGas, eth_sendRawTransaction y eth_getTransactionReceipt. El estado histórico requiere acceso a archivo.
¿Puedo usar un endpoint RPC público para un panel de UNCX?
Un endpoint público puede funcionar para lecturas de bajo volumen, pero la indexación de logs y las ráfagas de escritura a menudo alcanzan límites de rango o de velocidad. Para paneles e indexadores de producción, una API RPC gestionada o un nodo dedicado te brinda un comportamiento más predecible.
¿Cómo manejo los contratos de UNCX en múltiples cadenas?
Mantén una configuración por cadena con ID de cadena, endpoint, URL del explorador y direcciones de contratos. No asumas la misma dirección en todas las redes. Verifica el ID de cadena al inicio para que un endpoint mal configurado falle de inmediato.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
