This is a working pitch deck. Speaker notes (in indented blockquotes) are kept visible for transparency — they’re what we say when walking through this in person.

PRUEBA — Full Pitch Deck

Proof of Recognized Use, Evidence-Based Attestation

Updated June 3, 2026. Public dashboard now live at pruebaprotocol.org.

Each ## is a slide. Speaker notes in blockquotes. Flip to what's relevant for your audience.

PART 1: THE STORY (Everyone)

PRUEBA

Permanent, verifiable proof that communities gathered, decided, and acted — using only the tools they already have.

prueba = "proof" in Spanish

Open with this. One sentence. Let it land.

The Problem

Communities do real work. None of it is provable.

• Sarreya Sport runs 50+ girls through football every Saturday in Hargeisa
• Hoops Sagrado runs basketball sessions daily in Guatemala
• Funders ask: "How many people used the court?"
• The answer: A WhatsApp thread. A notebook. Someone's memory.

Savannah told us they track sessions informally in WhatsApp. When grant reports are due, someone scrolls back through months of messages trying to reconstruct what happened. This is the norm, not the exception.

The Insight

The data already exists. It's just trapped.

• Every session gets discussed in the group chat
• Every decision gets debated there
• Every turnout gets mentioned
• It's all there — in WhatsApp, in Somali, in the group's own words

We don't need a tracking tool. We need to listen to what's already being said and make it permanent.

Key insight: we're not asking communities to adopt a new tool. We're adding a bot to the chat they already use.

What PRUEBA Does

A bot in your group chat that turns conversations into permanent, verifiable records.

• No wallets — community members never touch crypto
• No apps — works in WhatsApp and Telegram
• No English required — bot speaks Somali, Spanish, English, and more
• No trust required — anyone can independently verify any record

Emphasise "no wallets" — this is the fundamental difference from POAP, Snapshot, Gitcoin Passport. The bot holds the signing key. The community holds the trust.

How It Works

1. Organiser describes what happened — natural language, any language
2. Bot confirms details — "28 girls, 90 min, Lionsgate Gym? Correct?"
3. 3 community members reply "confirm" — social multisig
4. Record saved permanently — metadata on IPFS, attestation on Base
5. Public verification link — anyone can check, forever

Walk through slowly. Five steps, all in the same group chat, takes 2 minutes total.

PART 2: THE COMMUNITIES (For Shannon, Savannah, Asma)

Sarreya Sport — Somaliland

Who: Women's football collective, Hargeisa. Est. 2015. 50+ girls/women, ages 13-45. Home of Gobanimo FC.

The scenario:

• Saturday community session at Lionsgate Gym
• Coach Asma types: "Waxaan lahayn tababar maanta, 28 gabdhood, 90 daqiiqo" (We had training today, 28 girls, 90 minutes)
• Bot responds in Somali confirming the details
• Two other members confirm
• Permanent record created

The Somali language support is critical. These are real people in Hargeisa — the tool has to meet them where they are.

What This Unlocks for Sarreya

Funding arguments that write themselves:

• "Here are 40+ verified session records from this year, each confirmed by multiple community members"
• vs. "We run weekly sessions with about 20-30 girls"

Governance as you grow:

• Schedule changes, venue decisions, league rules — all logged
• No single person writes the history alone

A verifiable story:

• Two years from now, a clear record of every session since you started
• Portable — it belongs to Sarreya, not to any platform

How It Works for You (Sarreya)

You don't need to do anything technical.

Recording a session — someone types:

"Practice done. 26 girls, 90 minutes, Banadir stadium."

Bot responds:

"✓ 26 girls, 90 min, Banadir stadium, April 5th. Is that right?"

After confirmations:

"Saved permanently ✓ [View record]"

Recording a decision — someone types:

"Agreed: move Saturday practice to 4pm for the next month."

Bot asks: How did the community make this decision? (consensus, vote, elder, coordinator...)

Then saves it after confirmations.

PRUEBA never assumes voting. It captures however the community actually makes decisions.

Hoops Sagrado — Guatemala

Who: Community basketball programme, Guatemala.

The problem:

• Jumpstart Canada funded one court
• Need usage data to justify a second court
• Currently: no systematic proof the court is being used

With PRUEBA:

• 6 months of verified session records
• Each confirmed by multiple community members
• "Here are 200 records proving 3,000+ visits" vs "we think about 30 kids use it"

This is the concrete funding unlock. The difference between anecdotal evidence and verifiable proof. Jumpstart Canada can click any link and verify independently.

What We're Asking of Communities

Not much.

• Try the bot — live in your WhatsApp group; @sarreya_bot also live on Telegram
• Log sessions when it feels natural — after practice, someone types what happened
• Tell us what's clunky — feedback shapes what we build
• Nothing else — no wallets, no accounts, no apps, no fees

The May Workshop (Hargeisa)

Early May: hands-on session with Sarreya Sport in Hargeisa.

We wanted to hear:

• What do you wish funders could see?
• What decisions has your group made that you'd have wanted on record?
• What would make this genuinely useful rather than just another thing to do?

The workshop shaped how PRUEBA's WhatsApp flow now works in practice. The protocol is built around how Sarreya works, not the other way around.

PART 3: THE PROTOCOL (For Shannon & AIFS group)

Social Multisig — The Trust Model

The innovation that replaces wallets.

• Bot holds the signing key (community never needs a wallet)
• 3 confirmations required before any record goes permanent
• No single person can fake a record
• Threshold configurable per community
• Maps to how communities already make decisions — together

"Social multisig" is our term. It's community consensus expressed through chat confirmations. The bot won't write anything on-chain until enough people verify.

What's Already Built (as of June 2026)

PRUEBA + Confetti = Participatory Funding Stack

Confetti — "vote. rally. earn." — is a contest protocol where voters buy votes on entries via a rising price curve; 90% goes into a rewards pool that winning voters split. It's a decision + payment layer that reads on-chain data.

The integration:

1. PRUEBA attests community activity on-chain (sessions, attendance, governance)
2. Community enters a Confetti contest — entry field includes their PRUEBA entity address
3. A Confetti extension reads attestation count/history from that address on-chain
4. Voters vote with real economic skin in the game
5. Payment flows automatically to winners — weighted by verified track record

Why this fits funders' actual need:

• Participatory process, not a manual judging panel
• Communities with real attestation histories get naturally weighted by voters
• Every outcome is on-chain and auditable
• No wallets needed for community members (Para handles crypto abstraction)

The extension reading PRUEBA attestation data doesn't exist yet — it's a Q3/Q4 build.

PRUEBA + poidh = Workflow Bridge (Not a Full Stack)

poidh.xyz — "pics or it didn't happen" — built by AIFS collaborators.

How they work together:

1. Community runs sessions → PRUEBA attests them permanently
2. Submitter includes the PRUEBA attestation link in the poidh submission
3. Voters can click through to verify the attestation on-chain

Where Confetti fits: For more complex, multi-session proof with automatic payment, Confetti's extension layer reads PRUEBA on-chain data and triggers rewards. poidh is better suited for simpler, one-off proof tasks.

poidh and PRUEBA are complementary — casual social proof meets formal verifiable records. The technical integration is lightweight, and poidh is a great tool for simple proof-of-action use cases.

PART 4: TECHNICAL ARCHITECTURE (For Rather)

Protocol Stack

Community (WhatsApp / Telegram)
        ↓
OpenClaw Bot Agent (NL → structured data, multilingual)
        ↓
Metadata JSON → IPFS (Pinata, pinned)
        ↓
EAS Attestation (Base mainnet)
        ↓
Indexer → REST API (api.pruebaprotocol.org)
        ↓
Web Dashboard (pruebaprotocol.org)

EAS Schemas (Prototypes — feedback welcome)

Both deployed on Base mainnet.

Schema A: Community Activity

bytes32 entityId      // Community identifier
bytes32 activityRef   // IPFS CID (keccak256 → bytes32)
uint64  timestamp     // Unix timestamp of session
address attestedBy    // Bot wallet address

View on EAS Scan

Schema B: Governance Decision

bytes32 entityId      // Same community identifier
bytes32 proposalRef   // IPFS CID → governance metadata
uint64  timestamp     // Unix timestamp of decision
address attestedBy    // Bot wallet address

View on EAS Scan

Off-chain Metadata (IPFS)

All rich data lives in IPFS. On-chain attestation is a pointer + timestamp + signer.

Activity metadata:

{
  "schema": "prueba-activity-v1",
  "facilityName": "Lionsgate Gym",
  "activityType": "football",
  "sessionDate": "2026-04-05T14:00:00Z",
  "durationMinutes": 90,
  "participantCount": 28,
  "confirmedBy": ["Asma", "Fatima", "Hodan"]
}

Governance metadata:

{
  "schema": "prueba-governance-v1",
  "proposalText": "Move Saturday practice to 4pm",
  "decisionProcess": "consensus",
  "outcome": "approved",
  "participantCount": 12,
  "confirmedBy": ["Asma", "Savannah", "Hodan"]
}

Note: governance captures decision process (consensus, elder, coordinator, vote) — not just vote tallies. We don't assume Western governance models.

Bot Wallet & Delegation

Bot wallet: 0xc2568e680076eb5c9B488f65Cb5076048E5E0805

• Single delegated key — bot signs on behalf of communities
• Social multisig at the UX layer (not contract layer) for v1
• Planned: per-community signing keys, EAS delegation spec

Open Design Questions (For Rather)

1. entityId encoding — ENS namehash? keccak(slug)? What's most composable?
2. IPFS ref type — bytes32 (keccak of CID, lossy) vs string (full CID)?
3. Social multisig on-chain — resolver contract that checks confirmations, or UX-layer enough for v1?
4. Per-community key management — patterns that don't require communities to hold private keys?
5. NEAR ↔ Base bridge — if IronClaw agents attest on NEAR, clean way to publish to EAS on Base?

Integration Possibilities

IronClaw / NEAR:

• Community entityId as IronClaw agent address → portable cross-chain identity
• Each community's attestation bot as an IronClaw agent — holding own key, queryable via NEAR
• NEAR attestation mirror to Base EAS for funder legibility

poidh workflow bridge:

• Include PRUEBA attestation link in the poidh submission description
• Voters can verify the attestation on-chain independently
• poidh works well for simple, one-off proof-of-action tasks; PRUEBA adds verifiable on-chain depth

Hypercerts:

• PRUEBA attestations aggregate into impact claims
• "Sarreya Sport: 45 sessions, 800 girl-hours, April-December 2026" → issued as Hypercert

Resolver contracts (future):

• Validate IPFS metadata completeness
• Enforce minimum participant count
• Check entityId registration
• Emit events for indexer

PART 5: ROADMAP & ASKS (Everyone)

Timeline

We Need Your Input

• Schema design — prototypes, not final. What should we track?
• Social multisig threshold — is 3 right? Should it vary?
• Governance model — consensus, elder, coordinator models — not just voting
• Integration with IronClaw/NEAR — how does this complement Rather's infrastructure?
• Custom payment-reveal pipeline — what does automated proof → payment look like for your communities?
• Other communities — who else could use this?

End with genuine asks. This is collaborative — the AIFS group shapes the protocol.

Links

• Public dashboard: https://pruebaprotocol.org
• API: https://api.pruebaprotocol.org
• GitHub: https://github.com/explorience/prueba-protocol
• Telegram bot: https://t.me/sarreya_bot
• Activity schema: https://base.easscan.org/schema/view/0x2fc2d7385d068fd2df246752e9d466937e0a9850496ee36e3f834a17ed4fdc2e
• Governance schema: https://base.easscan.org/schema/view/0xc6f1d7668fb42840b66cf4d4871afd104165bbc8d499dcf5c25ec7ec9ffb152e
• poidh: https://poidh.xyz
• Sarreya Sport: https://sarreya.org
• AIFS: https://allinforsport.org · Blog
• SuperBenefit: https://superbenefit.org

PRUEBA is a protocol, not a product. The schemas are public. The code is open source. The records are permanent and verifiable by anyone.

The question isn't whether communities do valuable work. They do. The question is: can we make that work legible, permanent, and useful — without asking them to change anything about how they already operate?