Thanks2Go: Building a Human-Approved Gratitude Rail in One Weekend

I used Codex to its fullest potential as a research partner—for code mapping, source comparison, evidence organization, consistency checks, editorial control, and deliverable preparation. I formulated the intent, defined the scope, interpreted the results, arbitrated the conclusions, and preserved every public decision. This collaboration expands my investigative capacity; judgment, responsibility, authorship, and final signature remain under my authority.

This is a submission for Weekend Challenge: Generosity Edition.

What I Built

For five years, I have spent so many hours coding, studying mathematics, debugging, and learning new systems that much of it became ordinary to me. Opening VS Code, reading an unfamiliar repository, shaping an API contract, or asking what must never be automated feels like daily routine.

This weekend changed the scale of that routine.

Two developers asked me for help at almost the same moment that DEV announced its Generosity Edition challenge. One conversation was about learning. The other was about seeing a public portfolio with fresh eyes. I suddenly understood that the knowledge I had stopped noticing could shorten someone else’s path.

Thanks2Go grew from that realization: gratitude should be easy to express, but never easy to automate past the human who is spending it.

The product in one sentence

A creator voluntarily declares one canonical Thanks2Go profile on a page they control, and a visitor can open that profile after an explicit extension click to choose either a fixed PayPal gratitude tip or a Solana devnet demonstration.

There is no account system, feed, ranking, directory, background scan, or payment database. The first profile is my own SecuredMe profile, because a weekend experiment is not a reason to make other people part of a payment system without a separate onboarding and consent process.

Demo

• Live profile: thanks2go.securedme.ca/p/securedme
• Video: final selection and public embed pending.

The demo begins with a contribution that helped someone move forward. It then shows the declared profile, the click-scoped extension, the fixed 2 USD PayPal handoff, the Solana devnet gesture, a real A2A recipient check, the four WebMCP tools, and a signed receipt verification. Every provider action remains visible and human-controlled.

The live page is usable now. The video link will be added only after its recording excludes payer identity, merchant details, wallet secrets, environment values, and private financial links.

Code

SeCuReDmE-main-dev / thanks2go

Human-approved gratitude rails with Solana devnet, PayPal, A2A, WebMCP, and verifiable receipts

Thanks2Go

Thanks2Go is a human-approved gratitude rail built for the DEV Weekend Challenge: Generosity Edition. A creator declares one canonical profile. A visitor explicitly chooses either a fixed 2.00 USD PayPal gratitude tip or a clearly labelled Solana devnet demonstration.

Agents may inspect, stage, hand off, and verify. They cannot approve, capture, or sign payment.

What is in the repository

• React + TypeScript + Vite public profile
• Chrome Manifest V3 extension with only activeTab and scripting
• Express/Vercel API with signed ten-minute mandates
• PayPal Orders v2 create/capture boundary with fixed server-side amount
• Solana Commerce Kit 0.1.1 in tip mode on devnet
• Two real A2A 1.0 agents using @a2a-js/sdk 1.1.0
• ES256 vc+jwt gratitude receipts and public JWKS
• Experimental document.modelContext WebMCP progressive enhancement
• Contract, API, privacy, permission, and authority-boundary tests

Start locally

Requirements: Node.js 20 or newer and npm 11.

npm ci
copy .env.example .env.local
npm run dev

Open http://localhost:5173/p/securedme. Without…

View on GitHub

The public MIT repository contains the React/Vite page, the Manifest V3 extension, shared Zod contracts, A2A agents, the Express/Vercel API, security documentation, 103 automated tests, and the evidence checklist. The repository was created inside the challenge window. The current release gate keeps the remaining provider and recording evidence visibly pending.

How I Built It

The declaration is small on purpose

<link rel="thanks2go" href="https://thanks2go.securedme.ca/p/securedme">
<meta name="thanks2go:profile"
      content="https://thanks2go.securedme.ca/p/securedme">

The Chrome Manifest V3 extension has only activeTab and scripting. It reads those two selectors and the visible origin only after I click the extension. A conflict fails closed. A missing declaration leads to a manual canonical-URL field. A valid result still does not navigate until I click again.

That extra click is deliberate friction. It is the product boundary.

Two rails with different meanings

The PayPal rail is deliberately boring: exactly 2.00 USD, fixed on the server, described as a voluntary gratitude tip. Provider fees apply and Thanks2Go does not promise a specific net amount. The client cannot change the currency, amount, payee, description, or return destinations. Creation and capture use separate stable idempotency identifiers, and a success receipt is issued only after PayPal confirms the exact capture. The API discards payer name and email and exposes only a one-way hash of the provider payer identifier.

The Solana rail is deliberately labelled devnet demonstration. I pinned @solana-commerce/kit 0.1.1 and use its headless createTipRequest primitive in SOL tip mode. A visitor selects one of three bounded values—0.001, 0.005, or 0.01 SOL—and receives a signed ten-minute mandate. The transaction builder adds a read-only reference derived from that mandate's hash and exactly one matching memo. The server verifies finality, recipient, amount, signature, time window, reference, and memo before producing a receipt. Devnet tokens have no monetary value, and the interface says so at the decision point.

The general QR, when present, contains only the canonical profile URL. It never contains a wallet destination or an executable payment.

What the agents are allowed to do

Thanks2Go has two first-party A2A agents using the official JavaScript SDK and the v1 SendMessage JSON-RPC method.

• The Payer Intent Agent can stage an exact mandate after a rail and amount are selected.
• The Recipient Trust Agent can report evidence that the canonical origin and configured rail destination are controlled.

Their Agent Cards are signed with the same ES256 service identity published through JWKS. They answer immediately with an A2A Message; there is no persistent task history.

I used AP2 as a conceptual decomposition—intent, bounded mandate, visible approval, provider action, receipt—but I do not claim AP2 conformance. I also do not turn agent context into identity. Thanks2Go can say “origin controlled” and “destination controlled.” It cannot say “real person,” “safe profile,” or “human identity verified.”

WebMCP as progressive enhancement

When document.modelContext exists, the page registers four experimental WebMCP tools:

• inspect_gratitude_profile
• stage_gratitude_intent
• open_payment_handoff
• verify_gratitude_receipt

No tool can set approval to true, create or capture a PayPal order, or sign a Solana transaction. The normal interface works when WebMCP is absent.

This was an important design test for me. Agentic software becomes more useful when its authority is explicit; silently upgrading every useful action into autonomy weakens that trust.

I then asked a browser agent to inspect the product as if it had never seen the implementation. It understood the main boundary, yet it still had to guess whether an origin-control field was independently verifiable, whether a valid credential meant a settled payment, and whether the page had exposed unrelated browser secrets. That uncertainty became a contract test.

The inspection tool now reports the current origin, its match with the canonical profile, the transport state, the JWKS and signed Agent Card locations, and explicit paymentInitiated: false and secretsReturned: false fields. The staging tool exposes a recipient-control credential while withholding the signed payment mandate. Receipt verification separates cryptographic validity from confirmed settlement and from usability as payment proof.

After that bounded refinement, webmcp.com's external scanner graded the deployed page B+, detected all four tools, and recognized rigorous schemas and clear safety invariants. The product remains one deliberate page; I chose a narrow journey over pages created only to improve a coverage score. The grade is dated September 4; index presence was checked separately on September 5. It is not a security certification.

The work behind webmcp.com deserves its own acknowledgement here. Its public scanner and evaluation method gave me an immediate agent-facing review instead of leaving me to guess whether the tools were understandable from outside my own code. The feedback made refinement faster and easier: I could see which schemas needed precision, improve the contract once, redeploy, and verify the result. That kind of practical evaluation surface helps WebMCP move from an experimental browser capability toward something developers can test, compare, and improve with evidence.

Receipts without a gratitude database

Each mandate is signed, self-contained, audience-bound, nonce-bearing, idempotent, and valid for at most ten minutes. Provider state remains the source of truth. A confirmed result becomes a W3C Verifiable Credentials Data Model 2.0-shaped receipt in an application/vc+jwt-compatible ES256 envelope.

This removes the need for a database of who thanked whom. It does not erase provider retention or the public nature of a blockchain. The privacy page says both plainly.

What I tested

The automated suite covers canonical URLs, amount constraints, deterministic hashes, expiry, JWT tampering, API origin checks, the approval gate, signed Agent Cards, a real inter-agent A2A v1 exchange, MV3 permissions, conflicting declarations, and the absence of payment authority from WebMCP.

The release gate separately requires provider evidence: PayPal sandbox success, cancellation, refusal and idempotent retry; a separately confirmed live 2 USD capture; Solana devnet acceptance, cancellation, mismatched recipient/amount/reference and finality; keyboard, screen-reader, mobile and Chrome passes; GitHub Actions; TLS; and the public deployment.

At the September 5 verification checkpoint, 103 automated tests passed and GitHub Actions was green. Production checks exercised signed A2A exchanges and all four native WebMCP tools. PayPal sandbox success, cancellation and idempotent retry were verified; documented provider negative testing covered failure responses. A merchant screenshot showed a completed live 2 USD payment from a separate consenting payer. A 0.001 SOL devnet transfer was independently verified as finalized to the configured recipient, and Thanks2Go verified its signed receipt. Remaining work includes correlating and verifying the live PayPal application receipt, the outstanding browser QA, and the final demo recording.

The part that surprised me

I entered the weekend thinking I was building a small generosity tool. I ended up seeing my own last five years differently.

The technical work matters: strict contracts, a minimal extension, two payment rails, agent cards, verifiable receipts, threat models, tests. But the more important realization is that knowledge can become invisible to the person who carries it every day. The way back to curiosity was to place that knowledge in service of someone else—and then be disciplined enough to protect them from what the software should never decide.

Gratitude can travel quickly. Approval should still belong to a person.

Prize Categories

I am entering Best Use of Solana.

Thanks2Go uses @solana-commerce/kit 0.1.1 in tip mode on devnet. Commerce Kit prepares the bounded headless tip request; Thanks2Go constructs the native SOL transfer and adds a mandate-derived reference and memo, then verifies finality, recipient, exact amount, reference, memo, signature, and time window on the server before issuing a receipt. The interface identifies this rail as a devnet demonstration at every decision point.

Project Links

• Live profile: https://thanks2go.securedme.ca/p/securedme
• Source: https://github.com/SeCuReDmE-main-dev/thanks2go
• Challenge: https://dev.to/challenges/weekend-2026-09-03

Companion podcast

Why Thanks2Go rejects frictionless design — companion audio;

Why Thanks2Go rejects frictionless design - Google Drive

drive.google.com