sierpe

Sierpe é um servidor auto-hospedado que monitora a rede Stellar para os contratos que um usuário registra e mantém seu histórico completo no banco de dados Postgres do próprio operador, exposto através de uma API REST e uma UI de gerenciamento incorporada. O projeto se identifica como v1.5.2, com um design descrito como estável em docs/DESIGN.md, e afirma que eventos, estado do contrato, transferências de tokens, trustlines e movimentações de tokens estão com as funcionalidades completas e operando na testnet. O que ele indexa - Eventos emitidos por contratos registrados, descobertos a partir da especificação on-chain de cada contrato e preenchidos em blocos, sendo então acompanhados na ponta da chain. - Estado do contrato: o histórico de alterações de entradas de armazenamento mais um snapshot atual. - Transferências de tokens decodificadas (decodificação SEP-41, muxed CAP-67) e as trustlines clássicas de ativos SAC. - Movimentações de tokens para dentro ou para fora de um contrato, independentemente de qual contrato emitiu a transferência, com relatórios de cobertura por tipo. - Histórico abaixo da janela de retenção do RPC: os RPCs da Stellar mantêm aproximadamente sete dias de eventos, portanto o Sierpe preenche desde o genesis onde as fontes permitem e é projetado para reproduzir Public History Archives para intervalos que nenhum RPC atende; a reprodução de arquivo é fornecida via imagem `-full`. Como é utilizado A implantação é um container ao lado de um Postgres vazio. Os contratos são registrados em tempo de execução como dados, não código, através de uma chamada autenticada como POST /v1/contracts com um ID de contrato e `from: genesis`; o servidor então classifica o contrato, preenche seu histórico e continua acompanhando-o. Os usuários podem consultar eventos com filtros no estilo getEvents-v2 (por exemplo, topic0 e cursores), o snapshot de armazenamento atual para uma chave e o histórico de qualquer entrada de armazenamento. A documentação lista Railway, Docker Compose e implantações de containers genéricos, e o README sugere que o mesmo binário roda no Railway, AWS, GCP ou em um pequeno VPS, com um custo alvo abaixo de $10/mês para um projeto típico. Os requisitos são Docker ou Go 1.25+, com configuração através de DATABASE_URL, NETWORK e ADMIN_TOKEN. Comportamento da API e garantias de honestidade O README enfatiza que a cobertura e as lacunas são dados de primeira classe: cada resposta declara `coverage` e um `scanStatus` de HAS_MORE, WAITING_FOR_LEDGERS, OLDEST_REACHED ou COMPLETE, portanto, uma página vazia indica que nada existe ou que a indexação não atingiu aquele intervalo. A paginação depende de cursores opacos que codificam a consulta completa, destinados a evitar derivas. Toda a superfície da API está especificada em docs/openapi.yaml e as métricas estão documentadas em docs/METRICS.md; um dashboard do Grafana e uma página de status estão listados entre as entregas do appliance. Interface e controle de acesso Uma UI de gerenciamento está incorporada em `/` e existe um endpoint de listagem de contratos. Um modo opcional de Basic Auth para toda a superfície é oferecido para implantações em domínios públicos. Não-objetivos explícitos O README afirma que o projeto não é um serviço hospedado, não é uma plataforma de análise (sem agregações ou dashboards sobre dados do usuário), não é um indexador de toda a chain (apenas contratos registrados são indexados) e não é um framework — a necessidade de escrever código para usá-lo seria considerada um bug. Roadmap Marcos concluídos cobrem o esqueleto (configuração, saúde, migrações, loop de cursor com verificações de continuidade), eventos de ponta a ponta, estado do contrato, um lançamento de appliance v1.0.0, transferências de tokens e trustlines SAC (v1.1), reprodução de arquivo (v1.2), a UI incorporada e listagem de contratos (v1.3), Basic Auth opcional (v1.4) e movimentações de tokens com cobertura por tipo (v1.5). O trabalho planejado inclui a descoberta de classe de contrato na v1.6, onde registrar um hash wasm indexa cada contrato implantado a partir dele, e na v2 a entrega push com webhooks assinados e sinks de broker, com um servidor MCP descrito como sob exploração. Material do projeto A documentação inclui docs/DESIGN.md (arquitetura, modelo de dados, superfície da API, configuração, marcos), docs/DEPLOY.md, docs/KNOWLEDGE.md (29 princípios destilados de indexadores de produção, cada um com sua fonte), CONTRIBUTING.md e SECURITY.md. O projeto é licenciado sob Apache-2.0 e convida a issues e feedbacks.