sierpe

Sierpe es un servidor autoalojado que monitorea la red de Stellar para los contratos que un usuario registra y mantiene su historial completo en la base de datos Postgres del operador, expuesta a través de una API REST y una interfaz de usuario de gestión integrada. El proyecto se etiqueta como v1.5.2, con un diseño descrito como estable en docs/DESIGN.md, y establece que los eventos, el estado del contrato, las transferencias de tokens, las trustlines y los movimientos de tokens están completos en cuanto a funcionalidades y se ejecutan contra la testnet. Qué indexa - Eventos emitidos por contratos registrados, descubiertos a partir de la especificación on-chain de cada contrato y recuperados en bloques, para luego ser seguidos en la punta de la cadena. - Estado del contrato: el historial de cambios de las entradas de almacenamiento más una instantánea actual. - Transferencias de tokens decodificadas (decodificación SEP-41, muxed CAP-67) y las trustlines clásicas de activos SAC. - Movimientos de tokens hacia adentro o hacia afuera de un contrato, independientemente de qué contrato haya emitido la transferencia, con informes de cobertura por tipo. - Historial inferior a la ventana de retención de RPC: los RPC de Stellar mantienen aproximadamente siete días de eventos, por lo que Sierpe recupera datos desde el génesis donde las fuentes lo permiten y está diseñado para reproducir History Archives públicos para rangos que ningún RPC sirve; la reproducción de archivos se proporciona a través de la imagen `-full`. Cómo se utiliza El despliegue consiste en un contenedor junto a un Postgres vacío. Los contratos se registran en tiempo de ejecución como datos, no como código, a través de una llamada autenticada como POST /v1/contracts con un ID de contrato y `from: genesis`; el servidor entonces clasifica el contrato, recupera su historial y continúa siguiéndolo. Los usuarios pueden consultar eventos con filtros estilo getEvents-v2 (por ejemplo, topic0 y cursores), la instantánea de almacenamiento actual para una clave y el historial de cualquier entrada de almacenamiento. La documentación enumera despliegues en Railway, Docker Compose y contenedores genéricos, y el README sugiere que el mismo binario se ejecuta en Railway, AWS, GCP o un VPS pequeño, con un costo objetivo inferior a $10/mes para un proyecto típico. Los requisitos son Docker o Go 1.25+, con configuración a través de DATABASE_URL, NETWORK y ADMIN_TOKEN. Comportamiento de la API y garantías de honestidad El README enfatiza que la cobertura y los vacíos son datos de primera clase: cada respuesta declara `coverage` y un `scanStatus` de HAS_MORE, WAITING_FOR_LEDGERS, OLDEST_REACHED o COMPLETE, por lo que una página vacía indica que nada existe o que la indexación no ha llegado a ese rango. La paginación se basa en cursores opacos que codifican toda la consulta, destinados a evitar el desplazamiento de datos. La superficie completa de la API está especificada en docs/openapi.yaml y las métricas están documentadas en docs/METRICS.md; un tablero de Grafana y una página de estado se incluyen entre los entregables del dispositivo. Interfaz y control de acceso Una interfaz de gestión está integrada en `/` y existe un endpoint de listado de contratos. Se ofrece un modo opcional de Basic Auth para toda la superficie para despliegues en dominios públicos. No objetivos explícitos El README establece que el proyecto no es un servicio alojado, ni una plataforma de análisis (sin agregaciones ni tableros sobre datos de usuario), ni un indexador de toda la cadena (solo se indexan los contratos registrados), ni un framework; tener que escribir código para usarlo se consideraría un error. Hoja de ruta Los hitos completados cubren el esqueleto (configuración, salud, migraciones, bucle de cursor con comprobaciones de continuidad), eventos de extremo a extremo, estado del contrato, un lanzamiento de dispositivo v1.0.0, transferencias de tokens y trustlines SAC (v1.1), reproducción de archivos (v1.2), la interfaz integrada y el listado de contratos (v1.3), Basic Auth opcional (v1.4) y movimientos de tokens con cobertura por tipo (v1.5). El trabajo planificado incluye el descubrimiento de clases de contratos en v1.6, donde registrar un hash de wasm indexa cada contrato desplegado a partir de él, y en v2 la entrega push con webhooks firmados y sumideros de brokers, con un servidor MCP descrito como bajo exploración. Material del proyecto La documentación incluye docs/DESIGN.md (arquitectura, modelo de datos, superficie de API, configuración, hitos), docs/DEPLOY.md, docs/KNOWLEDGE.md (29 principios destilados de indexadores de producción, cada uno con su fuente), CONTRIBUTING.md y SECURITY.md. El proyecto tiene licencia Apache-2.0 e invita a enviar problemas y comentarios.