Saltar al contenido
VespiContributions

VESPI CONTRIBUTIONS · PILOTO PROPUESTO EN STELLAR

Un buen aporte merece un registro que ambas personas puedan verificar.

Desde revisiones de código y mentorías hasta proyectos comunitarios, Vespi Contributions propone una constancia compartida de lo que se solicitó, se entregó y se aceptó, firmada en Stellar por quienes participan.

Ver el flujo propuesto ↓Reproducir la prueba existente ↗︎

Piloto propuesto · postulación enviada, resultado pendiente. El kernel y la prueba en testnet ya se pueden reproducir.

Ilustración: dos manos sostienen el mismo recibo de papel sobre una mesa mientras una abeja vuela encima.

A QUIÉN SIRVE

Un flujo. Muchas formas de aportar.

Cada comunidad colabora a su manera. La constancia puede seguir los mismos tres pasos.

  • Un builder con chaqueta de mezclilla entrega una tarjeta sobre un escritorio.BUILDERS

    Revisar una wallet, mejorar un repositorio o ayudar a un equipo a publicar un arreglo.

  • Una joven con su cuaderno escribe una solicitud en su escritorio.MENTORÍAS

    Acompañar a otro builder en una decisión técnica, una prueba o una integración.

  • Personas de distintas edades trabajan juntas en una mesa larga.COMUNIDAD

    Conectar equipos, apoyar una iniciativa de embajadores o colaborar entre capítulos.

FLUJO PROPUESTO · TODAVÍA NO DISPONIBLE

Dos personas. Tres pasos firmados.

  1. 01SOLICITARSolicitante

    Quien solicita describe el aporte y firma la solicitud.

  2. 02APORTARQuien aporta

    Quien aporta entrega su trabajo, enlaza la evidencia y firma su paso.

  3. 03ACEPTARSolicitante

    Quien solicitó revisa el resultado y firma la aceptación.

Cada persona autoriza su propia acción. Una cuenta patrocinadora puede cubrir comisiones y reservas, pero nunca firma por un participante.

RECIBO PÚBLICO PROPUESTO

El registro acompaña a quien aportó.

Un recibo completo mostraría la solicitud, la entrega y la aceptación, quién autorizó cada paso, la evidencia pública y los enlaces a las transacciones en Stellar. Los archivos del recibo y el verificador funcionarían sin depender del sitio de Vespi.

Diseño ilustrativo. El flujo de recibos entre dos personas está propuesto y todavía no está disponible.

VESPI CONTRIBUTIONSRECIBO PROPUESTO
Revisión del alta en una wallet
INTERFAZ PROPUESTA · ILUSTRATIVA · NO ES UNA CADENA REAL
  1. 01SOLICITARSolicitante · cuenta de ejemplo«Revisa el registro de nuestra wallet en el celular.»✓ firmado con cuenta propiahuella · MEMO_HASH
  2. 02APORTARQuien aporta · cuenta de ejemplo«Probado en dos teléfonos. Arreglo y notas en el pull request.»✓ firmado con cuenta propiahuella · MEMO_HASH ↑ enlaza al recibo anterior
  3. 03ACEPTARSolicitante · cuenta de ejemplo«Revisado e integrado.»✓ firmado con cuenta propiahuella · MEMO_HASH ↑ enlaza al recibo anterior
Evidencia públicaReferencia pública (pull request)StellarLas tres transaccionesRecibosLos registros JSONComprobación localCómo funciona el verificador
Comprueba quién autorizó cada paso y en qué orden. El trabajo lo juzgan las personas.

POR QUÉ STELLAR · VERIFICACIÓN PROPUESTA

Cada persona firma. Cualquiera puede comprobarlo.

Cada participante firma su propio paso. La huella SHA-256 de cada recibo canónico entra en una transacción de Stellar, y cada recibo lleva el hash del anterior. El verificador lee el registro público y comprueba firmantes, roles y orden. Las reservas patrocinadas y el fee bump permiten participar sin comprar XLM, y Vespi nunca guarda las claves privadas de nadie.

  1. 01Paso firmado
  2. 02Huella del recibo
  3. 03Transacción en Stellar (MEMO_HASH)
  4. 04Verificador

Las firmas comprueban el reconocimiento, no la calidad del trabajo.

EXISTE HOY · REPRODUCIBLE

Una base técnica que puedes comprobar.

  • Kernel v0.1.8: 1.319 pruebas pasan en su suite congelada.
  • Prueba en testnet: 7 pagos guardados, 7 violaciones de política bloqueadas, 9 pruebas offline y un verificador que devuelve VERIFIED. La volvimos a correr desde un checkout limpio el 10 de noviembre de 2026 con Node 24.
  • Una transacción anterior en mainnet ancla la huella de un recibo (25 de octubre de 2026).
  • Registros públicos de tráfico: 1.821 clonaciones de Vespi y 5.855 de Lore Plugin hasta el 9 de noviembre de 2026.

Las clonaciones no son usuarios únicos, y nada de esto es uso del flujo propuesto entre dos personas. La prueba usa un solo pagador y roles simulados.

Ejecutar el verificador existente ↗︎Ver el anclaje en mainnet ↗︎

PRUEBA EXISTENTE · ROLES SIMULADOS

$ node --test demo/sandbox/sandbox.test.cjs
ℹ tests 9
ℹ pass 9
ℹ fail 0
$ node demo/sandbox/verify.cjs --offline
Ledger: 7 payments from the payer,
7 paid receipts, total 29000000 stroops.
VERIFIED
Salida de una corrida desde checkout limpio · commit f53cd4b · Node v24.22.2 · 10 nov 2026

PROPUESTO PARA 30 DÍAS

Lo que construiría el piloto propuesto de 30 días.

  1. S1

    Firma de cada participante y alta con cuentas patrocinadas.

  2. S2

    Una primera cadena de referencia de tres pasos en mainnet, entre los dos builders, y páginas de recibo compartibles.

  3. S3

    Un verificador independiente de un solo comando y al menos diez casos de manipulación rechazados.

  4. S4

    Tres parejas reales de la comunidad, la evaluación de una organizadora externa y una reproducción independiente.

USD 5.000 · 120 horas de trabajo · evidencia pública por cada criterio. Son metas, no resultados.

Fuera de alcance: puntajes de reputación, insignias, tokens, un contrato Soroban nuevo y juzgar la calidad de un aporte.

VIDEO Y PITCH

El piloto en 99 segundos.

Leer el pitch deck (PDF, 10 láminas) ↗︎Ver en YouTube ↗︎

EL EQUIPO

Hecho en la comunidad. Comprobado en público.

  • Andrés PeñaLíder técnico · unas 100 horas

    Construye Vespi y Lore Plugin. En el piloto lidera la ingeniería, la firma de participantes, el alta patrocinada, el verificador y la publicación.

  • Francisco ToroModelo de aportes y piloto · unas 20 horas

    Sociólogo con 18 años de ejercicio profesional. En el piloto lidera el modelo de aportes, el acompañamiento de las parejas de la comunidad, la retroalimentación de uso y la evaluación.

Una persona ajena al equipo y a Tellus reproducirá la verificación y dejará el resultado en un issue público de GitHub.

Que el reconocimiento se pueda comprobar.

Lee el piloto propuesto, vuelve a correr la prueba de concepto existente y revisa la evidencia por tu cuenta.

Revisar el código ↗︎Reproducir la prueba existente ↗︎