My Summer of Bitcoin Journey

Diving into the Internship: Mid-Term Reflections

With the acceptance email still fresh in my inbox, I embarked on my 12-week adventure with Shopstr. The first half was a whirlwind of learning, coding, and overcoming hurdles in Bitcoin's intricate world. Under the guidance of my mentor calvadev, I focused on building the foundation for secure, trustless payments—starting with P2PK time-locked Cashu tokens and an automated processor for payment and shipping confirmations.

The project kicked off smoothly, but as a newcomer to Cashu and Nostr protocols, I faced my share of struggles. Debugging mint support for NUT-11 extensions and ensuring seamless integration with Next.js took late nights and plenty of trial-and-error. Yet, these challenges were rewarding, teaching me the nuances of cryptographic escrow and real-time event handling.

Implementing P2PK Time-Locked Cashu Escrow

The core security upgrade in Shopstr’s new payment flow centers on leveraging Cashu’s P2PK (Pay-to-PubKey) time-locked tokens. Previously, buyers had to trust that sellers would deliver after payment, with no cryptographic guarantees. My implementation adds a 2-of-3 multisig escrow, using Cashu’s NUT-11 extension, to hold funds securely until transaction conditions are met.

To implement P2PK time-locked Cashu tokens as payment escrow in Shopstr, I focused on enabling both trustless order processing and automated dispute resolution. Traditionally, Shopstr required buyers to trust merchants directly, but my approach leverages Cashu’s P2PK (Pay-to-Pubkey) time-lock feature (NUT-11) to enforce escrow at the protocol level.

First, I extended merchant profiles with a P2PK configuration—adding fields like enabled, pubkey, locktime, and refund pubkeys. This allows each shop to opt-in to time-locked payments, specifying a lock period and refund recipients.

In the payment flow, when a buyer checks out, the app dynamically detects if the seller supports P2PK. If enabled, it builds the payment with the merchant’s public key, locktime, and refund keys. The Cashu mint’s info is checked for NUT-11 support (“Mint does not support P2PK (NUT-11)”), and payments are sent using the wallet’s send function with a p2pk parameter.

How it Works:

• When a buyer pays, the app checks if the selected mint supports NUT-11 (P2PK). If not, the transaction is rejected (if (!mintInfo.nuts?.["11"]?.supported) { throw new Error("Cashu mint does not support P2PK escrow (NUT-11)"); }).
• The payment splits tokens using the wallet.send call and attaches P2PK options:
  • pubkey: Seller’s pubkey.
  • locktime: Optional time-lock, so funds can be refunded if stuck.
  • refundKeys: Includes both the buyer’s and any fallback pubkeys.
  • pubkeys: Always includes the buyer, seller, and a designated arbiter (from environment: ARBITER_PUBKEY).
  • nSigs: Set to 2, requiring any two signatures to spend, enforcing “2-of-3” multisig.

Code example:

const p2pkOptions = {
  pubkey: p2pk.pubkey,
  locktime: p2pk.locktime,
  refundKeys: [...(p2pk.refund || []), buyerPubkey],
  sigflag: tags.find((t) => t[0] === "sigflag")?.[1] || "SIG_ALL",
  nSigs: 2,
  pubkeys: [buyerPubkey, ARBITER_PUBKEY]
}

This ensures that the funds can only be unlocked with signatures from two of the three parties, drastically reducing risk for both buyer and seller. If the seller is unresponsive, buyer and arbiter can refund; if the buyer is malicious, seller and arbiter can release; and after timeout, the buyer alone may reclaim.

UI updates provide clear “ Locked for X days” indicators for buyers, and a refund button is available if the lock expires and funds are not claimed, automating buyer protection.

This approach minimizes trust requirements, automates order handling, and sets the groundwork for dispute resolution by holding funds securely until conditions are met or refunds are triggered.

Automated Payment and Shipping Confirmation Processor

For my Summer of Bitcoin internship, I implemented an Automated Payment and Shipping Confirmation Processor for Shopstr to address manual order processing and trust issues between buyers and pseudonymous merchants. Traditionally, payments and order updates required merchant intervention, introducing risk and delays.

Approach: I introduced automation by leveraging the Nostr protocol for encrypted direct messaging. Upon successful payment, Shopstr now triggers a function (sendPaymentConfirmationMessage) that sends a digitally signed payment confirmation DM directly to the buyer’s Nostr pubkey, using the merchant’s key for authenticity. This function is invoked automatically after invoice or Cashu payment success, looping through each product in a cart or single product order, and includes vital details like order ID and payment amount.

Similarly, after the merchant ships the order, a separate function (sendShippingConfirmationMessage) automatically notifies the buyer with shipping confirmation over Nostr DM. Both functions wrap the event securely using ephemeral keys and encrypt the message before dispatch, ensuring privacy.

React components (CartInvoiceCard, ProductInvoiceCard, and Listing) handle state and trigger these messages automatically based on payment or shipping status, removing the need for manual merchant involvement.

Outcome: This approach automates order communication, reduces buyer risk, and sets the stage for integrating P2PK time-locked tokens or HODL invoices for escrow. It also lays the groundwork for future dispute resolution UIs, making Shopstr safer and more efficient for Bitcoin commerce.

Mid-Term Milestone and Learnings

Passing the mid-term evaluation was a huge boost! It validated my progress and motivated me for the second half. I learned invaluable lessons in Bitcoin-native commerce, from minimizing trust with cryptography to automating workflows in decentralized apps.

My mid-term evaluation congratulations email

Knock knock, BTC here!

Check out my contributions:

• Added P2PK Time-Locked Cashu Tokens - midterm
• Automated Payment and Shipping Confirmation Processor - midterm

Wrapping Up: Final Evaluation and Reflections

As the internship entered its final stretch, the momentum from mid-term propelled me forward. The momentum from escrow and automation carried into building user-facing resolution tools and ensuring code reliability. Struggles persisted—like handling encrypted chat sorting and edge-case testing—but collaboration with calvadev turned them into triumphs.

This phase deepened my appreciation for Bitcoin's potential in e-commerce, blending cryptography with intuitive UIs for a seamless experience.

Dispute UI and Workflow

To complement cryptographic escrow, I built a full-featured Dispute UI to provide both transparency and recourse in the case of issues like non-delivery or fraud.

Key Features and Flow:

• Opening Disputes: After purchase, buyers see an “Open a Dispute” button. Triggering this posts a Nostr event tagged to buyer, seller, and arbiter, with the order ID and reason.
• Tracking Disputes: A dedicated “Disputes” tab in the UI lists all disputes involving the user. Each entry shows the order, parties, status, and the latest message.
• Dispute Chat: Clicking a dispute opens a secure chat, implemented using NIP-59 (gift-wrap) encrypted Nostr messages. All parties can communicate, with messages sorted and decrypted in the client.
• Arbiter Controls: If a case can’t be resolved amicably, the arbiter can “Rule for Buyer” or “Rule for Seller.” This triggers the partial signing of the escrowed tokens (using the arbiter’s Schnorr signature) and delivers the result to the winner for redemption. The UI disables further actions and updates the status.
• Status Publishing: Each resolution is posted as a Nostr event (kind: 30007), so all clients update the dispute’s status in real time.

Code Example for Dispute Activation:

await activateDispute(nostr, signer, productData.d!, reason, userPubkey, productData.pubkey)

Code Example for Arbiter Ruling:

const { inputs, signatures } = await createPartialRedemption(dispute.escrowToken, signer)

Summary: By combining P2PK time-locked multisig with a rich Nostr-based dispute system, I built a workflow that minimizes trust, gives users clear recourse, and keeps all interactions cryptographically verifiable and censorship-resistant. This approach strengthens Shopstr’s security and user experience for Bitcoin-native commerce.

Boosting Codebase Reliability with Test Coverage

For my Summer of Bitcoin internship, I boosted our codebase’s reliability by setting up test coverage using Jest and React Testing Library. I configured Jest for Next.js, added essential test scripts, and wrote unit tests for our custom hooks like useNavigation and useTabs. These tests ensured our navigation and tab logic worked correctly across different scenarios. This process made our codebase more robust and maintainable for future development.

Journey's End: Outcomes and Gratitude

Completing the final evaluation felt surreal—a complainant to growth from Bitcoin novice to contributor. Shopstr now boasts trustless payments, automated processes, and dispute handling, all while being more reliable thanks to tests. This internship honed my skills in Next.js, Nostr, Cashu, and Lightning, and taught me the power of open-source collaboration.

Stipend confirmation email

Explore my final contributions:

• Dispute UI - final term
• Test Coverage - final term
• Test Coverage - final term
• Test Coverage - final term

Internship Goodies: A Bitcoin Surprise!

Woohoo! As a delightful bonus for my Summer of Bitcoin internship, I received an awesome hardware wallet and some cool Bitcoin-themed goodies, all for free! This thoughtful gesture from the SoB team made the journey even more rewarding, giving me tools to securely dive deeper into the Bitcoin ecosystem.

My Summer of Bitcoin Hardware Wallet

See Hardware Wallet Post on X

Bitcoin-Themed Goodies from Summer of Bitcoin

See Goodies Post on X