Vela — a source hands over evidence and risks being exposed.
Who contributes, who checks and who may publish are kept apart. Evidence: 11/11 tests. Fictional sources and media.
Part of Vespi's HackMeridian 2026 submission, as evidence of what Vespi and Lore Plugin let a person build.
For judges: How it works · Evidence · Limits · Review-only license.
The source is in this repository: run npm test on Node 24.
These projects remain separate, runnable repositories. / Estos proyectos siguen siendo repositorios ejecutables por separado.
Read in English
Kernel re-pin, 26 Oct 2026. This project now vendors Vespi kernel 0.1.8 (release
v0.1.8-kernel, commit13dbe24). Suite: 11 of 11 pass indocs/suite-2026-10-26.txt. Mentions of 0.1.6 below describe the 2026-10-11 capture.
The unit is the sealed document and the verifications that may support its publication.
Vela is a documented vertical slice for a legal channel where a person can submit a document they cannot publish alone. The document is sealed and remains unpublished while invited, fictional media verify it one at a time. Publication is attempted only after the configured number of verifications is recorded. Institutional membership is declared, but its proof is pending: Vela does not build zero-knowledge verification.
A person can hand over evidence and still be left exposed when an institution stays silent. Nothing reaches the public, yet the person who submitted it has already taken the risk. The opposite shortcut is no better: publishing a document without enough review can turn it into a weapon and leave its source carrying the cost. Vela makes waiting part of the publication rule: seal first, invite fictional verifiers, and keep the document unpublished until the record meets the chosen threshold.
Imagine a person, recorded only as fuente-1, submitting a fictional document about institucion-ejemplo. Vela seals it and leaves it unpublished. The custodian invites medio-1, medio-2 and medio-3, all fictional. Each invite permits one closed attestation. With fewer than three recorded verifications, publication is rejected and the reason is retained; once the configured threshold is met, Vela recomputes the checks before writing the publication line. The threshold of three is this project's choice, not a rule of the kernel. This is a synthetic walkthrough, not real journalism or proof that a document is authentic.
The scene below follows the agreement and the behaviors named in the test suite. It is an illustrative dialogue, not a transcript of a program run; the supplied sources do not include the output of npm run recorrido. The organizations and document are fictional, and the attestations are the project's closed set.
Source “I submit the sample document once.”
Vela The document is sealed. Publication remains closed.
Custodian Invites medio-1, medio-2 and medio-3.
medio-1 Attests: documento-autentico.
Custodian Tries to publish while the count is below three.
Vela Publication is rejected; the reason is retained.
medio-2 Attests: documento-incompleto.
medio-3 Attests: no-puedo-verificar.
Custodian Tries publication after the configured threshold is met.
Vela Recomputes the checks, then writes the publication line.
Those dialogue lines explain the specified path; they are not quoted terminal output. One real failure reason is recorded in the agreement: requirements consume 3 against grant max 1. The captured suite output is reproduced in Evidence. A second signature from the same invited medium is rejected, an uninvited medium cannot attest, and changing the sealed document prevents publication even if the count is reached.
source submits once
|
v
document sealed; unpublished
|
v
custodian invites fictional verifiers
|
v
each invited verifier attests once
|
v
recompute receipts and count the local record
|
+-- below threshold --> reject; retain the reason
|
+-- threshold met ----> write the publication line
| Actor | Rights in the described flow | Limits |
|---|---|---|
Source (fuente-1) |
Submit one document | No identity field is accepted; Vela does not promise anonymity or prove who submitted it |
| Channel custodian (Vela) | Seal, invite, count, and apply the threshold | Does not decide whether a document is true and cannot publish before the threshold |
| Invited verifier | Use one invitation for one closed attestation | Fictional organization; no real medium is named or contacted |
| Reader | Open the local JSONL record with an editor | Receipt digests do not establish who kept or supplied the file |
The source submission, verifier invitation and each verification use separate one-use authority grants and leave receipts. Vela builds the publication grant from the count it reads at the time of the attempt, and the published state does not reopen. The kernel's sufficient predicate decides whether that grant can cover the configured threshold. Before writing publication, Vela recomputes the checks from the record. The receipt digest helps detect changes; it does not authenticate the person who held the file.
| You need | What it gives you | Where it lives |
|---|---|---|
| A record that a document was submitted once | A one-use seal and a receipt tied to the document digest | How it works |
| Publication to wait for several attestations | One invitation and one attestation per fictional verifier; a threshold checked from the record | How it works |
| A reason when publication cannot proceed | A rejected attempt whose insufficiency comes from the kernel predicate | Evidence |
| A record a reader can inspect | A local JSONL file that can be opened without Vela | How it works |
| A clear boundary around institutional membership | Membership is declared and its zero-knowledge proof is marked pending | Legal and limits |
Vela is not an anonymity product, an Anonymous service, a leak site, a hacking tool, a source-identification system or a live journalism service. It does not contact real media or establish that a document is true. Its sample scenario uses synthetic data, fictional organizations and fictional signatures.
The recorded test record reports 11 passing tests out of 11, with 0 failing and 0 skipped, run under Node v24.15.0. The nine functional tests cover early-publication rejection, invitation and one-use limits, document integrity after sealing, rejection of an attempt to publish source identity, closed publication, the successful threshold path, the pending ZK boundary and the absence of an identity field in the record. One test checks the vendored kernel copy module by module against its SOURCE.md, and one additional passing test checks that the five module headers name the same commit.
The 2026-10-03 capture was red because the project was pinned to the older kernel cut (0.1.3, commit 54c20c7); that re-pin to 0.1.6 is done. The earlier RED phase records nine project cases failing before implementation and two digest checks passing; its counts are not the same measurement as the current 11/11 output. The agreement and phase notes also record three defects found and corrected during GREEN: free-form verifier text, publication written before recomputation, and receipt audits applying publication checks to a seal receipt. These are internal adversarial phase notes, not an independent security audit. Evidence includes the test names and limits.
Vela is one of the eleven functional projects in the Vespi project set. It uses the kernel copy vendored by Lore Plugin, pinned by module digests. The project runs on kernel 0.1.6 (commit 39d4573), verified module by module against its SOURCE.md in the 2026-10-11 suite. The documented kernel pieces Vela consumes are bounded authority grants, one-use budgets, the sufficient threshold predicate, receipt digests and receipt verification. Lore Plugin provides the vendored kernel copy described in the agreement; the agreement does not name other Lore Plugin features as part of this flow. This project has no network, testnet, payment or external anchor. See Vespi and Lore Plugin.
What this relationship means. The project was built with Lore Plugin's method (its agreement and criterion live in the project, in acuerdo.md and lore/), and its operations, authority and receipts run on the Vespi kernel 0.1.8, in the pinned copy of the v0.1.8-kernel release (vendor/vespi-kernel, commit 13dbe24). That copy sits in the project as vendor/vespi-kernel and the suite verifies it against its SOURCE.md. Lore Plugin does not run inside the project. This project does not use the kernel's newer capabilities (Stellar pubnet anchors, live x402 settlement, the ZK verifier, emergency access); it exercises the core of operations, authority and receipts.
Review status: this project has not been audited. The Vespi kernel it runs on has had superreviews with Claude Code and no independent external security audit.
There is no running zero-knowledge proof. Institutional membership is declared and its proof is pending. Vela does not hack, leak or identify a source, even in simulation. It does not use real documents, personal data, real media or a network, and it claims no legal compliance. The project materials do not verify an active agent session with RC5, and they do not establish readiness for real use. The kernel re-pin to 0.1.6 is done; the current suite is 11/11. See Legal and limits.
This repository contains the source code, the agreement, explanation and test record, under the review-only terms in LICENSE, which permits reading and cloning for evaluation. Run npm test on Node 24 from the project root. The license is proprietary and marked as a working draft for legal review.
Andrés Peña, repository authority: andresanemic.
How it works · Evidence · Legal and limits · Review-only license · Vespi · Lore Plugin
Leer en español
Nueva fijación del kernel, 26 oct. 2026. Este proyecto ahora vendoriza el kernel de Vespi 0.1.8 (release
v0.1.8-kernel, commit13dbe24). Suite: 11 de 11 aprobadas endocs/suite-2026-10-26.txt. Las menciones a 0.1.6 más abajo describen la captura del 2026-10-11.
Funcionó.
El documento queda sellado hasta que verificadores invitados respalden su publicación.
La unidad es el documento sellado y las verificaciones que pueden respaldar su publicación.
Vela es un recorrido vertical documentado para un canal legal donde una persona puede entregar un documento que no puede publicar por su cuenta. El documento queda sellado y sin publicar mientras medios ficticios invitados lo verifican uno por uno. La publicación se intenta solo después de registrar el número configurado de verificaciones. La pertenencia a la institución se declara, pero su prueba está pendiente: Vela no construye verificación de conocimiento cero.
Una persona puede entregar evidencia y aun así quedar expuesta si una institución guarda silencio. Nada llega al público, pero quien entregó el documento ya asumió el riesgo. La otra salida tampoco resuelve el problema: publicar sin suficiente revisión puede convertir el documento en un arma y dejar el costo sobre su fuente. Vela incorpora la espera en la regla de publicación: primero sella, luego invita a verificadores ficticios y mantiene el documento sin publicar hasta que el registro alcanza el umbral elegido.
-
Lee la base del proyecto y su recorrido. Empieza por Cómo funciona.
-
Abre el registro de pruebas. Consulta Evidencia.
-
Lee los límites jurídicos y de verificación. Consulta Marco legal y límites.
-
Lee los términos en la licencia de solo revisión y ejecuta
npm test(Node 24).
Imagina que una persona, registrada solo como fuente-1, entrega un documento ficticio sobre institucion-ejemplo. Vela lo sella y lo mantiene sin publicar. El custodio invita a medio-1, medio-2 y medio-3, todos ficticios. Cada invitación permite una atestación cerrada. Si hay menos de tres verificaciones registradas, se rechaza la publicación y se conserva el motivo; cuando se alcanza el umbral configurado, Vela vuelve a calcular las comprobaciones antes de escribir la línea de publicación. El umbral de tres es una elección de este proyecto, no una regla del kernel. Es un recorrido sintético, no periodismo real ni una prueba de que el documento sea auténtico.
La escena sigue el acuerdo y los comportamientos descritos por los nombres de las pruebas. Es un diálogo ilustrativo, no una transcripción de una ejecución: las fuentes entregadas no incluyen la salida de npm run recorrido. Las organizaciones y el documento son ficticios, y las atestaciones pertenecen al conjunto cerrado del proyecto.
Fuente «Entrego una vez el documento de muestra».
Vela El documento queda sellado. La publicación sigue cerrada.
Custodio Invita a medio-1, medio-2 y medio-3.
medio-1 Atestigua: documento-autentico.
Custodio Intenta publicar cuando el conteo aún no llega a tres.
Vela Rechaza la publicación y conserva el motivo.
medio-2 Atestigua: documento-incompleto.
medio-3 Atestigua: no-puedo-verificar.
Custodio Intenta publicar después de alcanzar el umbral configurado.
Vela Recalcula las comprobaciones y escribe la línea de publicación.
Estas líneas explican el recorrido especificado; no son una salida literal de terminal. Un motivo real de rechazo que aparece en el acuerdo es requirements consume 3 against grant max 1. La salida capturada de la suite está reproducida en Evidencia. Una segunda firma del mismo medio invitado se rechaza, un medio no invitado no puede atestiguar y alterar el documento sellado impide publicarlo aunque se alcance el conteo.
la fuente entrega una vez
|
v
documento sellado; sin publicar
|
v
el custodio invita a verificadores ficticios
|
v
cada verificador invitado atestigua una vez
|
v
recalcular recibos y contar el registro local
|
+-- bajo el umbral --> rechazar; conservar el motivo
|
+-- umbral alcanzado -> escribir la línea de publicación
| Actor | Derechos en el recorrido descrito | Límites |
|---|---|---|
Fuente (fuente-1) |
Entregar un documento una vez | No se acepta un campo de identidad; Vela no promete anonimato ni prueba quién lo entregó |
| Custodio del canal (Vela) | Sellar, invitar, contar y aplicar el umbral | No decide si un documento es verdadero y no puede publicar antes del umbral |
| Verificador invitado | Usar una invitación para una atestación cerrada | Organización ficticia; no se nombra ni contacta a ningún medio real |
| Lector | Abrir el registro JSONL local con un editor | Los digests de recibos no acreditan quién guardó o entregó el archivo |
La entrega de la fuente, la invitación del verificador y cada verificación usan grants de autoridad de un solo uso y dejan recibos. Vela construye el grant de publicación a partir del conteo que lee en el momento del intento, y el estado publicado no se reabre. El predicado sufficient del kernel determina si ese grant cubre el umbral configurado. Antes de escribir la publicación, Vela vuelve a calcular las comprobaciones desde el registro. El digest del recibo ayuda a detectar cambios, pero no autentica a la persona que conservó el archivo.
| Necesitas | Qué te da Vela | Dónde vive |
|---|---|---|
| Registrar que un documento se entregó una vez | Un sello de un solo uso y un recibo ligado al digest del documento | Cómo funciona |
| Que la publicación espere varias atestaciones | Una invitación y una atestación por verificador ficticio; el umbral se comprueba desde el registro | Cómo funciona |
| Conocer el motivo cuando no se puede publicar | Un intento rechazado cuya insuficiencia viene del predicado del kernel | Evidencia |
| Inspeccionar el registro | Un archivo JSONL local que se puede abrir sin Vela | Cómo funciona |
| Delimitar la pertenencia institucional | Pertenencia declarada y prueba de conocimiento cero marcada como pendiente | Marco legal y límites |
Vela no es un producto de anonimato, un servicio Anonymous, un sitio de filtraciones, una herramienta para hackear, un sistema de identificación de fuentes ni un servicio periodístico activo. No contacta a medios reales ni establece que un documento sea verdadero. Su ejemplo usa datos sintéticos, organizaciones ficticias y firmas ficticias.
El registro de pruebas entregado informa 11 aprobadas de 11, con 0 fallidas y 0 omitidas, ejecutadas con Node v24.15.0. Las nueve pruebas funcionales cubren el rechazo de una publicación anticipada, los límites de invitación y uso único, la integridad del documento después del sello, el rechazo de un intento de publicar la identidad de la fuente, el cierre de una publicación, el recorrido positivo al alcanzar el umbral, el límite ZK pendiente y la ausencia de un campo de identidad en el registro. Una prueba comprueba la copia vendorizada del kernel módulo por módulo contra su SOURCE.md, y otra prueba aprobada comprueba que los encabezados de los cinco módulos declaren el mismo commit.
La captura del 2026-10-03 estaba en rojo porque el proyecto estaba fijado al corte viejo del kernel (0.1.3, commit 54c20c7); esa re-fijación a 0.1.6 ya está hecha. La fase RED anterior registró nueve casos del proyecto que fallaban antes de implementar y dos comprobaciones de digest que pasaban; esos conteos no miden lo mismo que el 11/11 actual. El acuerdo y las notas de fase también documentan tres defectos hallados y corregidos al pasar a GREEN: texto libre de verificación, publicación escrita antes del recálculo y auditorías que exigían comprobaciones de publicación a un recibo de sello. Son notas adversariales internas, no una auditoría de seguridad independiente. Evidencia incluye los nombres de las pruebas y sus límites.
Vela es uno de los once proyectos funcionales del conjunto de Vespi. Usa la copia del kernel incluida por Lore Plugin, fijada por digest de módulo. El proyecto corre con el kernel 0.1.6 de este corte local (commit 39d4573), verificado módulo por módulo contra su SOURCE.md en la suite del 2026-10-11. Las piezas del kernel que Vela documenta que consume son grants de autoridad acotada, presupuestos de un solo uso, el predicado sufficient para el umbral, digests de recibos y su verificación. Lore Plugin aporta la copia vendorizada del kernel descrita en el acuerdo; el acuerdo no nombra otras funciones de Lore Plugin como parte de este recorrido. Este proyecto no tiene red, testnet, pagos ni anclaje externo. Consulta Vespi y Lore Plugin.
Qué significa esta relación. El proyecto se construyó con el método de Lore Plugin (su acuerdo y su criterio viven en el proyecto, en acuerdo.md y lore/), y sus operaciones, autoridad y recibos corren sobre el kernel de Vespi 0.1.8, en la copia fijada del release v0.1.8-kernel (vendor/vespi-kernel, commit 13dbe24). Esa copia está en el proyecto como vendor/vespi-kernel y la suite la verifica contra su SOURCE.md. Lore Plugin no corre dentro del proyecto. Este proyecto no usa las capacidades nuevas del kernel (anclas Stellar pubnet, liquidación x402 en vivo, el verificador ZK, el acceso de emergencia); ejerce el núcleo de operaciones, autoridad y recibos.
Estado de revisión: este proyecto no ha sido auditado. El kernel de Vespi sobre el que corre ha tenido superreviews con Claude Code y ninguna auditoría de seguridad externa independiente.
No hay una prueba de conocimiento cero activa. La pertenencia institucional se declara y su prueba está pendiente. Vela no hackea, filtra ni identifica a una fuente, ni siquiera en simulación. No usa documentos reales, datos personales, medios reales ni una red, y no afirma cumplir normas jurídicas. Los materiales del proyecto no verifican una sesión activa de agente con RC5 ni establecen que esté listo para uso real. La re-fijación del kernel a 0.1.6 está hecha; la suite actual es 11/11. Consulta Marco legal y límites.
Este repositorio contiene el código fuente, el acuerdo, la explicación y el registro de pruebas, bajo los términos de solo revisión de LICENSE, que permiten leerlo y clonarlo para evaluarlo. Ejecuta npm test con Node 24 desde la raíz del proyecto. La licencia es propietaria y está marcada como borrador de trabajo para revisión jurídica.
Andrés Peña, autoridad del repositorio: andresanemic.
Cómo funciona · Evidencia · Marco legal y límites · Licencia de solo revisión · Vespi · Lore Plugin