Why I Applied
→ I am a first-year CS student at Amity University, Mohali. I had been building full-stack projects (DaemonDoc, Clura, NovaDrive) for a while. But something always felt like it was missing. I was building things, but not really contributing to anything that mattered at a protocol level.
→ Then I came across Summer of Bitcoin. It is a global internship program that places developers into open-source Bitcoin and Lightning projects, and it pays a stipend for it. The moment I read through the project list and saw Shopstr, a decentralized marketplace built on Nostr and Bitcoin, I knew that was the one.
My project: build a p2pk Cashu escrow system to enable trustless trade between buyers and sellers.
Phase 1: Getting In the Door
→ The SoB application is not just a form. You need merged pull requests into the project you are applying to. That is the entry ticket. So before I wrote a single word of my proposal, I started reading the Shopstr codebase.
→ My first few contributions were small, the kind that most people dismiss as "not real contributions." A Fisher-Yates shuffle fix for randomizing product listings. Small UI bugs. Incrementally harder issues each time. But each one taught me how the codebase was structured, how calvadev (the project owner) reviewed PRs, and what kind of thinking was valued in this community.
→ One contribution I am still proud of: I traced a multi-file spinner bug across the entire upload flow. It was not a one-liner. It required understanding how state was being shared across components and where the loading flag was not being reset correctly. That trace took hours. The fix itself was maybe five lines.
The Zustand Performance Pilot
One of the more technical things I did before submitting my proposal was run a performance pilot on Shopstr's ProductContext with my collaborator Aryan. The context was causing unnecessary re-renders across components that didn't even consume the changing state.
What We Did
- Profiled the worst-case render time on ProductContext using React DevTools
- Replaced the context with a Zustand store, slicing state to avoid cross-component invalidation
- Measured again: worst-case dropped from ~216ms to ~2.2ms
- Documented the approach and included it in the proposal as evidence
This wasn't just for the proposal. The codebase actually needed it. That felt important to me: contributing something real, not just padding a CV.
Writing the Proposal
→ The SoB proposal had to be more than "I want to build X." It needed a detailed breakdown of the technical implementation: the cryptography, the protocol specs, the edge cases.
→ My project was a p2pk Cashu escrow system for Shopstr. Cashu is an ecash protocol built on Bitcoin. Pay-to-public-key (p2pk) tokens are Cashu tokens locked to a specific public key. Only the holder of the corresponding private key can redeem them. The idea was to use these as a trustless escrow mechanism between buyers and sellers.
→ I read NUT-11 (the Cashu spec for p2pk) cover to cover. Studied PRs #152, #159, and #217 in the Shopstr repository to understand what groundwork was already laid. I outlined three deliverables: p2pk escrow (primary), a dispute resolution system (secondary), and hodl escrow (tertiary). I wrote the proposal in one sitting, but it was backed by weeks of reading.
Selection Criteria Breakdown (as I understood it):
The Rejection
→ The results dropped. I did not get in.
→ I had put an estimated 75% selection probability on myself going in. The proposal had scored around 9.5/10 from the people I had shared it with. I had 9+ merged PRs. I had been active in the community. And still, the email said no.
→ I will not pretend that did not sting. It did. When you have spent weeks reading protocol specs at midnight, tracing bugs through someone else's codebase, writing and rewriting a proposal, and then it is over in one email. The silence after that is loud.
"The thing about rejection is that it forces you to sit with the question: was this worth doing even if I don't get the outcome? I kept coming back to the same answer: yes. I had learned Cashu, Nostr, ecash protocols. I had real merged PRs in a real Bitcoin project. That existed independent of whatever some committee decided."
→ So I waited. Not passively. I kept reading, kept being present in the Shopstr community. I did not disappear after the rejection the way a lot of applicants do.
The Reversal: Selection
→ Then things changed. I got selected.
→ I still do not know the exact mechanics of what shifted. But I think staying present after the rejection mattered. Not disappearing. Not burning bridges. Continuing to engage with calvadev and Gautam (my mentor) like someone who was already part of the project, because in a real sense, I was.
→ The project scope was confirmed: p2pk Cashu escrow as the primary deliverable, dispute system as secondary, hodl escrow tertiary. Aryan, my collaborator throughout the application, was also selected, working on the MCP server side of Shopstr. The stipend is split between us.
What the Journey Taught Me
11. Contributions before proposals
- Nobody owes you a spot for writing a good proposal alone
- Merged PRs are proof of work in the most literal sense
- Even small fixes teach you how the codebase thinks
- The people reviewing your proposal have already seen your code
22. Read the specs, not just the code
- NUT-11 took me a day to get through properly
- Understanding the protocol made the implementation obvious
- Reviewers can tell when someone actually read the spec vs skimmed a summary
- Protocol literacy is what separates application-layer devs from protocol devs
33. Rejection is not the end of the story
- Most people disappear after rejection. That alone sets you apart if you don't
- The work you did still exists. The PRs are still merged. The knowledge is still yours.
- Committees are imperfect. Timing matters. Politics matter. Stay anyway.
- The selection that followed was only possible because I did not leave after losing
44. Find your people inside the project
- calvadev, Gautam, Aryan: these relationships were built before selection, not after
- Working with Aryan on the Zustand pilot made both our profiles stronger
- Community is the moat. Technical skill gets you in the door; presence keeps it open
Where Things Stand Now
→ The escrow work is underway. Building a trustless trade system on ecash is genuinely hard. There are edge cases around token locking, key management, and dispute resolution that do not have clean answers yet. That is exactly why it is interesting.
→ If you are reading this as someone going through a similar application (for SoB, GSoC, or anything like it), here is the most honest thing I can say: the program is secondary. The work is primary. Apply because you want to build that specific thing in that specific codebase. The stipend and the title follow from that. If you optimize for the title first, the reviewers can tell.
→ And if you get rejected, stay. That is the whole move.