Skip to content
VespiContributions

VESPI CONTRIBUTIONS · PROPOSED STELLAR PILOT

Good work deserves a record both people can verify.

From code reviews and mentorship to community projects, Vespi Contributions proposes a shared record of what was requested, delivered and accepted, signed on Stellar by the people involved.

See the proposed flow ↓Reproduce the existing sandbox ↗︎

Proposed pilot · application submitted, result pending. The kernel and the testnet sandbox can be reproduced today.

Illustration: two hands hold the same paper receipt across a table while a bee flies over it.

WHO IT IS FOR

One workflow. Many ways to contribute.

Communities help each other in different ways. The acknowledgment can follow the same three steps.

  • A builder in a denim jacket hands a small card across a desk.BUILDERS

    Review a wallet flow, improve a repository or help a teammate ship a fix.

  • A young woman with a notebook writes a request at her desk.MENTORS

    Guide a builder through a technical decision, a test or an integration.

  • People of different ages work together around a long table.COMMUNITY

    Connect teams, support an ambassador initiative or contribute across chapters.

PROPOSED FLOW · NOT LIVE YET

Two people. Three signed steps.

  1. 01REQUESTRequester

    The requester describes the contribution and signs the request.

  2. 02CONTRIBUTEContributor

    The contributor submits the work, links the evidence and signs their step.

  3. 03ACCEPTRequester

    The requester reviews the result and signs the acceptance.

Each person authorizes their own action. A sponsor account may cover fees and reserves, but it never signs for a participant.

PROPOSED PUBLIC RECEIPT

The record travels with the contributor.

A completed receipt would show the request, the delivery and the acceptance, who authorized each step, the public evidence and links to the Stellar transactions. The receipt files and the verifier would work without Vespi’s website.

Illustrative design. The two-person receipt flow is proposed and not live yet.

VESPI CONTRIBUTIONSPROPOSED RECEIPT
Wallet onboarding review
PROPOSED UI · ILLUSTRATIVE · NOT A LIVE CHAIN
  1. 01REQUESTRequester · example account«Review our wallet's sign-up flow on mobile.»✓ signed with own accountdigest · MEMO_HASH
  2. 02CONTRIBUTEContributor · example account«Tested on two phones. Fix and notes in the pull request.»✓ signed with own accountdigest · MEMO_HASH ↑ links to previous receipt
  3. 03ACCEPTRequester · example account«Reviewed and merged.»✓ signed with own accountdigest · MEMO_HASH ↑ links to previous receipt
Public evidencePublic reference (pull request)StellarThe three transactionsRaw receiptsThe JSON recordsLocal checkHow the verifier works
Checks who authorized each step, in what order. People judge the work.

WHY STELLAR · PROPOSED VERIFICATION

Each person signs. Anyone can check.

Each participant signs their own step. The SHA-256 digest of each canonical receipt goes into a Stellar transaction, and each receipt carries the hash of the one before it. The verifier reads the public ledger and checks signers, roles and order. Sponsored reserves and fee bump let newcomers take part without buying XLM, and Vespi never holds their secret keys.

  1. 01Signed step
  2. 02Receipt digest
  3. 03Stellar transaction (MEMO_HASH)
  4. 04Verifier

Signatures verify acknowledgment, not the quality of the work.

EXISTS TODAY · REPRODUCIBLE

A technical base you can check.

  • Kernel v0.1.8: 1,319 tests pass in its frozen suite.
  • Testnet sandbox: 7 saved payments, 7 blocked policy violations, 9 offline tests and a verifier that returns VERIFIED. We reran it from a clean checkout on 10 November 2026 with Node 24.
  • An earlier mainnet transaction anchors one receipt digest (25 October 2026).
  • Public traffic records: 1,821 Vespi and 5,855 Lore Plugin clone events through 9 November 2026.

Clone events are not unique users, and none of this is use of the proposed two-person flow. The sandbox uses one payer and simulated roles.

Run the existing verifier ↗︎See the mainnet anchor ↗︎

EXISTING SANDBOX · SIMULATED ROLES

$ 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
Output of a clean-checkout run · commit f53cd4b · Node v24.22.2 · 10 Nov 2026

PROPOSED FOR 30 DAYS

What the proposed 30-day pilot would build.

  1. W1

    Participant signing and sponsored onboarding.

  2. W2

    A first three-step reference chain on mainnet, between the two builders, and shareable receipt pages.

  3. W3

    An independent one-command verifier and at least ten rejected tampering cases.

  4. W4

    Three real community pairs, an outside organizer’s assessment and an independent reproduction.

USD 5,000 · 120 builder-hours · public evidence for each criterion. These are goals, not results.

Out of scope: reputation scores, badges, tokens, a new Soroban contract and judging the quality of a contribution.

VIDEO AND PITCH

The pilot in 99 seconds.

Read the pitch deck (PDF, 10 slides) ↗︎Watch on YouTube ↗︎

THE TEAM

Built in the community. Checked in public.

  • Andrés PeñaTechnical lead · about 100 hours

    Builds Vespi and Lore Plugin. In the pilot he leads engineering, participant signing, sponsored onboarding, the verifier and the release.

  • Francisco ToroContribution model and pilot · about 20 hours

    Sociologist with 18 years of professional practice. In the pilot he leads the contribution model, facilitation with community pairs, usability feedback and the evaluation.

Someone outside the team and Tellus will reproduce the verification and record the result in a public GitHub issue.

Make acknowledgment verifiable.

Read the proposed pilot, rerun the existing proof of concept and judge the evidence yourself.

Inspect the code ↗︎Reproduce the existing sandbox ↗︎